Marin Ivezic
A compliance lead at a European bank opens four browser tabs on a Monday morning in 2026. The bank holds US defense contracts, runs an Australian branch, and books trades through a Singapore subsidiary. Each tab carries a national position on post-quantum cryptography. No two of them agree.
The first says that from 2027, new acquisitions for US national security systems are expected to meet the NSA’s Commercial National Security Algorithm Suite 2.0. The second says Germany’s federal information security agency, the BSI, expects hybrid deployments, built from an algorithm list that no other country publishes. The third says Australia’s Signals Directorate wants classical public-key cryptography retired by the end of 2030, and does not recommend hybrid. The fourth sets out the UK’s phased approach, published as guidance rather than statute: a cryptographic inventory and a costed migration plan by 2028, migration complete by 2035.
One migration program has to satisfy all four.
More than a dozen national authorities have now published post-quantum guidance. They agree that quantum computers will eventually break RSA and elliptic-curve cryptography, and that organizations should move to the new standards. On sequencing, on configuration, and on enforcement, they part company. This is a field guide to the disagreement, and to building one plan that meets all of it.
The 2035 number and what it hides
Line the endpoints up and the picture looks orderly. NIST’s transition guidance, IR 8547, would disallow quantum-vulnerable algorithms in US federal systems after 2035. The UK’s National Cyber Security Centre puts the end of its third phase at 2035. The EU’s coordinated roadmap, agreed through the NIS Cooperation Group, targets 2035 for full migration. Canada’s federal timeline ends in the same year.
The agreement is real, but it is arithmetic rather than coordination. Most agencies worked from the same three inputs: the NIST standardization schedule, the estimated arrival window for a cryptographically relevant quantum computer – a machine large enough to recover private keys from public ones – and the decade or more that large enterprises need to replace cryptography across a full estate. Start in the mid-2020s, allow ten years, and 2035 falls out.
The number does damage in board packs. Nine years reads as comfortable, and comfortable dates get deferred. We track these deadlines because our learners keep arriving with the same sentence already circulating internally: we’re aligned with global timelines, so this belongs in the 2030 plan. 2035 is when the work has to be finished. The dates that decide this year’s budget are 2026, 2027, and 2030.
The deadlines inside this decade
Between now and the end of 2030 the pressure concentrates. A partial list, with the reason each one bites.
September 2026. FIPS 140-2 certificates move to the historical list. Not a post-quantum deadline, but it forces a cryptographic module refresh that competes for the same budget and the same engineers.
End of 2026. The first phase of the EU roadmap closes, covering national strategies, cryptographic inventories, and pilot deployments.
2027. New acquisitions for US national security systems are expected to be CNSA 2.0 compliant, on the transition timeline the NSA publishes with the suite. For vendors selling into that market, that is months of runway rather than years.
Late 2027. The main obligations of the EU Cyber Resilience Act apply, 36 months after the regulation entered into force. Products sold in the EU have to remain updatable across their support period, which in practice means being able to change cryptographic algorithms in the field.
2028. The end of the first phase in the UK’s published timeline: discovery and a costed migration plan. Guidance, with no statutory force behind the date.
2030. The heaviest year. Australia retires classical public-key cryptography. CNSA 2.0 moves networking equipment to exclusive post-quantum use. The EU roadmap wants critical infrastructure migrated. Germany expects regulated operators of essential services to have finished. NIST’s guidance deprecates 112-bit security.
Four years isn’t much against a decade-scale replacement program. Most large organizations are already inside the window.
Three places the guidance conflicts
Hybrid or pure post-quantum
Hybrid means running a post-quantum key exchange alongside a classical one, so the session key stays secret unless both are broken. This is the disagreement that costs the most to get wrong, because it is a configuration decision taken once per protocol and then inherited by every deployment.
Germany and France require it. The BSI codifies hybrid in its technical guideline for cryptographic mechanisms, and France’s cybersecurity agency, ANSSI, extends the requirement to signatures as well as key establishment. Australia goes the other way, does not recommend hybrid, and treats pure post-quantum at high parameter sets as the target from day one. CNSA 2.0 permits hybrid through the transition and then closes the window, ending in exclusive post-quantum use.
A single VPN configuration can’t be hybrid and pure at the same time. Either you run different configurations per region, or you pick one and accept future rework. We teach hybrid first, for two reasons. It meets the strictest current requirements while staying inside the permissive ones, and it keeps a classical fallback in place while the new algorithms are still young. The design requirement is the ability to drop the classical half later without rebuilding the stack around it.
Algorithm lists
Almost every jurisdiction in this article works from the NIST suite: ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures, with FN-DSA and HQC still to come. China is the exception, and is standardizing on a separate national track. Everywhere else the divergence is additive rather than subtractive.
The BSI also recommends FrodoKEM and Classic McEliece, both chosen for conservative security arguments rather than performance. South Korea ran its own national competition, KpqC, and selected HAETAE, AIMer, SMAUG-T, and NTRU+, none of which were in the NIST process.
This is a procurement and interoperability problem rather than a cryptography problem. An organization that hardcodes one parameter set into its libraries meets most requirements today and has nowhere to go when a German contract asks for FrodoKEM support, or a Korean partner needs SMAUG-T on the other end of the connection.
Scope and enforcement
The third disagreement is about consequences. At one end sit instruments with market access attached. The Cyber Resilience Act is product law, and a device that can’t be updated can’t be sold in the EU. The CNSA 2.0 acquisition gate is procurement, so failure shows up as a lost bid rather than a fine. At the other end sits guidance with no statutory force, including the UK’s phased timeline and most of the roadmaps published across Asia.
Treating non-binding as non-urgent is the expensive mistake. The NCSC can’t penalize anyone for missing 2028. UK financial and data regulators, though, use NCSC publications as their reference for reasonable practice, and any incident review will ask why the national authority’s published timeline was set aside. Guidance becomes enforceable through liability and through customer contracts long before it becomes law.
Build the map before the plan
The strategic conclusion is short. Your effective deadline is the earliest binding date in any jurisdiction where you operate, sell, or hold a contract. Everything after that is sequencing.
Getting to that date takes four steps, and we run them as a workshop exercise before anyone touches an architecture diagram.
- List obligations, not offices. Markets you sell into, regulated clients, contracts with government or defense customers, and the jurisdictions your data rests in. A subsidiary with no local regulator can still inherit a deadline from a client’s supervisor.
- Attach a date and a source to each. A date without a citation is unusable within a quarter. Record the document name and the clause, so the next reviewer can check it rather than re-derive it.
- Record the constraints, not just the date. Hybrid or pure, permitted algorithm list, and whether the obligation falls on your systems or on the products you ship. Two jurisdictions with identical dates can still require different builds.
- Set a review cadence. Quarterly is enough for most estates. Draft standards become final, roadmaps acquire implementing acts, and dates move in both directions.
The earliest date in the second column sets your first milestone. Work backwards from there, not from 2035.
What everyone agrees on
Three points of consensus should shape planning more than any single deadline.
Harvest now, decrypt later is treated as a present threat everywhere. An adversary copies encrypted traffic today and decrypts it once a capable machine exists. That makes key establishment the first migration target and long-lived confidential data the first thing to protect, ahead of signatures and short-lived transactional traffic.
Crypto-agility is universal. Every framework either requires it or assumes it. Being able to change algorithm, parameter set, and mode without rebuilding the application is the one investment that pays out under every timeline in this article rather than one of them.
The NIST suite is the safe starting point. Among the jurisdictions that use it, the divergence is about what to add, never about what to remove. Beginning with ML-KEM and ML-DSA is compatible with every jurisdiction named here apart from China, and the standards behind them are final: FIPS 203 and FIPS 204 were published in August 2024.
This article has a shelf life
Guidance changes. Draft transition documents become final, administrations revise dates, and voluntary roadmaps acquire implementing acts underneath them. Every date here should be re-checked against its primary source before it enters a board pack or a supplier questionnaire. The same applies to the deadline table your program office maintains, which is why the fourth step exists.
Where to take this next
The methodology for turning a jurisdiction map into a sequenced migration program is published at pqcframework.org. Deeper technical analysis of individual national positions, including the source timeline behind this article, sits at PostQuantum.com.
For structured training, Quantum Academy takes teams through cryptographic inventory, jurisdiction mapping, the hybrid decision, and the crypto-agility architecture that every timeline in this article depends on. Learners finish with a defensible first milestone and a map they can hand to procurement.