Skip to content

CONCEPT Cited by 1 source

Post-quantum authentication

Definition

Post-quantum authentication is the migration of digital- signature and credential-verification primitives to quantum- resistant alternatives — the who are you? side of cryptography, distinct from the can anyone else read this? side that HNDL mitigation addresses. Classical RSA / ECDSA / Ed25519 signatures and the PKI they anchor fall to the same CRQC that breaks key-exchange, but with a completely different threat profile and a much longer dependency chain to migrate.

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

Why authentication becomes urgent only near Q-Day

Unlike HNDL, signature forgery is a live attack — it cannot be done retroactively. An attacker with a future CRQC cannot go back and forge a signature over past traffic; the past is fixed. So authentication is a live-CRQC threat, not a captured-today threat.

Operational consequence:

Q-Day distance Authentication urgency
Far (10+ years) Low. Deploying PQ certs and signatures adds complexity and cost with no retroactive benefit.
Near (<5 years) Catastrophic. Any long-lived quantum-vulnerable signature key becomes a forgery vector the day a CRQC comes online.

This is why PQ encryption rolled out industry-wide around 2022 (HNDL-driven, captured-today matters) but PQ authentication only became the focus in 2026 after the Q-Day reassessment — Cloudflare's 2026 post is the canonical articulation of the flip.

The impersonation threat model

Once a CRQC exists, an attacker can derive the private half of any classical-signature key whose public half they can observe. That means:

  • Server impersonation on TLS / SSH / VPN protocols — the attacker forges the server's certificate signature, MITMs the connection, the client accepts the forgery.
  • Code-signing-cert compromise — forged binaries signed with a classical root or intermediate are accepted by automatic software update mechanisms as legitimate. Every apt-get upgrade / Windows Update / App Store install becomes a remote-code-execution vector.
  • Federation trust-anchor forgery — forged SAML / OIDC IdP signatures produce authentic-looking auth assertions for arbitrary user identities.
  • API auth key forgery — long-lived API tokens signed with quantum-vulnerable keys can be forged rather than stolen.

Cloudflare: "Any overlooked quantum-vulnerable remote-login key is an access point for an attacker to do as they wish, whether that's to extort, take down, or snoop on your system. Any automatic software-update mechanism becomes a remote code execution vector. An active quantum attacker has it easy — they only need to find one trusted quantum-vulnerable key to get in."

Prioritize long-lived keys

Under scarce / expensive first-generation CRQCs, attackers concentrate their limited quantum compute on keys that grant the most access for the longest duration — see concepts/long-lived-key-risk. Migration priority in practice:

  1. Root CAs + intermediate CAs — forge one and every cert underneath is unsafe.
  2. Code-signing certificates — every signed binary is an RCE primitive.
  3. Federation trust anchors (OIDC IdP signing keys, SAML IdP certs) — every assertion downstream is forgeable.
  4. API auth keys with long expiration — especially service-account / federation keys.
  5. TLS server certs (last — relatively short-lived, auto- rotated, most ecosystems already have automation).

If later-generation CRQCs are scalable (cheap, fast), the attacker may revert to HNDL so the attack stays covert (Sophie Schmieg's Enigma analogy). In that regime everything is exposed, so the long-lived-first prioritisation still holds — it's the tail of the risk curve that doesn't change.

The "add PQ is not enough" rule

Cloudflare's hardest-hitting observation: deploying PQ signatures alongside classical ones does not make the system PQ-secure. The attacker can still downgrade the handshake to force selection of the classical signature, then forge that.

Adding support for PQ cryptography is not enough. 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)

For federated systems (the public web, email, DNSSEC) disabling classical signatures is not feasible because many clients won't support PQ in time. Alternatives being worked on:

  • PQ HSTS — HSTS-style browser policy header declaring "only accept PQ signatures from this origin going forward" — analogous to HSTS forcing HTTPS over HTTP.
  • Certificate transparency- based downgrade protection — public logs let browsers / OSes detect attempted downgrade; see Bas Westerbaan's RWPQC 2026 slides.

Rotate-after-disable

Once quantum-vulnerable cryptography is disabled, the migration isn't done. All secrets that were ever negotiated through a quantum-vulnerable session must be rotated — because an adversary with prior captures can decrypt the session once Q-Day arrives and recover those secrets:

  • Passwords transmitted over a now-disabled TLS 1.2-with-classical- KEX session.
  • API keys issued in an OAuth flow conducted over a classical handshake.
  • Database connection strings, service-account tokens, cookies.

See patterns/disable-legacy-before-rotate for the canonical two-step sequence.

Why the migration chain is long

PQ encryption migration is essentially two-endpoint: client supports it, server supports it, negotiation picks it — one big push. PQ authentication touches a much deeper dependency graph:

  • Cert issuance infrastructure — CAs, ACME, internal PKI.
  • Cross-signing during transition — old roots + new PQ roots both signing intermediates so clients trust either.
  • HSM firmware — hardware key-storage boxes must support ML- DSA / SLH-DSA.
  • Federated-identity IdPs — Okta / Entra / Ping / Cognito signing keys + client-library verifiers.
  • Fraud monitoring / third-party validation — cert pinning, revocation OCSP / CRLite, DV / OV / EV compliance surfaces.
  • Client trust stores — OS-level updates (iOS / Android / macOS / Windows / Linux) + browser-embedded trust stores + embedded devices that may never update.

Cloudflare: "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."

Canonical PQ-signature primitives

  • ML-DSA (NIST FIPS 204, formerly Dilithium) — lattice-based; the dominant choice for general- purpose PQ signatures. Cloudflare's Mid-2026 Cloudflare→origin deployment target.
  • SLH-DSA (NIST FIPS 205, formerly SPHINCS+) — hash-based; larger signatures but extremely conservative security assumptions (only SHA / SHAKE); suited for long-lived signing keys.
  • Falcon (NIST FIPS 206-draft) — lattice-based; smaller signatures than ML-DSA but more complex implementation.

Third-party dependencies in scope

Cloudflare explicitly extends the migration scope beyond direct cryptographic counterparties:

It's important to understand the impact of a potential Q-day on third-party dependencies, both direct and indirect. Not just the third-parties you speak cryptography to, but also any third parties that are critical business dependencies like financial services and utilities. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

See patterns/third-party-dependency-quantum-assessment.

Seen in

  • sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security — canonical wiki instance. Cloudflare's 2026 roadmap pivots from PQ-encryption-by-default (2022 done) to PQ authentication: Mid-2026 ML-DSA for Cloudflare→origin, Mid-2027 Merkle Tree Certificates for visitor→Cloudflare, Early 2028 Cloudflare One SASE, 2029 fully PQ secure. Explicit framing of the priority flip and the add-PQ-is-not-enough / rotate-after-disable / third-party-dependency rules.
Last updated · 200 distilled / 1,178 read