The Global PQC Migration Clock: Where Every Country Stands and Why the Gaps Between Them Matter More Than the Deadlines Themselves

A CISO at a European bank with US defense contracts, Australian operations, and a Singapore subsidiary sits down in mid-2026 to build a PQC migration plan. She opens four browser tabs.

Tab one: CNSA 2.0 says new acquisitions for US National Security Systems must be compliant by January 2027. That’s six months away. Tab two: Germany’s BSI mandates hybrid PQC for critical infrastructure by 2030, using an algorithm list that includes FrodoKEM and Classic McEliece (algorithms that appear in no other country’s guidance). Tab three: Australia’s ASD says stop using classical asymmetric crypto entirely by end of 2030, and explicitly does not recommend hybrid. Tab four: The Bank of Israel required a board-approved quantum preparedness plan six months ago.

Four jurisdictions, four different answers to the same question. Not just different dates, but different positions on whether hybrid mode is required, forbidden, or optional. Different algorithm portfolios. Different scopes. Different enforcement mechanisms. And she needs one migration plan that satisfies all of them simultaneously.

This is the state of global PQC migration in 2026. Fifteen-plus countries have weighed in. They all agree quantum computers will eventually break current public-key cryptography. They all agree organizations should migrate to post-quantum algorithms. They disagree on almost every implementation detail.

I keep tracking these deadlines across jurisdictions, building the Global PQC Migration Timeline that maps all 60+ milestones, and writing individual analyses of each country’s approach. This capstone article pulls together what the individual pieces cannot: the patterns that emerge when you lay every jurisdiction’s timeline on the same axis, the conflicts that create real compliance problems for multinationals, and the strategic conclusions that should drive your planning.

The 2035 Mirage

Every major jurisdiction converges on the same outer boundary. The United States (NIST IR 8547) targets 2035 for full disallowance of quantum-vulnerable algorithms. The UK (NCSC Phase 3): end of 2035. The EU (NIS Cooperation Group roadmap): 2035. Canada: end of 2035. Japan: 2035. South Korea: 2035.

This convergence is not coincidental. Most national cybersecurity agencies calibrate their outer timelines against the same inputs: the US NIST standardization schedule, the estimated CRQC arrival window, and the enterprise migration study estimates of 8–15+ years for large organizations. If you start in 2024 and need 10 years, 2035 is where you land.

The 2035 consensus creates a dangerous illusion of alignment. Board presentations cite “2035” as the deadline, and the comfortable distance makes it easy to defer action. I’ve sat through executive briefings where “aligned with global timelines” meant “we have nine years, so this can wait.”

The reality is that 2035 is the date by which you must be finished. The dates by which you must have started, and in many cases completed critical-system migrations, are 2026, 2027, 2028, and 2030. Those intermediate milestones are where the jurisdictions diverge, where the compliance pressure actually bites, and where most organizations are already behind.

The 2026–2030 Squeeze

Between mid-2026 and the end of 2030, I count 14 hard or near-hard deadlines across the jurisdictions I track. A partial list:

FIPS 140-2 sunset arrives in September 2026. All FIPS 140-2 certificates move to Historical status, and federal procurement requires FIPS 140-3 validated modules. This is not a PQC deadline per se, but it forces a cryptographic module refresh cycle that coincides with (and competes for resources with) PQC migration.

Canada’s CCCS requires departmental migration plans by April 2026. The UAE’s Cybersecurity Council mandates approved migration plans on a similar timeline. The Bank of Israel already required board-approved preparedness plans by January 2026. The EU NIS Cooperation Group expects Phase 1 (national strategies, inventories, pilots) by end of 2026.

Then CNSA 2.0’s acquisition gate hits in January 2027: every new purchase for US National Security Systems must be compliant. The EU Cyber Resilience Act reaches full compliance around 2027, requiring products sold in the EU to support cryptographic algorithm updates throughout their lifecycle.

Australia’s ASD expects critical systems to begin transition by end of 2028. India’s NQM Task Force targets CII migration between 2027 and 2029.

By 2030, the squeeze tightens. CNSA 2.0 requires exclusive use of PQC for networking equipment and firmware. The EU roadmap targets CII and high-risk use cases migrated. Germany’s BSI sets full migration for KRITIS-regulated entities. Australia says classical asymmetric crypto must be eliminated entirely. NIST IR 8547 deprecates 112-bit algorithms. EO 14144 requires TLS 1.3 across all US federal systems.

That’s a lot of pressure concentrated in 48 months. And these are not “nice to have” targets. Several carry real enforcement consequences, a topic I examine separately in Who Actually Enforces PQC Deadlines?

Three Axes of Divergence

The 2035 convergence hides three distinct axes along which national approaches actively conflict.

Axis 1: Hybrid vs. Pure PQC

The single most consequential divergence for implementation architects is whether to deploy PQC algorithms alongside classical ones (hybrid mode) or replace classical algorithms entirely (pure PQC). I cover this in depth in The Hybrid Question, but the summary positions are:

Hybrid mandatory: Germany’s BSI and France’s ANSSI mandate hybrid deployment for production use. BSI’s TR-02102-1 codifies this as a technical requirement, not a recommendation. ANSSI extends the hybrid mandate to both key encapsulation and digital signatures, a position stricter than most. The ETSI TS 103 744 standard provides the technical specification for hybrid key exchange. The October 2024 joint statement signed by 18 EU member states endorsed the hybrid approach.

Hybrid discouraged: Australia’s ASD explicitly does not recommend hybrid. The ISM guidance specifies ML-KEM-1024 as the required parameter set and treats pure PQC as the target from the outset. ML-KEM-768 is acceptable only until 2030.

Hybrid as transition, pure PQC as goal: CNSA 2.0 allows hybrid during the transition period but drives toward exclusive PQC use. By 2030, networking equipment must run CNSA 2.0 algorithms exclusively. By 2033, the hybrid window closes for nearly everything.

No stated position: Japan recommends hybrid as a transitional strategy. South Korea, India, and the UAE have not taken a definitive position on hybrid vs. pure.

For a company operating VPN infrastructure across Germany, Australia, and the US, these positions are directly contradictory. Germany requires hybrid. Australia discourages it. The US allows it temporarily. You cannot satisfy all three with a single configuration policy. You need crypto-agility — the architectural capability to run different algorithm configurations per jurisdiction — or you need to pick hybrid (which satisfies Germany and the US transition period) and accept that Australia may eventually require reconfiguration to pure PQC.

My recommendation: deploy hybrid now. It satisfies the strictest current requirements (BSI, ANSSI), remains compliant with the more permissive frameworks (CNSA 2.0 transition, UK NCSC), and reduces risk against potential PQC algorithm weaknesses. Architect for the ability to drop the classical component when Australia or CNSA 2.0’s exclusive-use dates arrive. The organizations that will struggle are those that deploy pure PQC to satisfy Australia and then discover they need hybrid for their German operations, or vice versa.

Axis 2: Algorithm Portfolios

NIST’s standards (ML-KEM, ML-DSA, SLH-DSA, with FN-DSA and HQC forthcoming) are the global baseline. Every jurisdiction I track accepts them. The divergence is about what else goes on the approved list.

Germany’s BSI includes FrodoKEM (tighter security reduction than ML-KEM) and Classic McEliece (decades-old code-based cryptography) as acceptable alternatives. ANSSI has signaled it may not guarantee its accepted algorithms exactly match NIST’s. Both agencies favor a conservative cryptographic philosophy that prioritizes well-understood mathematical foundations over standardization convenience.

South Korea has gone further. The KpqC competition selected four algorithms (HAETAE, AIMer, SMAUG-T, and NTRU+) that never appeared in the NIST pipeline. Korea will adopt NIST’s algorithms as well, but the KpqC selections occupy official national standards positions. If Korean procurement requirements mandate KpqC algorithms for domestic government use, international vendors face an implementation burden that no other market creates.

China is on a separate track entirely. The Chinese national PQC standards process is producing algorithms distinct from both NIST and KpqC selections. For organizations operating in China, the PQC migration is effectively a parallel project with its own algorithm set, standards body, and timeline.

The practical impact of algorithm divergence is straightforward: the more algorithms you need to support across your operations, the more complex your cryptographic infrastructure becomes. This is why I keep returning to crypto-agility as the foundational architectural requirement. An organization that hardcodes ML-KEM-768 into its stack satisfies most jurisdictions today but has no flexibility when BSI requests FrodoKEM support for a German government contract, or when a Korean partner requires SMAUG-T interoperability.

Axis 3: Scope and Enforcement

The third divergence is about who these deadlines apply to and what happens if you miss them. I examine this in detail in Who Actually Enforces PQC Deadlines?, but the spectrum runs from binding regulation with market-access consequences to guidance that nobody audits.

At the binding end: CNSA 2.0’s 2027 acquisition gate is a procurement requirement. If your product doesn’t comply, it doesn’t get purchased for NSS. Full stop. The EU Cyber Resilience Act is product-market-access law: products that cannot receive cryptographic updates fail the regulation. The Bank of Israel’s Directive 202501 is a supervisory requirement with a named submission target. The UAE’s National Encryption Policy is backed by executive regulation.

In the middle: Canada’s ITSM.40.001 and Treasury Board SPIN create dated, auditable procurement requirements. The EU’s NIS Cooperation Group roadmap carries strong political backing and will likely flow into NIS2 implementing acts. Germany’s BSI guidance shapes KRITIS compliance and certification outcomes.

At the softer end: The UK NCSC’s three-phase timeline is authoritative guidance without statutory enforcement. Japan’s NCO interim report sets a target without intermediate checkpoints. Malaysia’s NACSA roadmap is a framework, not a mandate. The G7 CEG roadmap for the financial sector carries weight but has no enforcement mechanism.

The mistake organizations make is treating “non-binding” as “non-urgent.” The UK NCSC has no statutory power to enforce its 2028 discovery deadline, but when the NCSC publishes a three-phase timeline, UK regulators (FCA, PRA, Ofcom, ICO) use it as a benchmark for what “reasonable” cybersecurity practice looks like. An organization that ignores NCSC guidance and later suffers a quantum-related breach will face hard questions about why it deviated from the national cybersecurity authority’s published timeline. Guidance becomes quasi-binding through the liability chain even when it isn’t statutory.

The Earliest Deadline Wins

I’ve been making this argument for over a year, and the global timeline picture makes it concrete: the earliest deadline in any jurisdiction you operate in is your effective deadline.

A European bank with US defense exposure doesn’t get to plan against the UK’s comfortable 2028 discovery phase. It needs to meet CNSA 2.0’s January 2027 acquisition gate for any products it supplies to NSS. A German manufacturer selling IoT devices into the EU market doesn’t plan against BSI’s 2030 KRITIS deadline; it plans against the EU CRA’s 2027 product compliance requirement. An Australian subsidiary of a Japanese conglomerate doesn’t get Japan’s 2035 endpoint; it gets ASD’s 2030 disallowance.

This principle sounds obvious, but I see it violated constantly. Organizations build migration plans against their home jurisdiction’s timeline and then discover, mid-program, that a client contract, a market access requirement, or a procurement gate in another jurisdiction pulls the deadline forward by three to five years.

The planning principle should be: identify every jurisdiction where you operate, sell, or are contractually bound. Find the earliest binding milestone in any of them. That date governs your program’s first milestone. Then work backward from there.

For most multinationals in mid-2026, the binding milestones that should be driving immediate action are:

If you sell into US government/defense markets: CNSA 2.0 acquisition gate, January 2027. Six months. If you aren’t already compliant or on a waiver path, you’re late.

If you sell products in the EU: EU CRA crypto-agility compliance, ~2027. Your products must support cryptographic updates. This is an architecture requirement, not an algorithm swap.

If you operate critical infrastructure in Germany: BSI hybrid PQC migration, 2030. Four years, but the enterprise migration study says large organizations need 12–15 years. Do the arithmetic.

If you operate in Australia: ASD classical crypto elimination, end of 2030. The most aggressive endpoint among major Western allies.

If you serve financial clients in the EU: NIS Cooperation Group Phase 2 targets CII migration by end of 2030. Financial regulators will treat this as the benchmark for supervisory expectations.

If you serve no government, defense, or regulated-sector clients and operate in a single jurisdiction with soft guidance: You have more time. But not as much as you think, because client expectations flow upstream. When a bank begins requiring PQC attestation from its vendors (and several are already doing this under G7 CEG and DORA pressure), the vendor’s own deadline becomes the bank’s deadline, not the vendor’s home regulator’s.

What Convergence Tells Us

Despite the divergences, the global picture contains a strong consensus signal that organizations should take seriously.

Every major jurisdiction agrees that Harvest Now, Decrypt Later is a present-tense threat. The UAE policy cites it explicitly. The Bank of Israel frames its directive around it. CNSA 2.0’s urgency around key exchange migration is HNDL-driven. This consensus means that data confidentiality (protecting information in transit and at rest against future quantum decryption) is the highest-priority migration target everywhere. Organizations should migrate key exchange mechanisms before signatures, and long-lived confidential data before short-lived transactional data.

Every major jurisdiction agrees that crypto-agility is a requirement, not a nice-to-have. The EU CRA mandates it for products. The UAE mandates it for government systems. ANSSI treats it as a design prerequisite. Even jurisdictions without explicit crypto-agility language (UK, Japan) structure their phased timelines around the assumption that organizations will need to update their cryptographic implementations iteratively. An architecture that cannot swap algorithms is an architecture that fails every regulatory framework.

Every major jurisdiction has accepted the NIST algorithm suite as either the standard or a baseline. No country has rejected ML-KEM, ML-DSA, or SLH-DSA. The divergences are about what to add to the list, not what to subtract. For an organization starting its migration, the NIST suite is the safe starting point, with crypto-agility providing the flexibility to accommodate additional algorithms required by specific jurisdictions.

What Divergence Tells Us

The divergences (hybrid requirements, algorithm portfolios, enforcement mechanisms) are not bugs in the system that will be ironed out by international coordination. They reflect genuine differences in national security philosophy, cryptographic culture, and risk appetite. I’ve written about this in the context of PQC standards fragmentation and sovereignty in the PQC era.

France and Germany’s insistence on hybrid reflects a legitimate concern that PQC algorithms are younger and less tested than their classical predecessors. If ML-KEM is broken by a novel classical attack (unlikely but not impossible), hybrid mode ensures the classical component still provides security. Australia’s rejection of hybrid reflects a different calculation: that the operational complexity of running two algorithm stacks outweighs the marginal security benefit, and that a clean break to pure PQC is simpler to implement and audit.

Both positions are defensible. The problem is that they’re incompatible, and neither side shows any sign of converging. Organizations should plan for permanent divergence on the hybrid question, not wait for international harmonization that isn’t coming.

South Korea’s parallel algorithm standardization reflects an industrial policy calculation: domestic PQC algorithm development builds cryptographic capability, creates export products, and reduces dependence on NIST. Other countries (China, Russia) are making similar moves at larger scale. The long-term trajectory is toward a world with multiple PQC algorithm standards, not a single global baseline.

Where This Is Heading

Three developments over the next 12–18 months will shape how the global timeline picture evolves.

First, enforcement will sharpen. The January 2027 CNSA 2.0 acquisition gate will be the first high-profile PQC enforcement event in the West. How strictly the US government applies it, and how many vendors request and receive waivers, will set the tone for enforcement across other jurisdictions. If compliance is rigorous, it sends a signal that accelerates timelines everywhere. If waivers are routine, it signals that deadlines are aspirational.

Second, the EU regulatory chain will tighten. The NIS2 implementing acts are expected to include PQC-specific requirements. DORA is already creating pressure on financial institutions. The EU CRA reaches full compliance. When these regulatory instruments align with the NIS Cooperation Group’s 2030 target, the EU framework becomes substantially binding. Not through a single legislative act, but through the cumulative effect of multiple regulations pointing in the same direction.

Third, the financial sector will create its own enforcement. The G7 CEG roadmap, the BIS quantum-readiness work, and the FS-ISAC migration roadmap are converging on a common expectation that systemically important financial institutions will be PQC-ready by 2030. Banks will flow these requirements to their suppliers through contractual clauses and vendor assessment questionnaires. This is how “guidance” becomes “mandatory” without legislation: through the supply chain.

What to Do With This

This analysis is the strategic layer. The practical question (what to do first, in what order, and with what resources) is addressed by the PQC Migration Framework and the practical steps guide. But the global timeline picture drives three strategic conclusions that should inform how you scope and sequence your program:

Scope your program to your most demanding jurisdiction, not your home jurisdiction. Identify every market, contract, and regulatory relationship that creates a PQC obligation. Map the corresponding deadlines. Your program’s first milestone is set by the earliest one. The Global PQC Migration Timeline tool is designed to make this mapping visible.

Architect for permanent divergence. Do not assume that the hybrid question will resolve, that algorithm portfolios will converge, or that enforcement will harmonize. Build your cryptographic infrastructure to support algorithm substitution, mode switching (hybrid to pure), and jurisdiction-specific configurations. This is more expensive than a single global rollout, but the alternative is re-architecture every time a jurisdiction changes its requirements. Several will.

Start with key exchange, prioritize HNDL-exposed data, and treat 2027 as your planning anchor. The global consensus on HNDL urgency, the CNSA 2.0 acquisition gate, and the availability of production-ready implementations (OpenSSL 3.5 ships hybrid PQC by default) mean that key exchange migration can start now, for most organizations, without waiting for further standards maturation. Signatures come next, but the tooling there is less mature and the regulatory pressure is softer.

The global PQC migration clock is not one clock. It’s fifteen of them, ticking at different speeds, set to different alarms, and occasionally running backward when administrations change or standards get revised. The organizations that will handle this successfully are the ones that see the full board, plan for the most demanding case, and start moving while their competitors are still debating which deadline to believe.