Harvest Now, Forge Later: The Quantum Threat to Your SSO

TL;DR

• “Harvest now, decrypt later” is a confidentiality risk: adversaries record encrypted traffic today and decrypt it once a cryptographically relevant quantum computer (CRQC) arrives.
• For single sign-on (SSO), the sharper risk is forge later: signatures cannot be “harvested,” but a quantum-forged signing key lets an attacker mint trusted tokens for every downstream relying party.
• A forged IdP root-of-trust is worse than a decrypted session, because it is a federation-wide compromise, not a single-session leak.
• You can act today with hybrid (composite) signatures — Mosca’s theorem says start now, because migration time plus data shelf-life can already exceed the time to a CRQC.

What is “harvest now, decrypt later” — and why does it under-describe the SSO risk?

Harvest now, decrypt later (also called store now, decrypt later) is an attack strategy where an adversary captures encrypted data today and stores it until a future quantum computer can break the key exchange that protected it. It targets confidentiality. For SSO the dominant quantum risk is different: not decryption of stored traffic, but forgery of the signatures that bind your entire identity federation together.

This distinction matters because identity providers (IdPs) are built on signatures, not just on encryption. Every ID token, every access token, and every JSON Web Key Set (JWKS) entry exists so that a relying party (RP) can verify that a credential genuinely came from the IdP. Break the verification math and you do not need to harvest anything — you simply forge new, perfectly valid tokens. That is the “forge later” threat, and it is the part of the quantum conversation that auth teams most often miss.

CAI Technology is not a government authority. We build identity infrastructure, and the threat model below is the one we design against.

How does the quantum threat change when the asset is a signature, not a secret?

The “harvest now, decrypt later” framing comes from the encryption world, where the loss is bounded: an attacker who decrypts a 2026 session learns the contents of that session. Damage is real but local in time.

Signatures invert the calculus. A signing key is a root of trust: it does not protect one message, it vouches for an unbounded number of future and past messages. If an adversary recovers an IdP’s private signing key — by using Shor’s algorithm against RSA or elliptic-curve keys once a CRQC exists — they can forge:

• new ID/access tokens that every federated RP will accept as authentic;
• assertions for users and scopes that never existed;
• backdated artifacts, because nothing about a signature reveals when the attacker computed it.

There is nothing to “harvest” first. The public key is already public (it is published in the JWKS). The attacker waits for the quantum capability, derives the private key from the public key, and starts forging. Confidentiality attacks degrade gracefully; a root-of-trust forgery does not.

How to read this diagram: The top path is the classic harvest-now-decrypt-later attack — the attacker records traffic, waits for a quantum computer, and recovers the contents of a single session. The bottom path is the forge-later attack against an IdP. There is no harvesting step, because the signing key’s public half is already published in the JWKS; the attacker only needs the future quantum capability to recover the private half, after which every relying party accepts forged tokens as genuine. The contrast shows why confidentiality damage is bounded to one session while a forged root of trust propagates to the whole federation. For an IdP, defending the signing key is therefore the higher-priority quantum task. See our post-quantum authentication guide for the full category view.

What does an attacker forge first?

A rational adversary attacks the key with the largest blast radius and the longest lifetime. In an SSO deployment that ordering is fairly predictable:

1. The IdP token-signing key. One forged key produces unlimited valid tokens for every connected application. This is the crown jewel.
2. Federation / trust-anchor keys. SAML or OIDC federation metadata signing keys let an attacker impersonate an entire trusted party, not just a user.
3. Code-signing and update keys. Forge these and you ship malicious software that clients install as “trusted” — a supply-chain compromise.
4. Long-lived CA and intermediate keys. Anything that other systems pin to or chain from.

The common thread is lifetime. A session key lives for minutes; an IdP signing key or a code-signing key lives for years and is trusted by thousands of downstream verifiers. Long-lived, widely-trusted signing keys are exactly the assets that “forge later” puts at risk.

How to read this diagram: This flowchart traces the blast radius once a single federation signing key is forged. Because the IdP is the trust anchor, one compromised key lets the attacker mint tokens accepted by every relying party — HR, finance, cloud consoles, and source control alike. The right-hand branches show how that fans out into privilege escalation, financial fraud, and even CI/CD tampering, all without phishing a single user password. The bottom node makes the core point: this is not “an account was breached,” it is the federation’s root of trust being breached, which is categorically harder to detect and contain. This is precisely why post-quantum protection should start at the signing key, using approaches such as composite ML-DSA + Ed25519 signatures and verified on hardware-attested devices.

When is “later”? Reading the timelines honestly

Nobody can name the exact year a CRQC arrives, but the planning question is not “when does it arrive” — it is “when do I have to be ready.” That is the value of Michele Mosca’s theorem, often written as the inequality X + Y > Z:

• X = how long your data (or trust) must stay secure;
• Y = how long your migration to post-quantum cryptography takes;
• Z = how long until a CRQC exists.

If X + Y > Z, you are already too late if you start when the quantum computer appears. For an IdP signing key, X is effectively the service’s whole lifetime, and Y — migrating signing keys, JWKS, RP libraries, and SDKs — is measured in years. Mosca’s analysis is summarised in his “A cybersecurity threat for the quantum world” and related IACR work.

The authoritative timelines reinforce the urgency rather than relax it. The U.S. NSA’s CNSA 2.0 suite directs software- and firmware-signing to move to post-quantum algorithms first — explicitly because signing is the long-lived, hardest-to-roll asset — with broad adoption targeted well before 2035. NIST finalised its first post-quantum standards (including FIPS 204 / ML-DSA) in 2024 via the Post-Quantum Cryptography project, removing the “no standard yet” excuse. And transport-layer deployment is already real-world: Cloudflare’s post-quantum work reports that a large and growing share of TLS traffic already uses hybrid post-quantum key exchange. Encryption is migrating; signatures, the part SSO depends on, are the next front.

What can you do today?

The practical answer is hybrid (composite) signatures: pair a classical signature (such as Ed25519) with a post-quantum one (such as ML-DSA-87) so a token is valid only if both parts verify. You stay secure as long as either primitive holds during the transition — classical math protects you against weaknesses in young lattice assumptions, and the post-quantum half protects you against a future CRQC. CAI-AUTH issues OIDC tokens signed with a composite ML-DSA-87 + Ed25519 signature (algorithm id CAI-PQ-HYBRID-87-Ed25519, following draft-ietf-lamps-pq-composite-sigs).

Concretely, start here:

• Inventory your signing keys — IdP, federation, code-signing — and rank them by lifetime and blast radius.
• Prioritise the root of trust. The IdP token-signing key is the single highest-leverage key to make post-quantum first.
• Choose Category 5 for root keys. ML-DSA-87 is the strongest ML-DSA parameter set; details in our NIST FIPS 204 / ML-DSA engineer reference.
• Bind verification to trustworthy endpoints. Pair post-quantum signing with hardware attestation so approvals come from genuine secure elements, not rooted or emulated devices.
• Plan the migration as a programme, not a patch. Because Y is large, the calendar starts now.

You do not need a quantum computer in the room to justify this. You need to accept that a forged root of trust is a worse day than a decrypted session — and that the migration clock is already running.

FAQ

What is “harvest now, decrypt later”?

Harvest now, decrypt later is an attack where an adversary records encrypted data today and stores it until a future quantum computer can break the key exchange and decrypt it. It targets confidentiality of long-lived secrets, which is why post-quantum key exchange is being deployed even before quantum computers exist.

Does the quantum threat affect digital signatures, not just encryption?

Yes, and for SSO it is the more serious concern. A quantum computer running Shor’s algorithm could recover an IdP’s private signing key from its public key, letting an attacker forge tokens every relying party trusts. Unlike decryption, this is a federation-wide root-of-trust compromise — often called the “forge later” risk.

How soon is the quantum threat to authentication?

Treat it as a programme starting now. Mosca’s theorem (X + Y > Z) shows that if data shelf-life plus migration time exceeds time-to-quantum, you are already late. NSA’s CNSA 2.0 prioritises post-quantum signing well before 2035, and NIST standardised ML-DSA (FIPS 204) in 2024 — so the tooling exists today.

What can I do today to protect my SSO signing keys?

Adopt hybrid (composite) signatures that combine a classical algorithm like Ed25519 with a post-quantum one like ML-DSA-87, so tokens verify only if both parts hold. Start with your highest-blast-radius keys — the IdP token-signing key and federation trust anchors — and pair signing with hardware-attested verification.

See it live: inspect a working post-quantum OIDC discovery document and JWKS at auth.caitech.ro, and read about our patent-pending design at auth.caitech.ro/patents.