Skip to content

CONCEPT Cited by 1 source

Long-lived key risk

Definition

Long-lived key risk is the principle that the impact of a compromised key scales with the duration the key grants access and the breadth of systems that trust it — so migration, monitoring, and rotation priority should be ordered accordingly. A key that unlocks a single short-lived session is a local, bounded failure. A key that unlocks every system trusting a CA for ten years of signatures is a structural failure.

The principle is load-bearing for PQ migration prioritisation (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security), but generalises beyond the quantum threat to any credential- compromise threat model.

The priority ladder

Keys ordered roughly by attacker value per unit of attack work, canonical for scarce / expensive first-generation CRQCs but informative more generally:

  1. Root CA private keys — one forged signature → unbounded intermediate issuance → trust the whole subtree for as long as the root cert validity (decades). The single highest-leverage key in a PKI.
  2. Intermediate CA / code-signing CA keys — forge a subordinate → forge every leaf cert under it for the intermediate's validity (years).
  3. Code-signing keys — every update mechanism that trusts this key becomes an arbitrary-RCE vector. Automatic software updates extend the blast radius across every machine that ran that update.
  4. Federation trust anchors (OIDC IdP signing keys, SAML IdP certificates) — every authentication assertion downstream is forgeable. Blast radius = every relying party.
  5. Long-lived API tokens / service-account credentials — particularly ones with no rotation automation; often indefinite-validity in practice.
  6. Long-lived SSH keys — frequently pre-date key-rotation discipline; "10% of historical SSH keys grant root, none ever expire" (Ylonen, OPKSSH context).
  7. Session-short credentials (TLS server cert, OIDC access token, STS session token) — bounded lifetime, often automated rotation → structurally lower risk.

The scarce-vs-scalable-CRQC inversion

The 2026 Cloudflare analysis identifies a subtlety: the priority order above holds only while CRQCs are expensive. At scale:

  • Scarce / expensive first-generation CRQCs — attackers concentrate their limited compute on the highest-leverage keys; long-lived keys first.
  • Scalable / cheap CRQCs — attackers can break any key cheaply. Priority may shift toward covert attacks: individual-key forgery triggers broken-key detection, but HNDL-style passive decryption of captured traffic stays hidden. Sophie Schmieg's Enigma analogy: the valuable capability is the one the attacker keeps secret.

Either way, long-lived keys need to be migrated first — they are either the natural first target or the largest exposure surface in the covert-attack regime.

Ephemeral credentials as the structural response

The canonical remediation for long-lived-key risk is ephemeral credentials: generate-on-demand, use-briefly, discard. Examples already in the wiki:

  • OPKSSH — OIDC-issued 24h SSH certificates replace long- lived SSH keys; ACL moves from key-fingerprint to email.
  • AWS STS session tokens — federated roles issue tokens that expire in minutes to hours.
  • Lakebase per-boot VM keys — die when the VM dies.

Structural effect: the long-lived-key-accumulation problem ("10% grant root, none expire") cannot occur because no key is long-lived.

But: ephemeral credentials still depend on a long-lived authentication root — the OIDC IdP's signing key, the KMS root, the cloud-provider account trust anchor. That long-lived root remains a prime target and is not fungible with the ephemeral-credentials discipline itself. You have concentrated the long-lived-key attack surface, not eliminated it.

Long-lived key inventory as a prerequisite

Cloudflare's recommendation to enterprises — "assess critical vendors early for what their failure to take action would mean for your business" — presumes the enterprise has already enumerated its own long-lived keys. In practice this is difficult because long-lived keys are often:

  • Distributed across HSMs, YubiKeys, KMS slots, dev laptops, build servers, CI runners.
  • Hidden in config files, environment variables, bootloader firmware, TPM-sealed blobs.
  • Not owned by any one team — historical accidents of who provisioned what.
  • Dependency-chained — the long-lived key is not the application's key, it's the TLS certificate's intermediate's root's anchor in a client trust store.

A long-lived-key inventory is therefore itself an engineering project, not a one-afternoon scan. The PQ migration effectively forces the inventory because you cannot rotate what you cannot find.

Third-party long-lived-key exposure

Most enterprises have long-lived-key exposure through third parties they do not control — see patterns/third-party-dependency-quantum-assessment. Examples:

  • Payment processors with their own TLS and code-signing chains.
  • Software vendors whose binaries the enterprise installs on employee laptops.
  • Federated-identity providers whose signing keys anchor every SSO flow.
  • Browser trust stores shipped in the OS — the enterprise has no control over which CAs are trusted.

Cloudflare's explicit prescription: "it's important to understand the impact of a potential Q-day on third-party dependencies, both direct and indirect."

Why rotation matters after disablement

Even once classical signatures are disabled via patterns/disable-legacy-before-rotate, every secret ever transmitted over a classical-TLS / classical-SSH / classical-IPsec session may already be compromised — a CRQC-equipped attacker with prior captures can decrypt them. The long-lived keys in that category (application API keys, service-account tokens) must be rotated or they're live attack credentials the moment Q-Day arrives.

Key lifetime as a first-class design axis

The broader engineering lesson: treat key lifetime as a deliberate design choice, not an operational afterthought.

  • Default to short lifetimes (session tokens, STS, JWT minutes- to-hours) and automate rotation.
  • Reserve long lifetimes for trust anchors where rotation is architecturally hard (root CAs, OS-embedded keys) and compensate with HSM isolation, split-custody, and auditable ceremonies.
  • Eliminate accidental long-lived keys (dev personal SSH keys, hand-provisioned API tokens) via platform design — ephemeral- credentials is the standard recipe.

Seen in

  • sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security — canonical wiki instance. "If quantum computers arrive in the next few years, they will be scarce and expensive. Attackers will prioritize high-value targets, like long-lived keys that unlock substantial assets or persistent access such as root certificates, API auth keys and code-signing certs. If an attacker is able to compromise one such key, they retain indefinite access until they are discovered or that key is revoked." Sets the PQ-migration priority order.
Last updated · 200 distilled / 1,178 read