Marin Ivezic
Boards hear the Y2K comparison in nearly every quantum briefing, and it does honest work. An executive sponsor has to justify spending in 2026 against a failure that hasn’t happened yet, and Y2K is the one precedent most of the people in the room lived through. It gives them a reference for scale, for cost, and for the uncomfortable political position of asking for money whose success looks identical to having done nothing.
The trouble is the conclusion the comparison delivers for free. Y2K is widely remembered as the disaster that never arrived, and that memory travels with the analogy whether anyone says it aloud or not.
What Q-Day means
Q-Day is the point at which someone operates a cryptographically relevant quantum computer, or CRQC: a machine large enough and stable enough to run Shor’s algorithm against the public-key cryptography in production use today. RSA and elliptic-curve cryptography both fail against such a machine. Symmetric encryption such as AES and the hash functions underneath it are affected much less, so the exposure concentrates in two places, key exchange and digital signatures. That covers TLS on every website, VPN tunnels, code signing, payment authorisation, and the certificate hierarchies that hold all of it together.
Nobody knows the date. Estimates vary widely, and nobody offering one claims certainty. Post-quantum cryptography, or PQC, is the replacement set of public-key algorithms designed to resist that attack. NIST published the first three as federal standards in August 2024: ML-KEM (formerly CRYSTALS-Kyber) for key establishment, and ML-DSA and SLH-DSA for signatures.
What the comparison gets right
Every system, every supplier. Y2K was not a project that one team completed. It reached into mainframe code, operating systems, embedded controllers, and the products of hundreds of third parties, and it forced organisations to ask vendors questions they had never asked before. A PQC migration works the same way. Web servers, hardware security modules, certificate authorities, firmware update chains, industrial controllers, and every supplier who signs a binary are all in scope. No single product delivers quantum readiness, whatever the datasheet claims, because the dependency runs through code your organisation did not write.
The spend comes before the symptom. Y2K budgets had to be approved while everything was working. That is exactly the position a CISO is in now. On Q-Day itself, nothing visible breaks. Sites load, payments clear, and the failure is silent by construction, because an adversary reading traffic has every reason to keep it that way. Both threats live in the background of normal operations until a moment that arrives without an alarm.
The failure map is unknown in advance. Y2K teams did not know which systems would misbehave, which is why so much of the effort went into discovery and testing rather than remediation. The same holds here, and for the same reason: most organisations cannot currently produce a list of where they use public-key cryptography, in which protocol versions, with which key sizes, under whose ownership. Discovery is the long pole in both programmes.
Where the comparison misleads
Y2K had a physical date. Q-Day has regulatory ones. January 1, 2000 was fixed by the calendar, and every project plan hung off it. Q-Day has no such anchor, and organisations that wait for one will wait past the point where the work is deliverable. What exists instead are dates set by standards bodies and regulators. NIST’s draft transition report, IR 8547, proposes deprecating RSA and elliptic-curve cryptography after 2030 and disallowing them after 2035, and it remains a draft whose dates could move before it is final. NSA’s CNSA 2.0 sets its own milestones for United States national security systems and the vendors who serve them. Dates like these bind procurement, contracts, and audit findings well before any quantum computer exists, and they are the schedule a board should actually plan against.
Y2K could not be exploited early. Q-Day already is. There was no way to attack the millennium bug in 1997, because the date had not arrived. The quantum case allows exactly that, through a strategy known as harvest now, decrypt later, or HNDL: an adversary copies encrypted traffic today, stores it, and decrypts it once a CRQC exists. That inverts the risk calculation for any data with a long confidentiality requirement. Patient records, sealed legal material, source code, diplomatic traffic, and long-lived credentials are all exposed by an interception that has perhaps already happened. A Y2K fix delivered on December 30, 1999 would have worked. A PQC migration completed in 2032 does nothing for data captured in 2026.
Y2K ended. This does not. Once the date rolled over and the straggler bugs were cleared, the problem was closed and the teams disbanded. Now, this is the part that changes the budget line rather than the project plan: post-quantum migration has no equivalent moment. The standards are new, cryptanalysis of them continues, key and signature sizes affect protocols in ways the field is still discovering, and some devices will need redesign rather than patching. What the work produces, if it is done well, is crypto-agility: the ability to change cryptographic algorithms without re-engineering the systems that depend on them. That is a permanent capability with an owner and a running cost, and it is the difference between funding a project and funding a function.
Using the precedent properly
The useful reading of Y2K is that tens of thousands of engineers spent several years making sure the sky held, under governance that most organisations have since dismantled. Three parts of that governance transfer directly.
- A cryptographic inventory that names an owner for each finding. Y2K programmes lived or died on the completeness of the code survey. The same applies here, and the discovery phase reliably takes longer than the remediation estimate assumes.
- Prioritisation by data lifetime, not by system criticality. HNDL means the first systems to migrate are the ones carrying secrets that must stay secret into the 2040s, which is rarely the same list as the tier-one application register.
- Board reporting against dated external milestones. A programme measured against CNSA 2.0, sectoral guidance, and the dates written into customer contracts survives leadership changes. A programme measured against a threat with no date does not.
For migration methodology in depth, the Post-Quantum Cryptography Framework sets out the phases and the artefacts each one produces, and PostQuantum.com carries the technical background on algorithm selection and hybrid deployment.
Where to start
We see most quantum readiness programmes stall at the same point: the sponsor understands the threat and cannot yet distinguish a real migration plan from a vendor’s roadmap. That gap is a knowledge problem before it’s a budget problem, and it closes faster than executives expect.
We built Quantum Academy’s Post-Quantum Foundation program for exactly that reader. It covers what a CRQC can and cannot do, how the NIST standards differ in practice, how to scope a cryptographic inventory, and how to read the regulatory timelines that will set your programme’s deadlines. Start at quantumacademy.com/.