In brief: Only 9% of organizations have a post-quantum cryptography plan, yet intelligence agencies are actively harvesting encrypted traffic today to decrypt it once a quantum computer arrives. The NIST ML-KEM standard (FIPS 203) is final. Enterprises that wait for an “obvious” quantum threat before migrating will be decrypted before they ever see it coming.
Why the Threat Clock Started Years Ago
Most security teams treat quantum computing as a future problem — something to schedule after the next compliance cycle. That framing is structurally wrong, and the error has a name: harvest-now-decrypt-later (HNDL).
State-level adversaries and well-resourced criminal groups are intercepting and archiving encrypted traffic right now — TLS sessions, VPN tunnels, encrypted file transfers, sealed API payloads. They cannot read it today. They are storing it until a cryptographically relevant quantum computer (CRQC) arrives. At that point, all of that archived traffic becomes readable in retrospect. Every medical record, every financial transaction, every trade secret transmitted over today’s public-key cryptography is a candidate.
The Global Risk Institute’s 2025 Quantum Threat Timeline Report aggregated estimates from 48 expert respondents: the median estimate places a 50% probability of a CRQC capable of breaking RSA-2048 by 2034. The tail risk extends earlier. For data that must remain confidential for 10-plus years — government records, intellectual property, long-term financial instruments — the threat window has already opened.
NIST formally closed its post-quantum standardization process in August 2024, releasing three standards: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a stateless hash-based signature backup. ML-KEM — based on the CRYSTALS-Kyber algorithm — is the primary migration target for TLS, VPN, and key exchange protocols. NIST’s official announcement confirmed these are ready for immediate enterprise deployment.
The policy pressure followed within months. The NSA’s CNSA 2.0 suite requires all new U.S. national security systems to implement post-quantum algorithms by January 2027, with full migration across existing systems targeted by 2030–2035. NIST has separately declared RSA-2048 and elliptic-curve P-256 disallowed for new federal systems by 2030. For enterprises in supply chains that include U.S. federal agencies, these are not optional benchmarks — they are contractual prerequisites arriving faster than most organizations’ security roadmaps currently project.
Advertisement
What enterprise security teams should do
The migration from classical to post-quantum cryptography is not a patch cycle. It is an infrastructure transformation that requires systematic execution. Meta’s engineering team, which published a detailed post-quantum migration framework in April 2026, describes five maturity levels organizations pass through: PQ-Unaware → PQ-Aware → PQ-Ready → PQ-Hardened → PQ-Enabled. Most enterprises today sit at PQ-Unaware or early PQ-Aware. The gap to PQ-Enabled is measured in years of deliberate work, not months of reactive patching.
1. Complete your cryptographic inventory before writing a single migration plan
The foundational prerequisite — and the step most organizations skip — is knowing where cryptography currently lives in their environment. This means identifying every certificate, every key exchange protocol, every signing scheme, and every application that calls cryptographic primitives, whether through libraries, hardware security modules, or third-party APIs.
The Quantum Insider’s May 2026 analysis of enterprise transitions found that cryptographic discovery covers only 60–80% of deeply embedded “Class F” systems — industrial controllers, firmware-level implementations, and legacy middleware. Full discovery in a large enterprise can take three to six months even with automated scanning tools. Organizations that skip inventory and jump directly to patching primary TLS libraries will create a false sense of completeness: their VPN gateway runs ML-KEM, but their HSM-backed signing infrastructure and their IoT management plane still use RSA-2048.
Practical starting point: deploy a cryptographic bill of materials (CBOM) tool such as IBM’s open-source cbomkit or Microsoft’s deprecated-crypto scanner against your top-10 revenue-critical applications. This produces a prioritized remediation list that transforms an overwhelming problem into a sequenced project.
2. Prioritize long-lived data and external-facing key exchange first
Not all cryptographic assets carry equal HNDL risk. The prioritization logic is straightforward: lifetime of data sensitivity plus time to migrate determines urgency. A TLS session for a single API call carries low HNDL risk because the data is ephemeral. A ten-year loan contract transmitted via encrypted email carries high risk.
Meta’s framework recommends prioritizing in this order: (1) external-facing key exchange protocols where HNDL risk is highest; (2) long-lived secrets and stored encrypted data; (3) internal service-to-service communication; (4) signing infrastructure, which has different timeline pressure since signature forgery requires a live CRQC rather than pre-harvested data.
The technical overhead of ML-KEM is manageable. ML-KEM-768 key sizes are 1,184 bytes compared to 294 bytes for ECDH P-256, and ciphertext is 1,088 bytes versus 65 bytes. In practice, Meta’s benchmarks show TLS handshake overhead of approximately 1–3 milliseconds on modern hardware — negligible for most enterprise workloads. The real cost is operational: certificate management systems, hardware security modules, and load balancers all need vendor-specific updates or replacements. Budget $50K–$200K for small to mid-size organizations, $200K–$1M for mid-market, and $1M–$10M+ for large enterprise environments with complex cryptographic dependencies.
3. Address third-party and supply chain cryptographic dependencies explicitly
One of the most underappreciated dimensions of PQC migration is that an organization’s cryptographic posture is only as strong as its external dependencies. Cloud providers, SaaS vendors, certificate authorities, hardware vendors, and managed security service providers all control cryptographic infrastructure that enterprise teams cannot unilaterally upgrade.
Gray Group International’s enterprise PQC guide identifies supply chain cryptographic dependencies as the primary migration bottleneck for most mid-market organizations. The practical action: issue a formal cryptographic roadmap questionnaire to all Tier 1 vendors, requiring documented ML-KEM and ML-DSA timelines. AWS, Google Cloud, Cloudflare, and Microsoft Azure have all begun hybrid key exchange deployments (X25519+ML-KEM-768 in TLS 1.3) — enterprises should activate these hybrid modes now as an immediate risk reduction measure that requires no organizational re-architecture.
Hybrid key exchange (classical + post-quantum simultaneously) is the recommended transition posture: it provides quantum resistance while maintaining compatibility with systems that have not yet migrated. IETF RFC 9420 (MLS) and the emerging IETF hybrid PQC drafts for TLS 1.3 provide the interoperability foundations for this approach.
4. Build governance guardrails that prevent cryptographic regression
Migration projects frequently stall because developers continue to introduce new classical cryptography dependencies faster than the security team can retire old ones. Meta’s framework includes an explicit guardrails phase: automated enforcement in CI/CD pipelines that flags any new use of RSA, ECDH, or ECDSA key generation after a defined cutoff date.
Operationalizing this requires three elements: (1) a cryptographic policy defined in machine-readable form (e.g., an OPA/Rego policy for Kubernetes environments or a custom SAST rule for application code); (2) integration into the pull request gate so violations block merges rather than generating advisory warnings; (3) a formal exception process for legacy systems that cannot immediately migrate, with documented risk acceptance and remediation timelines.
Without these guardrails, PQC migration becomes a treadmill — security teams retire classical cryptography in one part of the stack while developers re-introduce it in new services. The governance layer converts a one-time migration into a permanent cryptographic hygiene standard.
The Migration Gap Is Already a Competitive Disadvantage
The 9% figure — the share of organizations with an active post-quantum plan — is not just a security statistic. It is a procurement risk, a regulatory exposure indicator, and increasingly a market differentiation signal.
Financial services regulators in the EU (DORA) and the U.S. (FFIEC) have both published PQC preparedness guidance. Insurance underwriters are beginning to ask about post-quantum readiness as part of cyber policy renewal questionnaires. And for technology vendors competing for U.S. federal contracts after 2027, the CNSA 2.0 compliance requirement is a hard gate — not a soft preference.
The organizations that begin cryptographic inventory and hybrid key exchange deployment in 2026 are not ahead of the curve. They are entering a race that started when state actors began harvesting traffic, and they are entering it four to five years after their adversaries. The organizations that wait until a CRQC is announced publicly will find that their “sensitive data from 2023” is readable before they can respond.
Post-quantum cryptography is the only defensive measure that closes the HNDL exposure window. Every month of delay is a month of additional harvested traffic that cannot be recalled.
Frequently Asked Questions
What is the difference between ML-KEM and the older Kyber algorithm?
ML-KEM (FIPS 203) is NIST’s standardized, finalized version of the CRYSTALS-Kyber algorithm. Kyber was the submission name during the NIST competition. ML-KEM incorporates minor technical refinements from the standardization process. The two are functionally equivalent for migration planning purposes — any implementation targeting “Kyber-768” or “Kyber-1024” should be updated to target ML-KEM-768 or ML-KEM-1024 using the FIPS 203 specification.
Can we just wait for vendors to upgrade their products and skip internal migration work?
No. Vendor updates handle the cryptographic libraries in their products, but they cannot inventory your organization’s custom applications, internally built services, or data stored under classical encryption. The cryptographic inventory step, governance guardrails in CI/CD, and prioritization of long-lived data are organizational work that no vendor can perform for you.
Is hybrid key exchange (classical + ML-KEM simultaneously) actually quantum-safe?
Yes — hybrid key exchange is quantum-safe because an attacker would need to break both the classical algorithm and ML-KEM simultaneously to compromise the session. Since ML-KEM is believed to be quantum-resistant, the hybrid approach provides quantum resistance while maintaining compatibility with systems that have not yet fully migrated. IETF standards bodies are finalizing the hybrid TLS 1.3 extensions to formalize this interoperability.
Sources & Further Reading
- NIST Releases First 3 Finalized Post-Quantum Encryption Standards — NIST
- Post-Quantum Cryptography Migration at Meta: Framework, Lessons, and Takeaways — Meta Engineering Blog
- Cryptographic Inventory Challenges in Post-Quantum Transitions — The Quantum Insider
- Post-Quantum Cryptography Enterprise Guide — Gray Group International
🔗 Related Intelligence
Post-Quantum Cryptography Migration: The Enterprise Roadmap After NIST Standards
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
