Post-Quantum Cryptography Has a Deadline Now

For most of the last decade, post-quantum cryptography was a research programme with a vague deadline attached. That ended in 2024, when NIST published the first finished standards, and again in June 2026, when the United States put dates on the migration. Organisations still describing quantum readiness as a five-year research item are not behind on the mathematics. They are behind on the paperwork.

The Algorithms Have Names

The schemes that appeared on every conference slide as CRYSTALS-Kyber and CRYSTALS-Dilithium are now FIPS 203, ML-KEM, for key establishment; FIPS 204, ML-DSA, for signatures; and FIPS 205, SLH-DSA, a stateless hash-based signature scheme kept as a conservative fallback. HQC, a code-based key-encapsulation mechanism, was selected in March 2025 as a second KEM and is being drafted as FIPS 207. Using the old names is not merely dated. It makes procurement language ambiguous, because vendors have shipped products under both naming schemes and will happily let you buy the wrong one.

The 2026 Calendar

The dates that matter are mostly American, and mostly already in force:

• 22 October 2026: federal agencies were due to submit cryptographic inventories and migration plans under OMB M-26-15, which followed Executive Order 14412 in June.
• 1 January 2027: CNSA 2.0 applies to new national-security system purchases, so anything bought after that date is expected to be quantum-resistant at the point of sale.
• 31 December 2030: key establishment must be quantum-resistant in federal high-value assets and high-impact systems.
• 31 December 2031: digital signatures must be as well. The order applies to those systems rather than every federal computer; the rest follow a five-phase schedule running to 2035.
• 2030 and 2035: NIST IR 8547 deprecates, then disallows, RSA, ECDSA, ECDH and DSA in federal systems.

Outside the United States the dates are advisory rather than binding. The UK's NCSC and co-ordinated EU guidance both point to 2035 for completion, with earlier dates for high-value systems. Advisory does not mean optional. The same vendors build for the strictest customer, and the same auditors read the strictest standard, so a supplier outside the federal market will still be asked where its migration plan is.

Harvest Now, Decrypt Later — But Not For Everything

The phrase has done useful work making the threat concrete, and it has also produced a lazy conclusion: that all data not protected by post-quantum cryptography should be treated as public by 2030. The actual exposure is a function of how long the data must stay confidential compared with how long the migration takes. A signed contract with a ten-year confidentiality term is exposed. Last quarter's marketing metrics are not. That distinction is the whole basis for prioritisation, and it is the reason an inventory is worth more than a strategy document.

Confidentiality is only half of it. Signatures have a separate clock, and the exposure is longer-lived than most teams expect: firmware images that must verify for a decade, code-signing certificates, document signatures, and the certificate chains underneath them. A signature that must remain valid in 2035 cannot be produced with an algorithm scheduled for deprecation in 2030.

What Is Already Hybrid

The browser transition is further along than the average enterprise plan. Chrome and Firefox negotiate the hybrid X25519MLKEM768 group by default, and the major TLS libraries support it. Hybrid matters: combining a classical and a post-quantum exchange means a break in either one does not sink the connection, and it buys time while the ecosystem matures. Certificate authorities and code-signing infrastructure lag behind the transport layer, which is why signing is the harder half of the programme even though it has the later deadline.

An Inventory You Can Finish

Cryptographic discovery is where these projects stall, because the honest answer is usually that nobody has a complete list. Start with what can be enumerated:

• External endpoints: every TLS service you expose, with the library and version behind it.
• Long-lived secrets: certificates, signing keys, VPN and device credentials, and the hardware that stores them.
• Embedded and OT systems: the equipment that will still be running in 2035 and cannot be patched, which is where the real replacement budget sits.
• Suppliers: one question, asked in writing — when will this product support ML-KEM and ML-DSA, and will the upgrade require replacing hardware?

Then design for crypto-agility rather than for a single algorithm. Algorithm identifiers, key sizes and certificate handling should be configuration, not constants compiled into firmware, or the next transition will cost exactly what this one does. The organisations that handle 2030 well will not be the ones that migrated fastest. They will be the ones that can answer, without a project, which systems use which cryptography and who owns each one.