The End of the Evaluation Period
For eight years — from 2016 to 2024 — post-quantum cryptography was a research problem. NIST solicited 82 candidate algorithms from researchers in 25 countries, ran multiple evaluation rounds, and in August 2024 published three finalized standards: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, an alternative hash-based signature scheme). The evaluation period is over.
In parallel, the NSA published CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) with a binding timeline for US national security systems: quantum-safe algorithms required in all new systems by January 2027, full application migration by 2030, complete infrastructure migration by 2035. France’s ANSSI announced that from 2027, products will not receive French cybersecurity certification unless they incorporate post-quantum cryptography. Google deployed ML-KEM in Chrome in 2024. OpenSSL 3.5 includes ML-KEM support. The infrastructure is no longer experimental.
The threat driving this urgency is not hypothetical. “Harvest now, decrypt later” (HNDL) attacks — where adversaries capture encrypted traffic today to decrypt when quantum computers mature — are confirmed active. Boston Consulting Group’s analysis states that “starting in 2030 will already be too late” for data with 10-year confidentiality requirements. That window includes financial records, government communications, intellectual property, and personal health data currently being transmitted over classical cryptographic channels.
The Migration Problem Is Operational, Not Algorithmic
The most important insight from Meta’s April 2026 migration framework is that the hard problem of PQC migration is not the algorithms themselves — it is the operational complexity of executing the transition across a large, heterogeneous enterprise environment.
Meta defines five maturity levels for PQC readiness: PQ-Unaware (no awareness of the quantum threat), PQ-Aware (initial assessment done, implementation not started), PQ-Ready (solution designed but not deployed), PQ-Hardened (all available protections deployed, though some primitives lack quantum-safe alternatives), and PQ-Enabled (full quantum protection deployed). Most large enterprises, as of 2026, sit at PQ-Aware or early PQ-Ready — meaning they have assessed the risk but have not yet begun deployment.
The migration challenges Meta identifies are structural: cryptographic dependencies are spread across thousands of applications, services, APIs, and infrastructure components. Many are in third-party libraries, hardware firmware, or legacy systems with limited updateability. Key exchange happens at the protocol layer (TLS, SSH, VPN), meaning any infrastructure that terminates encrypted connections — load balancers, firewalls, HSMs, API gateways — requires updates or replacement. And the transition must be executed without breaking existing systems, because a failed migration that takes down TLS for a banking platform or a government portal is not an acceptable outcome.
Advertisement
Three Steps for the Enterprise Roadmap
1. Run a Cryptographic Inventory Using a Risk-Tier Framework
You cannot migrate what you cannot find. The first step is a full cryptographic inventory — identifying every application, service, API, and infrastructure component that uses RSA, ECDH, or ECDSA, and classifying each by HNDL risk tier.
Meta’s prioritization framework defines three tiers: high priority (applications vulnerable to offline HNDL attacks — data with 10+ year confidentiality requirements transmitted over TLS), medium priority (applications vulnerable to future online attacks when CRQCs exist), and low priority (data with short confidentiality windows where future decryption provides minimal value to adversaries).
In practice: banking transaction encryption, government communications, healthcare records, and intellectual property are Tier 1. Standard web traffic, internal tooling with short data shelf-lives, and development environments are Tier 3. Everything else falls into Tier 2 based on the sensitivity and longevity of the data involved.
Automated cryptographic discovery tools (Venafi, Keyfactor, and open-source options) can scan certificate inventories and identify key exchange algorithms at scale. For internal services, network traffic analysis can identify RSA/ECDH handshakes at the packet level. The inventory output should feed directly into a migration sequencing plan — highest risk tier first.
2. Deploy Hybrid Cryptography for New Deployments Starting Now
The consensus guidance from Meta, ANSSI, NIST, and the UK NCSC is identical: use hybrid cryptography — classical plus post-quantum in parallel — during the transition period, rather than switching abruptly to PQC-only. This provides security insurance against the (unlikely but non-zero) possibility that a newly standardized PQC algorithm has an undiscovered weakness.
ML-KEM768 (NIST Level 3 security, equivalent to AES-192) is the recommended key encapsulation algorithm for TLS. The hybrid approach combines ECDH P-256 or X25519 with ML-KEM — both are computed and the key derivation function uses both outputs. If either algorithm is broken, the other provides protection. Chrome’s deployment uses X25519+ML-KEM768. OpenSSL 3.5 supports this hybrid mode natively.
For new infrastructure deployments in 2026-2027 — firewalls, load balancers, HSMs, VPN concentrators — ML-KEM/ML-DSA support must be a procurement requirement. HSMs warrant particular urgency: they manage private keys for PKI, code signing, and authentication systems, they have 5-7 year replacement cycles, and most current-generation HSMs require firmware updates or hardware replacement for PQC support. HSMs procured in 2026 without PQC support will be a bottleneck in 2028-2030 when migration targets require them.
3. Establish a Governance Framework That Prevents Backsliding
The technical migration is the easier half of the problem. The governance problem — ensuring that new systems deployed during the transition period do not re-introduce classical-only cryptography — is harder. Meta calls this “implementing guardrails”: updating cryptographic guidelines to prohibit new vulnerable key generation, preventing use of affected APIs in new code, and deprecating classical-only interfaces on a published schedule.
For enterprise organizations, the governance framework requires: a crypto-agility standard (which algorithms are approved, at what minimum key lengths, with what hybrid requirements), a deprecation timeline for classical-only configurations, a cryptographic exceptions process (what happens when a third-party system cannot be updated on schedule), and an annual audit against the standard.
The $15 billion market projection through 2030 assumes enterprises budget 2-5% of annual IT security spend per year on PQC migration. For an enterprise with a $20 million annual security budget, that is $400,000–1,000,000 per year allocated to this transition — a capital program, not a one-time project. Boards and CFOs need to understand this framing before the technical teams begin presenting migration plans.
What Comes Next: The 2026-2030 PQC Timeline
The next 18 months will clarify the commercial landscape significantly. NIST IR 8547 (guidance on algorithm selection and deployment) is in public draft; the final version will give enterprises clearer procurement language. HQC (a backup key encapsulation algorithm providing mathematical diversity from ML-KEM’s lattice basis) may be standardized, giving large organizations a diversification option.
Browser vendors and CDN providers are already deploying ML-KEM at scale. Cloudflare, Google, and Akamai handle enough global TLS traffic that their deployment decisions set a de facto standard for the wider ecosystem. Enterprises that have not deployed PQC will find their network traffic patterns shifting in 2026-2027 as counterparties upgrade — creating interoperability pressure to follow.
The Singapore Cyber Security Agency, UK NCSC, and Australian Cyber Security Centre have all published PQC migration roadmaps. The international regulatory convergence is clear: PQC is not optional for organizations operating in regulated sectors or with international counterparties. The only variable is the speed at which organizations recognize that their 2030 target requires 2026 planning.
Frequently Asked Questions
How urgent is the post-quantum threat if quantum computers capable of breaking RSA don’t exist yet?
The threat is urgent today because of “harvest now, decrypt later” attacks. Adversaries — primarily nation-state actors — are actively collecting encrypted traffic now with the intention of decrypting it once cryptographically relevant quantum computers (CRQCs) exist. If the data being transmitted today has a confidentiality requirement extending to 2035 or beyond (government secrets, long-term financial records, medical data), and CRQCs arrive before 2035, that data is retroactively exposed. Boston Consulting Group estimates “starting in 2030 will already be too late” for this category of data.
What is the practical difference between ML-KEM and the RSA it replaces?
ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) is a key encapsulation mechanism based on lattice cryptography (the Module Learning With Errors problem), which is believed to be computationally hard for quantum computers. RSA is based on the difficulty of factoring large integers — a problem that Shor’s algorithm running on a sufficiently powerful quantum computer can solve efficiently. ML-KEM at Level 3 (ML-KEM768) provides roughly equivalent classical security to AES-192, with significantly smaller key sizes than RSA-4096. TLS connections using ML-KEM768 have larger handshake packets than ECDH (about 1.5KB versus 64 bytes) but negligible performance overhead on modern hardware.
Why does the hybrid approach (classical + PQC) make sense during the transition?
The hybrid approach combines a classical algorithm (ECDH P-256 or X25519) with ML-KEM in the same key derivation. An attacker must break both algorithms to recover the key. This provides protection against two distinct risk scenarios: (1) a classical attacker today who cannot break classical algorithms, and (2) a future quantum attacker who can break classical but not PQC algorithms. The hybrid approach costs slightly more in computation and packet size but eliminates the risk that a newly standardized PQC algorithm has an undiscovered weakness. ANSSI, NIST, and UK NCSC all recommend hybrid deployment during the transition period.
—
Sources & Further Reading
- Post-Quantum Cryptography Migration at Meta: Framework, Lessons and Takeaways — Meta Engineering
- NIST IR 8547: Post-Quantum Cryptography Standards — NIST CSRC
- The $15 Billion Post-Quantum Migration — PR Newswire
- Post-Quantum Cryptography for Authentication: Enterprise Migration Guide 2026 — Security Boulevard
- Post Quantum Cryptography Migration 2026 — ISACA Journal
- Post-Quantum Cryptography Migration 2026: Enterprise Readiness — Programming Helper Tech
🔗 Related Intelligence
Post-Quantum Cryptography: The April 2026 Deadline Is Here
Harvest Now, Decrypt Later: Why Quantum Threats to Enterprise Encryption Are Already Here
The Quantum Clock Is Ticking: Why Every Organization Must Act on Post-Quantum
Post-Quantum Cryptography: Algeria’s Migration Roadmap Before 2027 Locks You In
