Every discussion of quantum computing and cryptography runs on the same rail: an adversary records encrypted traffic today and reads it once a sufficiently large machine exists. The case made in this examination of the cryptographic clock is the version most engineers have internalised, and it is correct as far as it goes. But it describes only the confidentiality half of public-key cryptography. The other half — signatures, provenance, notarisation, everything answering who made this and when — fails on a different clock, in the opposite direction, and its remedy stops working the instant the break arrives. That asymmetry is the most consequential thing in this transition that almost nobody has on a roadmap.
Verification Checks Math, Not History
A signature verifier is a pure function. It takes a message, a signature, and a public key, and returns a boolean. It has no access to when the signature was produced. It cannot distinguish a signature computed in 2019 from one computed in 2036 by someone who has recovered the private key and typed whatever date they liked into the metadata.
This is why the reassuring line — "signatures can't be harvested, so they're not urgent" — is technically true and practically misleading. Nobody un-signs your 2019 release artifact. What happens instead is that your 2019 release artifact stops meaning anything, because a forged one is now indistinguishable from it. The cryptographic property that dies is not integrity. It's discriminating power: the ability of a signature to separate the authentic from the fabricated. Once ECDSA falls, every classical signature ever produced collapses into the same evidentiary category as an unsigned file with a plausible date on it.
Work out where that lands in a normal engineering organisation and the surface is enormous. Signed Git tags and commits. Container image attestations and transparency-log entries. Notarised installers and driver packages. Signed firmware images sitting in devices that will still be deployed in 2040. SBOM attestations, build provenance, audit trails a regulator will want to inspect a decade from now. None of it is confidential. All of it is load-bearing.
The Timestamp Trap
The instinctive fix is a trusted timestamp. Wrap the artifact in an RFC 3161 token from a timestamp authority, or a qualified electronic timestamp under eIDAS, and you have third-party proof that the signature existed before a given moment. Long-term validation formats in the PAdES and CAdES families are built on precisely this idea, and over seventy jurisdictions grant such timestamps legal standing.
The trap: the timestamp authority signs its tokens with RSA or ECDSA. Break the TSA's key and an attacker doesn't merely forge documents — they mint backdated proof that the forgeries are old. The mechanism everyone is relying on to rescue historical signatures has exactly the same failure mode as the signatures it rescues, and it fails in the direction that manufactures false history rather than merely destroying true history.
Which produces the inversion at the heart of this piece. Confidentiality exposure is fixed at capture time. If a session was recorded in 2023 under classical-only key exchange, nothing you do in 2027 helps; that packet is already in someone's storage array. Forgery exposure is fixed at break time. An archive re-signed with post-quantum signatures and post-quantum timestamps before the break retains its evidentiary weight afterwards; the same archive left alone does not. Signatures are the half where action still changes the outcome — but only while the window is open, and the window closes without an announcement.
The Deadline That Arrives First Isn't TLS
The standards bodies already priced this in, and the ordering surprises most people who assume browsers lead. The NSA's CNSA 2.0 algorithms advisory sets the earliest deadline in its entire schedule for software and firmware signing: support and prefer by 2025, exclusive use by 2030. Web browsers, cloud services, and operating systems get until 2033. Networking equipment, 2030.
The rationale is stated plainly in NSA's own guidance: a quantum-resistant root of trust may be needed in firmware years before the rest of the system can catch up, because firmware is the component you cannot patch your way out of later. If a device shipping in 2027 validates its updates with ECDSA burned into a boot ROM, that device has no upgrade path at all once ECDSA falls. The signature verification code is the thing that would have to be replaced, and it is the thing gating replacement.
Note also what NSA specifies for that use case: not ML-DSA, and explicitly not SLH-DSA. Software and firmware signing is assigned the stateful hash-based schemes LMS and XMSS from SP 800-208, with the multi-tree variants HSS and XMSS^MT disallowed and LMS with SHA-256/192 named as the preferred parameter set. That choice has consequences most developers have never had to think about.
Stateful Signatures Break Your Deployment Model
Every signature scheme working engineers have used is stateless. Sign the same message twice with ECDSA and nothing bad happens. LMS and XMSS are not like this. They are Merkle trees over a finite supply of one-time keys, and each key index may be used exactly once. Reuse an index and you don't get a warning — you get catastrophic private key exposure.
Translate that into ordinary infrastructure practice and things start breaking immediately. You cannot snapshot a signing VM and restore it later; the restored image will re-issue indices the original already consumed. You cannot run two signers behind a load balancer from the same key material. Your disaster recovery runbook — restore last night's backup, resume service — becomes a key-compromise event. Blue-green deployments, autoscaling, container immutability, "cattle not pets": every reflex that makes modern deployment safe makes stateful signing unsafe.
This is the real reason NSA pushes signing into hardware security modules with hardware-managed state. It isn't ceremony. It's that the state is mutable, strictly non-replicable data whose accidental duplication destroys the key, and no ordinary deployment pipeline is designed to hold data with that property.
Bitcoin Is Running the Experiment in Public
If you want to see retroactive forgery risk play out with real money and a real deadline, watch Bitcoin, because it is the one system where the vulnerable public keys are already published forever and cannot be recalled.
Roughly 6.7 to 6.9 million BTC — over a third of circulating supply as of March 2026 — sit in outputs whose public keys are visible on-chain. That includes early pay-to-public-key outputs from the network's first years, every address that has ever been spent from, and every Taproot keypath spend. These aren't keys that might leak. They are published, permanent, and waiting.
The response has been two proposals. BIP-360 introduces a quantum-resistant output type. BIP-361, published in April 2026 under the title "Post Quantum Migration and Legacy Signature Sunset," goes further and proposes phasing out legacy ECDSA and Schnorr signatures entirely — first blocking new sends to vulnerable address types, then, years later, refusing to honour spends from them at all. Reporting on the developer backlash captures the conflict cleanly: the proposal would permanently freeze an estimated 1.7 million coins in ancient addresses whose owners are dead, lost, or gone, including roughly a million attributed to Satoshi.
Two details generalise well beyond cryptocurrency. First, the attack model the BIP authors describe is a covert bleed — derive keys quietly, move value slowly over months, never announce. Under that model the break becomes public knowledge long after it happens, which is precisely the scenario in which "we'll migrate when we see evidence" fails. Second, and more broadly applicable: BIP-361 is the first mainstream proposal to accept that when public keys are permanently published and a signature scheme is dying, the only real protection is to stop honouring the scheme. The freezing debate is fundamentally an argument about what to do with artifacts that cannot be re-signed. Every organisation holding a signed archive will eventually have some version of that argument, with auditors instead of miners.
What Actually Shrinks the Blast Radius
The good news is that the work is mostly unglamorous and mostly available now:
- Dual-sign new artifacts. Attach a post-quantum signature alongside the classical one rather than replacing it. Verifiers that don't understand the new algorithm ignore it; verifiers in 2035 have something that still discriminates. Cost is bytes and a second signing call.
- Anchor instead of re-signing at volume. For large evidence logs, build a Merkle tree over the records and post-quantum-sign the root. One signature covers millions of entries, and per-record proofs stay small — considerably cheaper than wrapping each entry individually.
- Migrate the timestamp authority before the end-entity certificates. A quantum-safe TSA can rescue classical signatures beneath it. A classical TSA cannot rescue anything, and can be used to fabricate history.
- Treat signing state as infrastructure, not configuration. If you adopt LMS or XMSS, index state needs the same rigour as a database primary: hardware-held, never restored from backup, never forked.
- Decide now what happens to artifacts you can't re-sign. Third-party notarisations, vendor-signed firmware in the field, records under legal hold. The answer may be "accept the loss," but that should be a decision with a date on it, not something discovered during a dispute.
The confidentiality story ends with a straightforward, if grim, conclusion: the data was taken, and it will be read. The provenance story ends somewhere stranger — with a dispute in which both parties hold signatures that verify, and no cryptographic means of telling which one is telling the truth. That outcome is still preventable today. It stops being preventable on a date that will not be announced in advance.
Top comments (0)