up:: Quantum Risk Models MOC

Forge-Later Attack

A forge-later attack is a quantum attack that recovers a private signing key from its already-public public key and uses it to forge signatures, certificates, and credentials that verify as genuine. It targets integrity and trust rather than secrecy, and it is the signature-side half of the quantum threat, the counterpart to the confidentiality-side harvest-now-decrypt-later risk. The word “later” names the one thing that is genuinely deferred: a signature or trust anchor created today stays trustworthy only until a cryptographically relevant quantum computer exists, so anything with a multi-decade lifetime is already living on that clock.

The short version:

1. Forge-later is an integrity and trust threat. It forges identity, it doesn’t recover stolen secrets.
2. It runs on the CRQC arrival clock, not a harvest clock. The attacker’s raw material, the public key, is already published, so there’s nothing to intercept and no advantage to recording anything in advance. The break needs a live quantum computer at the moment of the forgery.
3. The genuine “later”: a signature or trust anchor made today (a long-lived certificate, a code- or firmware-signing key, an archived signed record) becomes forgeable the day a CRQC arrives, so its integrity decays on the machine’s clock even though you signed it years earlier.
4. It is not the mirror image of HNDL. HNDL stages the attack now by recording ciphertext; forge-later can’t be staged, because key recovery needs only the public key plus the machine.
5. The fix is migrating signatures to ML-DSA or SLH-DSA before the machine arrives, and timestamping long-lived signatures so they can be proven to predate any forgery capability.

Picture a machine that reproduces anyone’s handwritten signature flawlessly, working only from a signature already printed in the newspaper. The machine won’t be built for another decade. Nothing about your signature is secret today, and nothing gets stolen in the meantime. The day the machine ships, though, every check you ever signed can be reproduced by anyone, and a bank in that future can’t tell your genuine old signature from a fresh copy. The danger was never in something captured in the past. It was always waiting on the machine.

Is a forge-later attack the same as harvest-now-decrypt-later?

No, and the difference is the whole point of naming it separately. HNDL stages its attack in the present: an adversary records encrypted traffic today, stores the ciphertext, and decrypts it years later once a quantum computer can break the key-establishment. The material to be broken is captured and warehoused now, which is exactly why HNDL is live today, the collection is happening while you read this.

A forge-later attack stages nothing. The thing an attacker needs to forge your signature is your public key, and public keys are published by design, sitting in X.509 certificates, in code-signing certificates, and in token-signing endpoints. There’s no traffic to intercept and no vault to breach, so recording anything in advance buys the attacker no head start. The break waits entirely on the hardware. Shor’s algorithm can compute a private key from a public key, but only on a machine large enough to run it, which does not exist yet.

That’s why the two risks run on two different clocks, and manufacturing a symmetry between them gets the timing wrong.

	Harvest Now, Decrypt Later	Forge-Later Attack
What it threatens	Confidentiality of data	Integrity and trust of signatures and identities
What’s captured in advance	Ciphertext, recorded and stored today	Nothing; the public key is already public
What the attacker waits on	A CRQC to break the key-establishment	A CRQC to recover the private signing key
When the damage lands	Later, when stored ciphertext is decrypted	Later, when a forged signature is presented and verified
The clock	Harvest clock: live today, because collection is happening now	CRQC arrival clock: exploitation waits on the machine
Primary replacement	ML-KEM (key establishment)	ML-DSA / SLH-DSA (signatures)

Source: P. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Computing, 1997, quant-ph/9508027.

How does a forge-later attack work?

A digital signature is trustworthy because only the holder of the private key can produce one, and anyone can verify it against the matching public key. Quantum computing breaks that one-way relationship, and the attack runs in four moves:

1. Pick a public target key. Root and intermediate CA keys, identity-provider signing keys, code-signing and firmware-signing keys. All published information.
2. Recover the private key. Run Shor’s algorithm on a live CRQC to compute the private signing key from the public one. For an ECDSA P-256 key that means a machine on the order of a few thousand logical qubits, far beyond anything that exists today.
3. Forge. With the private key in hand, the attacker mints fraudulent certificates, forges authentication tokens, signs malware and firmware, and signs fraudulent transactions.
4. Present the forgery. A relying party verifies the forged artifact and it passes, because the signature is mathematically correct. The key is real, the math checks out, and there’s no way to tell the forgery from the genuine article without out-of-band trust.

The key-recovery step needs no access to the victim and no captured material. It works from the public key plus the machine, which is what puts forge-later on a single dependency: the arrival of a CRQC.

Source: Martin Roetteler, Michael Naehrig, Krysta M. Svore, Kristin Lauter, “Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms,” ASIACRYPT 2017, arXiv:1706.06752.

Which signatures decay on the forge-later clock?

The genuine “later” lives in long-lived trust, the signatures and anchors that must stay verifiable for years or decades. Those are exactly the ones a forge-later attack ruins, because their trust horizon runs straight into the quantum timeline:

1. Roots of trust. Root and intermediate Certificate Authority keys anchor whole hierarchies, so breaking one forges every certificate beneath it. This is the worst case, a PKI collapse.
2. Code and firmware signing. A recovered code-signing key produces signed malware that passes verification on every device that trusts the certificate, and firmware signed under a classical key stays in circulation for the life of the hardware.
3. Archived signed records. A contract, audit log, or legal instrument RSA-signed or ECDSA-signed today may need to hold up in 2040, well after the machine could exist.
4. Long-lived credentials and tokens. Identity-federation and token-signing keys that stay in service for years.

There’s a second, subtler failure here beyond fresh forgeries. Once forgery capability exists, a verifier in the future faces a genuine ambiguity: a classical signature that checks out could be the honest one made today, or a forgery minted after the private key was recovered, and the signature alone can’t tell them apart. The mere future existence of a CRQC retroactively weakens the evidentiary strength of every classical signature still in play, including ones produced honestly years earlier. That’s why long-lived non-repudiation is the hardest case, and why the roots of trust migrate first.

Source: NIST, “Transition to Post-Quantum Cryptography Standards,” NIST IR 8547 (Initial Public Draft), November 2024, csrc.nist.gov/pubs/ir/8547/ipd.

NIST, “Stateless Hash-Based Digital Signature Standard,” FIPS 205, August 2024, csrc.nist.gov/pubs/fips/205/final.

Does capturing signed material now help the attacker?

Mostly not, and this is where the “harvest” framing falls apart. Recovering a private signing key needs only the public key, which is already published, so recording signatures or signed traffic in advance buys the attacker nothing toward the break. There is no harvest step that speeds a forge-later attack the way recorded ciphertext is the whole substance of an HNDL attack. A blanket claim that adversaries are “harvesting signatures now to forge later” doesn’t hold up, and it’s worth cutting rather than repeating.

The narrow exception is real but secondary, and it never touches the key-recovery step:

1. Blending a forgery into a real record. An attacker who retains genuine signed artifacts and their surrounding context now can, once a CRQC lets them forge, craft forgeries that fit a historical record they couldn’t otherwise reconstruct, which makes a fabricated old document harder to distinguish from a genuine one.
2. Enabling repudiation. Because forgery capability retroactively muddies old signatures, a dishonest signer can later disown a document they genuinely signed, arguing anyone could have forged it once the machine existed. Holding the signed record shapes which of those disputes are exploitable.

Both of these ride on the same underlying fact, that a long-lived classical signature loses its evidentiary strength once a machine can forge it. Neither one puts the forgery on a harvest clock. The clock is still the arrival of the CRQC.

Is “Harvest Now, Forge Later” a real term?

Some vendors market the signature-side risk as “Harvest Now, Forge Later” (HNFL) or “integrity harvesting,” positioned as the tidy mirror of HNDL. It reads well and it’s easy to remember, and it’s misleading in the same move. The harvest framing imports a symmetry that isn’t there: there is no meaningful harvest step, because the target public key is already public and nothing an attacker records in advance advances the forgery.

None of those labels is an established standard term in the NIST or NSA literature, which describes the threat plainly as the migration of digital-signature and authentication algorithms ahead of a CRQC. The accurate description is the one this note uses, a signature-integrity threat on the CRQC clock. Naming it after harvesting borrows HNDL’s present-tense urgency for a risk whose exploitation genuinely waits on the machine, which muddles exactly the timing a team needs to get right.

Why is a forge-later attack urgent if the machine is years away?

Exploitation waits on the CRQC, but the planning problem is live now, for one reason: signature and PKI migration takes years, and it has to finish before the machine exists. This is a straight Mosca’s theorem argument, X + Y > Z. For a root CA key the required trust lifetime (X) is effectively “until migration is done,” and the migration time (Y) is long, so if the break horizon (Z) lands first, future forgery is being locked in by present inaction.

1. Migration lead time is the binding constraint. Moving a PKI means updating trust stores, distributing new roots, rebuilding certificate hierarchies, and getting vendor-controlled signing services onto post-quantum algorithms. For a large estate that runs into years.
2. Vendor surfaces can’t move unilaterally. Operating-system trust stores, public CA root programs, and identity-platform migrations all carry external dependencies that stretch the timeline past what internal teams expect.
3. Long-lived signatures made today are already gambling. Because of the retroactive-ambiguity problem, a decades-lived signature produced now with a classical algorithm is betting that a CRQC never arrives inside its trust horizon.

The deadlines are written down. NIST IR 8547 puts the quantum-vulnerable public-key families on a schedule to be deprecated after 2030 and disallowed after 2035, and CNSA 2.0 sets 2035 as the completion date for migrating national-security systems.

Source: Michele Mosca, “Cybersecurity in an Era with Quantum Computers, Will We Be Ready?” IEEE Security & Privacy, 2018, ieeexplore.ieee.org.

NIST IR 8547 (Initial Public Draft), “Transition to Post-Quantum Cryptography Standards,” November 2024, csrc.nist.gov/pubs/ir/8547/ipd.

What replaces the vulnerable signatures?

The durable fix is migrating the signing algorithms themselves to the NIST post-quantum signature standards, whose security doesn’t fall to Shor’s algorithm:

Replace	With	Best for
ECDSA / RSA signatures	ML-DSA	General-purpose signing (primary choice)
ECDSA / RSA signatures	SLH-DSA	Stateless, conservative, very long-lived roots of trust
ECDSA / RSA signatures	FN-DSA	Constrained signature size and speed

Two structural measures address the long horizon:

1. Timestamp long-lived signatures. A timestamp authority that records when a signature existed (RFC 3161) can establish that a signature predates any plausible quantum forgery capability, which preserves its evidentiary value even for signatures already made.
2. Bridge with transitional structures and build for crypto-agility. Composite certificates carry both a classical and a post-quantum algorithm so post-quantum-aware verifiers get post-quantum security while older ones still work, and cross-certification lets an existing CA vouch for a new post-quantum CA before trust stores update everywhere. PKI that hardcodes its signing algorithm faces the longest migration.

Some things that look like fixes aren’t. Reissuing end-entity certificates without migrating the CA’s own signing key leaves the real forge target untouched, certificate pinning pins a still-vulnerable classical certificate, and bumping an RSA key to 4096 bits buys almost nothing against Shor’s algorithm.

Source: NIST, “Digital Signature Standard (DSS),” FIPS 186-5, February 2023, csrc.nist.gov/pubs/fips/186-5/final.

Common misconceptions

1. “Forge-later is just HNDL for signatures.” HNDL stages the attack by recording ciphertext now; forge-later stages nothing, because the public key is already public. They run on different clocks, and treating them as mirror images mis-sequences the work.
2. “Attackers are harvesting signatures now to forge later.” Recovering the private key needs only the already-public public key, so recording signatures buys the attacker nothing toward the break. The harvest framing doesn’t survive contact with the mechanism.
3. “If the machine is years away, signatures I make today are safe.” A signature that must stay trustworthy for decades becomes forgeable the day a CRQC exists, and honest old signatures turn ambiguous unless a trusted timestamp fixes them in time.
4. “A bigger RSA key protects my signatures.” Shor’s algorithm scales polynomially in key length, so RSA-4096 raises the quantum cost only modestly. The fix is a post-quantum signature, not a larger classical one.
5. “Reissuing my end-entity certificates fixes it.” If the CA’s own signing key is still classical, the actual forge target is untouched. The migration has to reach the roots.
6. “Forge-later only matters to governments.” Any long-lived trust anchor is exposed: code signing, firmware signing, signed contracts, and long-lived credentials all carry high consequence if their signatures become forgeable.

Questions people ask

What’s the difference between a forge-later attack and harvest-now-decrypt-later? HNDL is a confidentiality threat that stages itself now by recording encrypted traffic to decrypt later, so it’s live today because collection is happening today. A forge-later attack is an integrity threat that stages nothing, because the public key is already public, so its exploitation waits on a working quantum computer. Different clocks, different fixes.

Do attackers need to record my signatures now? No. Recovering the private key needs only the public key, which is already published, so there’s no harvest step and no advantage to capturing signatures in advance. The one narrow exception is that retained signed records can later help an attacker craft a forgery that blends into a real history, but that never speeds the key recovery.

When does a forge-later attack become possible? Once a CRQC exists that can run Shor’s algorithm against real-world key sizes. No such machine exists today, and credible estimates for its arrival span roughly 2030 to 2040 and beyond.

Why migrate signatures now if forgery needs a machine that doesn’t exist yet? Because signature and PKI migration takes years and has to finish before the machine arrives, which is the Mosca’s theorem argument. A long-lived signature made today with a classical algorithm is already betting that no CRQC lands inside its trust horizon.

Which signatures should migrate first? The highest-blast-radius trust anchors: root and intermediate CA keys, code-signing and firmware-signing keys, and identity-federation signing keys. These take the longest to rotate and carry the widest consequence if forged.

Does a timestamp protect an old signature? Yes, within limits. A trusted timestamp (RFC 3161) records that a signature existed at a point in time before any quantum forgery capability, which preserves its value as evidence. It’s a core mitigation for archives and legal records that can’t be re-signed.

Is “Harvest Now, Forge Later” a standard term? No. It’s vendor phrasing, not NIST or NSA terminology, and the harvest framing is misleading because there’s no meaningful harvest step. The accurate description is a signature-integrity threat on the CRQC clock.

What replaces the vulnerable signature algorithms? ML-DSA for general-purpose signing and SLH-DSA for conservative, long-lived roots of trust, with FN-DSA where signature size and speed are constrained. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are finalized NIST standards; FN-DSA (FIPS 206) is a draft expected to finalize in late 2026 or early 2027. All three resist Shor’s algorithm.

What’s the worst case? A broken root Certificate Authority key, which makes every certificate in its hierarchy forgeable at once. That’s PKI collapse, the highest-blast-radius outcome of a forge-later attack, and there’s no clean after-the-fact recovery, which is exactly why the migration has to be pre-emptive.

---

Everything here is the map, given freely. When your team needs the signatures and trust anchors that carry your integrity found, sized, and sequenced onto a post-quantum path before the machine arrives, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.