Skip to content

PATTERN Cited by 1 source

Disable legacy crypto before rotate

Shape

After enabling new cryptographic primitives (typically post- quantum), the migration is not complete until two further steps are executed in order:

Step 1: Enable new primitives         ← painless via algorithm negotiation
Step 2: Disable the legacy primitives ← blocks downgrade attacks
Step 3: Rotate every secret that ever crossed a legacy session
        ← burns captured-ciphertext attack value

Stopping at step 1 is the industry default and leaves the system exposed to two orthogonal threats — downgrade attacks (step 2 addresses) and harvest-now-decrypt-later (step 3 addresses). Both steps are structurally mandatory after Q-Day; neither is optional.

(Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

Why step 1 alone is insufficient

Problem 1: Downgrade attacks

With both classical and PQ primitives enabled, an active attacker in the handshake path can strip the PQ options from the advertised algorithm list and force classical-only negotiation. The transcript binding that normally defeats this (negotiation transcript signature) is itself a quantum-vulnerable signature: a CRQC- equipped attacker can forge the transcript auth, so negotiation- level downgrade protection fails.

Cloudflare's explicit statement:

Systems must disable support for quantum-vulnerable cryptography to be secure against downgrade attacks. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

Problem 2: Captured pre-disablement traffic

Any session that was ever negotiated with classical KEM primitives has its session keys derivable by a future CRQC from the captured ciphertext. Every secret transmitted in those sessions is recoverable:

  • Passwords transmitted over a TLS 1.2 HTTPS session with classical ECDHE.
  • API tokens issued via OAuth flow over classical TLS.
  • Database connection strings, service-account tokens, cookies.
  • SSH-agent forwarded credentials.

Once classical is disabled, attackers still have the captures. A post-Q-Day decrypt of those captures recovers live credentials — unless those credentials have been rotated in the interim.

The three-step sequence in detail

Step 1: Enable new primitives alongside classical

Via algorithm negotiation: add PQ hybrid KEM / PQ signature algorithm to supported lists, preference order favouring the new primitive. Clients that support it auto-select; clients that don't fall back without breakage.

This is painless and widely deployed by 2026: TLS X25519MLKEM768, SSH sntrup761x25519-sha512, IKEv2 PQ KEX.

Step 2: Disable classical primitives

The hard step. Feasible options by environment:

  • Closed systems (internal service mesh, enterprise VPN, controlled-SSH-fleet, HSMs, federation between trusted IdPs) — enforce PQ-only. Every client is under the organisation's control; flag-day cutover works.
  • Open federated systems (public web, email, DNSSEC, consumer SSH endpoints) — outright disablement breaks the long tail of clients. Alternatives:
  • PQ HSTS — browser-side sticky commitment: "this origin speaks PQ; refuse classical from it going forward."
  • Certificate Transparency-based downgrade detection — public logs reveal whether PQ certs exist for the origin; mismatch → treat as downgrade attack.
  • Graduated disablement — phase out specific cipher suites over time, monitor the client-side fallout, adjust.

In practice step 2 runs for years across the open Internet, because the pace is set by the slowest-upgrading clients. This is one reason Cloudflare's 2029 target is a 3+ year runway rather than a 6-month flip.

Step 3: Rotate every exposed secret

After classical is disabled (and before Q-Day arrives — the two windows should not overlap), every secret that ever crossed a classical session becomes a rotation target:

  • Passwords for every account whose password reset / login was ever submitted over classical TLS → force password change on next login, or expire and require rotation.
  • OAuth refresh tokens, service-account keys, database connection strings → force re-issuance.
  • Long-lived API keys — see long-lived key risk — highest-priority because they are both high-value targets and likely to have been transmitted multiple times over classical sessions during their lifetime.

Cloudflare's statement:

Once done, all secrets such as passwords and access tokens previously exposed in the quantum-vulnerable system need to be rotated. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

Rotation is the expensive step

In a typical enterprise, rotation is orders of magnitude more expensive than the technical cryptographic migration:

  • Enumerating every secret that has ever crossed a classical session — most orgs do not have this inventory.
  • Triggering rotation flows for each class of secret (user password, service account, OAuth token, API key, webhook signing key, database replication credentials).
  • Cascading updates — one rotated service-account key may need to be updated in 50 deployment configurations, CI secrets, operator runbooks.
  • Timing coordination — rotating the federation IdP's signing key requires all relying parties to fetch the new JWKS; rotation windows need careful orchestration to avoid outages.

This is why the migration timeline is "years, not months" (Cloudflare) — the signature-algorithm swap and the disablement are small fractions of the total work; rotation dominates.

What "rotate" means beyond credentials

The full rotation scope includes more than secrets:

  • Re-derive any key that was derived from a classical KDF output — if the classical session key fed a downstream derivation tree (common in messaging protocols), the derivates are also burned.
  • Re-issue signed artifacts where the signing key was classical — signed commits / release binaries / signed attestations may need re-signing under PQ keys, and the verification surfaces must accept the new signatures.
  • Rotate any long-term secret whose storage depended on classical envelope encryption — rewrap KEKs / DEKs under PQ- resistant primitives if the KMS doesn't already.

Not a one-time procedure — a standing discipline

A subtlety: future quantum cryptanalysis improvements may weaken PQ primitives too (especially lattice-based ML-KEM / ML-DSA which are newer and less battle-tested than classical ECDH). The disable-then-rotate sequence is the generic response to deprecating a cryptographic primitive, not a one-off quantum- era procedure. Treat it as a standing operational capability:

  1. Detect primitive weakness (cryptanalysis breakthrough, CVE advisory).
  2. Enable successor primitive in parallel.
  3. Disable weakened primitive.
  4. Rotate secrets that traversed weakened-primitive sessions.

The PQ migration is the first industry-wide test of this capability at the scale of the entire authentication stack.

Relationship to adjacent patterns

Seen in

  • sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security — canonical wiki instance. Cloudflare articulates the three-step sequence explicitly: "Disabling quantum-vulnerable cryptography is not the last step: once done, all secrets such as passwords and access tokens previously exposed in the quantum-vulnerable system need to be rotated. Unlike post-quantum encryption, which takes one big push, migrating to post-quantum authentication has a long dependency chain — not to mention third-party validation and fraud monitoring. This will take years, not months." The pattern generalises but PQ is its first-at-industrial-scale instance.
Last updated · 200 distilled / 1,178 read