Marin Ivezic
Two Threats, Taught Unevenly
Most quantum-risk briefings spend their time on encryption. The story is familiar by now: an adversary records encrypted traffic today, stores it cheaply, and decrypts it years later once a cryptographically relevant quantum computer exists. That is Harvest Now, Decrypt Later, usually shortened to HNDL. NIST has standardised the replacement algorithms in FIPS 203, 204 and 205, and NSA’s CNSA 2.0 requires national security systems to complete their transition by 2035. Dates like that give the recording window a shape that planners can work with.
The other half of the problem gets much less classroom time, and it is the half we find architects and control-systems engineers are least prepared for.
A digital signature is a mathematical proof that a specific private key approved a specific piece of data. It is what lets a programmable logic controller decide that a firmware image really came from its vendor, what lets a browser decide that a certificate really belongs to a bank, and what lets a fleet of smart meters accept an over-the-air update. RSA and ECDSA, the Elliptic Curve Digital Signature Algorithm, carry most of that load today. Shor’s algorithm breaks both, and it breaks them in the same stroke that it breaks the encryption everyone is already worried about.
Trust Now, Forge Later, or TNFL, is the name for what follows. Marin Ivezic makes the case that it deserves at least as much attention as HNDL in his definition of the term.
Two Different Exposure Windows
The two risks look similar and are sized by completely different inputs, which is the practical reason they need separate treatment in a migration plan.
HNDL exposure is measured against data retention. Ask how long a given secret must stay secret, and if the answer is fifteen years, then the traffic you send this afternoon is already in scope. The clock started before you began planning.
TNFL works the other way round. A forgery has to be produced by an adversary who already holds the quantum computer, so nothing signed today becomes retroactively suspect the way recorded ciphertext does. What matters instead is which verifiers will still be checking RSA and ECDSA signatures on that future date, and how hard it will be to tell them to stop. The exposure window is set by deployment lifetime and by the mutability of the trust anchor, meaning the public key or root certificate that a device treats as its ground truth.
That distinction changes what you inventory first. Under HNDL you look for long-lived confidential data. Under TNFL you look for verifiers you cannot reach: secure boot keys fused into silicon, root certificates with twenty-year validity periods, firmware signing chains held by a vendor who may not exist in a decade, field devices whose maintenance window opens once a year during a planned outage.
What a Forged Signature Buys an Attacker
Two well-documented incidents show the value of an accepted signature, and neither of them needed a quantum computer.
The Stuxnet drivers were signed with code-signing certificates stolen from Realtek Semiconductor and JMicron Technology, so Windows loaded them without complaint. In the SolarWinds compromise, malicious code was inserted into the build pipeline before signing, so the update that reached approximately 18,000 customers was genuinely and correctly signed by the vendor. In both cases the attacker’s real achievement was arriving inside the trust boundary, and everything downstream behaved exactly as designed.
A quantum forgery capability removes the theft and the pipeline subversion from that sequence. An adversary who can derive a private key from a published public key does not need to break into a signing facility, and leaves no artifact for anyone to find later.
The consequence differs by domain. In IT, a forged signature mostly means unauthorised software running with legitimate provenance. In operational technology, meaning the industrial control systems, embedded controllers and instrumentation that run physical processes, the object being authenticated is often an instruction to a machine. The failure mode is a physical process doing the wrong thing while every log in the plant records a valid signature and a trusted source. Integrity failures in those environments are harder to detect than confidentiality failures, because there is nothing missing and nothing unusual to alert on.
Why the OT Migration Is the Hard One
Four constraints make signature migration slower in OT than in enterprise IT, and they compound.
Deployment lifetime. Industrial equipment is specified for decades of service, and the cryptography is frequently fixed in firmware or in hardware at manufacture. Devices being commissioned this year will still be verifying signatures well past 2035.
Maintenance windows. Updating a controller is not a click. It can require a process shutdown, a safety re-validation, and a scheduling negotiation with operations that happens once or twice a year. Security work competes with everything else in that window.
Size and compute. Post-quantum signatures are larger. An ML-DSA-44 signature under FIPS 204 runs to roughly 2,420 bytes with a 1,312-byte public key, against ECDSA signatures over the P-256 curve at 64 to 72 bytes depending on encoding, with public keys of 65 bytes uncompressed or 33 bytes compressed. Some legacy protocols have fixed-width fields that simply cannot carry that. Some controllers do not have the memory or the cycles.
Assurance and approval. Cryptographic changes in a safety-instrumented system touch certification. Regulators, insurers and equipment vendors all have a say, and none of them move at the speed of a patch cycle.
The standards work is further along than most teams realise. NIST SP 800-208 approves LMS and XMSS, stateful hash-based signature schemes whose security rests on hash functions rather than on factoring, specifically for firmware and software signing. FIPS 205 provides SLH-DSA (SPHINCS+) as a stateless option built on the same foundation, and FIPS 204 provides ML-DSA (CRYSTALS-Dilithium) as the general-purpose choice. NSA’s CNSA 2.0 places software and firmware signing at the front of its required transition sequence, ahead of most other use cases, precisely because of the lifetime problem described above.
What Migration Teams Need to Be Able to Do
Three capabilities separate organisations that will finish this work from organisations that will discover it in 2031.
The first is a signature inventory that is genuinely distinct from an encryption inventory. Certificates, signing keys, secure boot chains, update mechanisms, licence checks, audit-log signing, device identity. The awkward instances are rarely in the certificate management platform.
The second is crypto-agility, meaning the ability to change algorithm without changing the product. In practice that means indirection at the design level: algorithm identifiers carried in the protocol, key stores sized for larger keys, verification logic that can hold two algorithms at once during a transition. Retrofitting agility into a fielded device is usually impossible, which makes it a procurement requirement rather than an engineering task.
The third is a compensating-control strategy for everything that cannot be upgraded. Quantum-safe gateways that validate and re-sign commands ahead of legacy endpoints, tighter network segmentation, and an honest replacement schedule for equipment whose trust anchor cannot be moved.
This work is inventory discipline, architecture and vendor management rather than exotic cryptography, applied to a class of asset that most crypto-inventory projects skip. The methodology work at pqcframework.org covers the migration programme structure in more depth, and PostQuantum.com carries the deeper technical treatment of the algorithms themselves.
Where to Build the Skills
Signature migration fails on the same thing every time, which is that nobody on the team owns the question. Quantum Academy’s Post-Quantum Foundation program covers the algorithm families, the NIST transition timeline and the inventory work that has to come first. The PQCS certification track goes further into migration design, including crypto-agility requirements and the constraints that make embedded and OT environments different from everything else.
Both are available at quantumacademy.com/.