Regulatory bodies around the world have been issuing post-quantum cryptography mandates, guidelines, and migration milestones. They’re not consistent, not equally binding, and they don’t apply the same way across different kinds of organisations. Before you can do anything useful with them, you need to understand what type of instrument each one actually is.
This article is part of our series on why post-quantum cryptography migration cannot be deferred — understanding the regulatory landscape is the external pressure that turns that urgency into a compliance timeline.
NIST FIPS 203–205, finalised in August 2024, serve as the de facto global baseline. But what you’re actually obligated to do about it depends heavily on your jurisdiction, your sector, and who your customers are. Sector-specific mandates from financial regulators and healthcare authorities haven’t been finalised yet — and this article is going to be straight with you about that gap rather than speculate.
What Is the Global PQC Regulatory Landscape and Which Bodies Have Issued Hard Mandates?
The landscape breaks into three tiers. Hard mandates with binding deadlines and specified algorithms: CNSA 2.0, OMB M-23-02, UAE 2026 plan submission. Authoritative guidance with staged milestones: the UK NCSC’s 2028/2031/2035 framework. And harmonisation targets without binding enforcement yet: the EU Commission’s 2030 target.
NIST’s three foundational standards — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — are the baseline that every national framework references. The Post-Quantum Cryptography Coalition’s international requirements comparison maps out where the real divergence is across jurisdictions. Binding mandates right now exist only in specific contexts: NSS and defence contractors (CNSA 2.0), US federal agencies (OMB M-23-02), and organisations operating in the UAE (2026 plan submission). Everyone else is at guidance or harmonisation-anchor level — for now.
What Does CNSA 2.0 Require and Who Must Comply?
CNSA 2.0 is the NSA‘s mandatory algorithm framework for US National Security Systems. And it doesn’t stop at government agencies — through supply-chain requirements it pulls in defence contractors and SaaS vendors whose products touch NSS environments.
It’s also specific. Not just algorithm families — actual parameter sets. ML-KEM-1024 for key establishment. ML-DSA-87 for digital signatures. AES-256 for symmetric. SHA-384/512 for hashing. The civilian default of ML-KEM-768 is not CNSA 2.0 compliant for NSS-adjacent work. That distinction is going to catch people out.
The schedule: January 2027 new NSS acquisitions must support CNSA 2.0; 2030–2031 legacy phase-out; 2035 full quantum resistance. Major defence and government acquisitions typically run 18–36 months from planning to delivery, which means RFPs being written today need CNSA 2.0 requirements in them right now. OMB M-23-02 and NSM-10 require all US federal agencies to conduct cryptographic inventories — and that creates supply-chain pressure on any SaaS vendor selling into the federal market.
What Are the UK NCSC’s Post-Quantum Migration Milestones and What Do They Mean for Planning?
The UK NCSC’s migration guidance gives you the most explicit multi-phase timeline of any jurisdiction. Three milestones: complete a full cryptographic discovery and initial migration plan by 2028; carry out highest-priority migrations by 2031; finish migration across all systems by 2035.
This is guidance with authoritative milestones, not a statutory mandate. Algorithm recommendations are ML-KEM-768 and ML-DSA-65 — less stringent than CNSA 2.0’s ML-KEM-1024. If you’re operating in both markets, that parameter gap is a real tension you’ll need to work through.
The practical takeaway: treat the 2028 planning milestone as an external anchor regardless of where you’re based. It’s the most actionable near-term deadline available. Completing a cryptographic inventory by then is good practice under any framework.
What Does the EU’s 2030 Post-Quantum Harmonisation Target Mean in Practice?
The EU Commission has targeted 2030 for quantum-safe harmonisation, coordinated through ENISA and the NIS Cooperation Group. In June 2025, the NIS Cooperation Group published a Coordinated Implementation Roadmap with phased milestones at 2026, 2030, and 2035.
There’s no single binding EU regulation yet. But if you’re serving EU financial institutions or regulated-sector clients, the 2030 target already functions as a procurement and due-diligence pressure point. ETSI TS 103 744 governs hybrid TLS within EU deployments and is the technical reference you want.
The member states are actually ahead of the Commission on this. Germany’s BSI mandates hybrid key exchange and includes FrodoKEM and Classic McEliece as conservative fallbacks — more prescriptive than the EU anchor. France’s ANSSI requires hybrid for both KEM and signatures. ENISA’s assessment across over 1,350 organisations in 27 member states found that most European stakeholders are largely unprepared. And DORA, effective January 2025, adds ICT risk management pressure on EU financial entities without yet specifying PQC timelines.
How Do Australia, UAE, and Malaysia Compare?
Australia (ASD) has the shortest deadline among Five Eyes nations. The Australian Signals Directorate recommends eliminating classical public-key cryptography entirely by 2030 — pure PQC, not hybrid. ML-KEM-1024 is required (ML-KEM-768 is only acceptable until 2030). ASD doesn’t recommend hybrid approaches, which puts it directly at odds with the EU’s hybrid-tolerant position.
UAE (UAE Cybersecurity Council) is one of the first governments to move from published guidance to binding requirement. The National Encryption Policy, approved in late 2025, requires mandatory submission of migration plans in 2026, mandates automated cryptographic inventory, crypto-agility by design, and prioritises protection of data with 10–20 year confidentiality lifetimes. The UAE’s policy is explicitly informed by the threat driving these regulatory responses — the harvest-now-decrypt-later model that makes long-lived data a present-tense risk.
Malaysia (NACSA) launched its National PQC Readiness Roadmap at the Kuala Lumpur PQC Conference in October 2025. No hard mandate yet, but ASEAN-level coordination is developing.
If you’re based in Australia and serving UAE clients, you’re satisfying both the ASD 2030 pure-PQC requirement and the UAE 2026 migration plan submission at the same time. The rule is simple: the most stringent applicable jurisdiction governs.
Which Compliance Mandates Apply to FinTech, HealthTech, and SaaS Companies?
Direct mandatory obligations exist for: US federal agencies and NSS contractors (CNSA 2.0, OMB M-23-02); SaaS companies in US federal procurement chains; organisations operating in the UAE (2026); and organisations serving Australian regulated-sector clients (ASD 2030).
Indirect pressure applies if you’re serving EU financial institutions (the 2030 target is already showing up in customer contracts) or storing long-lived patient data (harvest-now-decrypt-later exposure is real regardless of your direct mandate status).
If your company has no international operations or government contracts, there’s no direct mandatory PQC obligation on you right now. But regulatory frameworks propagate — from government through critical infrastructure into regulated sectors. The 2026–2030 window is likely when sector-specific FinTech and HealthTech mandates arrive.
One more thing worth being clear on: your cloud provider handling TLS post-quantum doesn’t satisfy your organisation’s compliance obligations. Platform PQC covers transport only. Your cryptographic inventory, internal systems, certificate management, data-at-rest encryption, and custom integrations are your problem.
What Sector-Specific Mandates Haven’t Been Issued Yet?
No sector-specific PQC mandates have come from financial regulators or healthcare authorities. HIPAA/HHS hasn’t issued one. PCI DSS, the Basel frameworks, FCA, and APRA haven’t either. Being straight about that gap is the accurate position — speculating about unissued mandates helps no-one.
The CEPS Task Force from December 2025 warned that capable quantum computers pose systemic risk to financial systems and urged institutions to start inventorying cryptographic assets now. Watch for propagation in the 2026–2030 window.
Standards worth monitoring: NIST NCCoE SP 1800-38 migration practice guide; ENISA sector-specific guidance under development; IETF RFC 9794; ISO/IEC 23837. The PQCMM from the PKI Consortium is a five-level readiness assessment framework you can use right now, before sector mandates arrive.
Compliance Deadlines by Jurisdiction — Reference
Verify all deadlines and algorithm requirements against primary sources before using this for procurement or compliance decisions.
US (NSS) — CNSA 2.0 — Hard Mandate Key deadline: 2027 new acquisition mandate; 2035 full migration. Algorithms: ML-KEM-1024, ML-DSA-87, AES-256, SHA-384/512. Applies to: NSS agencies, defence contractors, NSS supply chain.
US (Federal Civilian) — FIPS 203–205 / OMB M-23-02 — Hard Mandate Key deadline: 2030 deprecation; 2035 prohibition. Algorithms: ML-KEM, ML-DSA, SLH-DSA. Applies to: federal agencies; supply-chain pressure on federal SaaS vendors.
UK — NCSC PQC Migration Guidance — Staged Guidance Key deadlines: 2028 planning complete; 2031 critical systems; 2035 full migration. Algorithms: ML-KEM-768, ML-DSA-65. Applies to: critical infrastructure, government; advisory for private sector.
EU — EU Commission / ENISA / NIS Cooperation Group — Harmonisation Target Key deadlines: 2026/2030/2035 milestones. Algorithms: NIST standards; ETSI TS 103 744 for hybrid TLS. Applies to: EU-regulated sectors; no single binding regulation yet.
Germany — BSI Technical Guidelines — National Guidance Key deadline: aligned with EU 2030. Algorithms: ML-KEM + FrodoKEM + Classic McEliece (hybrid mandate). Applies to: German federal agencies and regulated market sectors.
France — ANSSI Recommendations — National Guidance Key deadline: aligned with EU 2030. Algorithms: ML-KEM plus FrodoKEM hybrid; hybrid required for signatures. Applies to: French market and EU operations.
Australia — ASD / ISM — Hard Guidance Key deadline: 2030 classical PKC eliminated; hybrid not recommended. Algorithms: ML-KEM-1024 required (ML-KEM-768 acceptable until 2030). Applies to: government, critical infrastructure; FinTech and HealthTech regulated-sector pressure.
UAE — UAE Cybersecurity Council — Hard Mandate Key deadline: 2026 migration plan submission required. Algorithms: crypto-agility by design; automated inventory; NIST-aligned. Applies to: all UAE-operating organisations.
Malaysia — NACSA / National PQC Readiness Roadmap — Emerging Framework Key deadlines: TBD. Algorithms: NIST-aligned. Applies to: ASEAN context; no hard mandate yet.
Timeline: UAE 2026 → EU/NIS 2026/2030 milestones → ASD 2030 → UK NCSC 2031 → CNSA 2.0/NIST 2035.
FAQ
Does Cloudflare automatically handling TLS count towards our organisation’s PQC compliance?
No. Cloudflare’s post-quantum TLS covers transport for Cloudflare-proxied connections. It doesn’t touch your cryptographic inventory requirements, internal system migration, certificate management, data-at-rest encryption, or non-proxied services. Platform PQC and organisational PQC compliance are completely different things.
If our company is based in Australia but serves EU customers, which framework applies?
Both. Australia’s ASD mandates classical PKC elimination by 2030 — pure PQC. The EU targets harmonisation by 2030 but permits hybrid. EU hybrid tolerance doesn’t reduce your ASD obligation; the stricter requirement applies.
Our company doesn’t sell to government — do any of these mandates directly apply to us?
Directly, only if you have US federal customers (OMB M-23-02 supply-chain), operate in the UAE (2026 plan submission), or serve Australian regulated-sector clients (ASD 2030). Indirectly, frameworks propagate from government into regulated sectors. And the harvest-now-decrypt-later risk to long-lived data is real regardless of your mandate status.
What is CNSA 2.0 and how does it differ from NIST FIPS 203–205?
NIST FIPS 203–205 specify the algorithm families that all national frameworks reference. CNSA 2.0 builds on those standards but is more prescriptive — it names specific parameter sets (ML-KEM-1024, ML-DSA-87, not just ML-KEM and ML-DSA) and sets hard procurement deadlines from 2027. NIST applies to federal systems broadly; CNSA 2.0 applies specifically to National Security Systems.
Is there a single global PQC compliance standard?
Not yet. NIST FIPS 203–205 are the de facto global reference, but there’s no international treaty equivalent. ISO/IEC 23837 provides an international standards layer; ETSI TS 103 744 governs EU hybrid TLS. Meaningful divergence exists across jurisdictions on parameter sets, hybrid requirements, and enforcement timelines.
What does “ML-KEM-1024 vs ML-KEM-768” mean for compliance?
Same algorithm family (ML-KEM / FIPS 203), different security parameter sets. ML-KEM-1024 is required by CNSA 2.0 and ASD. ML-KEM-768 is recommended by the UK NCSC and accepted in most civilian deployments. If you’ve deployed ML-KEM-768, you’re not CNSA 2.0 compliant for NSS-adjacent work.
What does “harvest now, decrypt later” mean for our compliance timeline?
Harvest-now-decrypt-later (HNDL) is the strategy of capturing encrypted data today for decryption once a capable quantum computer exists. Data you encrypt now that needs to stay confidential past 2030–2035 is already at risk. Any organisation holding sensitive records with long confidentiality requirements should treat HNDL as a present risk, not a future one.
What is the Post-Quantum Cryptography Maturity Model (PQCMM)?
The PQCMM is a readiness assessment framework from the PKI Consortium, launched at the 2025 Kuala Lumpur conference. Five maturity levels from initial awareness through full deployment. It’s useful if you don’t yet face direct regulatory mandates but want a structured way to assess — and communicate — your PQC posture to customers or regulators.
Does FIPS validation of a cryptographic module mean our product is PQC compliant?
No. FIPS 140-3 validation confirms a module meets security and implementation standards. It doesn’t confirm the module implements post-quantum algorithms or that your product meets any specific PQC mandate. A FIPS-validated module implementing only classical RSA/ECC is not PQC compliant.
What does the EU’s ETSI TS 103 744 standard require?
ETSI TS 103 744 governs hybrid TLS implementations within EU deployments — specifically how classical and post-quantum algorithms should be combined in TLS 1.3 handshakes. It’s the primary technical reference for EU-based organisations implementing post-quantum TLS. Not yet a binding regulation, but it’s the recognised standard that ENISA guidance and EU Commission harmonisation efforts reference for TLS-layer compliance.
Understanding which deadlines apply to your organisation is the first step. Translating them into a phased programme is the next one. The migration roadmap that translates these regulatory deadlines into a phased plan gives you the four-phase structure — from cryptographic inventory through hybrid TLS, authentication migration, and full cryptographic agility — calibrated to SMB resource constraints.
