NIST's Post-Quantum Standards Are Here. Your Infrastructure Isn't Ready.

In August 2024, the National Institute of Standards and Technology published three finalized post-quantum cryptography (PQC) standards: FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+). These represent the culmination of an eight-year standardization process that began in 2016. The standards exist. The threat model is real. What hasn't happened yet is any meaningful migration of the internet's actual infrastructure.

The cryptographic algorithms protecting most of today's internet — RSA-2048, ECDH P-256, ECDSA — depend on mathematical problems (integer factorization and discrete logarithm) that classical computers cannot solve efficiently. A cryptographically relevant quantum computer (CRQC) running Shor's algorithm could break these in hours. No such machine exists today, but the "harvest now, decrypt later" threat is already active: nation-state actors are collecting encrypted traffic today with the intent to decrypt it once quantum hardware matures.

What NIST Actually Standardized

FIPS 203 / ML-KEM is the primary key encapsulation mechanism for general encryption and key exchange — the direct replacement for RSA and ECDH in protocols like TLS. It offers three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, balancing security level against key and ciphertext sizes. ML-KEM-768 is considered the practical default, offering security comparable to AES-192.

FIPS 204 / ML-DSA handles digital signatures, replacing RSA and ECDSA in certificate chains, code signing, and authentication systems. Like ML-KEM, it comes in three parameter variants (ML-DSA-44, ML-DSA-65, ML-DSA-87). The catch: ML-DSA signatures are significantly larger than ECDSA signatures — ML-DSA-65 produces 3,309-byte signatures versus ECDSA's 64–72 bytes. This has real implications for certificate chain sizes in TLS handshakes.

FIPS 205 / SLH-DSA is a stateless hash-based signature scheme, more conservative in its security assumptions than ML-DSA since it relies only on hash function security rather than lattice problems. It's slower and produces larger signatures, making it better suited for long-lived signatures on root certificates and firmware rather than high-throughput authentication.

Where the Internet Actually Stands Today

Browser support for hybrid key exchange arrived before the standards were even finalized. Chrome enabled X25519Kyber768 (a hybrid combining classical ECDH with Kyber) by default in Chrome 124 (April 2024). Cloudflare and Google have been running hybrid PQC for TLS since late 2023 on their edge infrastructure. But this covers only key exchange — the certificate chains validating server identity still use ECDSA or RSA throughout.

The certificate ecosystem is essentially unmigrated. The roughly 200 million active TLS certificates in use as of mid-2025 are overwhelmingly ECDSA or RSA. Certificate authorities including DigiCert and Let's Encrypt have begun testing PQC certificate issuance but have not yet rolled out production PQC certificates at scale. The problem is compounding: PQC certificates with ML-DSA signatures would increase TLS handshake sizes substantially, potentially breaking clients with strict packet size limits or affecting performance on high-latency connections.

VPN protocols are similarly lagging. WireGuard, OpenVPN, and IPsec/IKEv2 implementations vary widely in PQC support. OpenSSH added support for the hybrid sntrup761x25519-sha512 key exchange in version 8.5 (2021) and made it the default in 9.0 (2022), making it one of the earliest widely-deployed PQC integrations. But VPN products used in enterprise environments — Cisco, Palo Alto, Fortinet — have varying timelines, with many still roadmapping PQC support through 2026–2027.

The Timeline Organizations Face

The U.S. government's timeline is the most prescriptive. NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates PQC migration for national security systems, with different deadlines by system type. Software and firmware signing: by 2025. Networking equipment: by 2026. Operating systems: by 2027. Most classified and sensitive government systems: by 2033. NIST's own guidance in Special Publication 1800-38B provides a migration roadmap for federal agencies with similar timelines.

For private organizations, there's no regulatory mandate yet — but that's changing. The EU's NIS2 directive includes cryptographic agility requirements, and ENISA (the EU Agency for Cybersecurity) has published PQC migration guidelines recommending organizations complete inventory and planning phases by 2025 and begin active migration by 2026. Financial sector regulators in the UK and EU have issued similar guidance.

The "harvest now, decrypt later" window is the critical driver for prioritization. Any data with a confidentiality requirement beyond 5–10 years should be treated as already at risk if it's being transmitted today over classical cryptography. Healthcare records, financial agreements, intellectual property, and classified communications all fall into this category.

The Technical Challenges Migration Actually Involves

PQC migration is not a simple drop-in replacement. The larger key and signature sizes in post-quantum algorithms create cascading compatibility issues. ML-KEM-768 public keys are 1,184 bytes compared to 32 bytes for X25519. ML-DSA-65 public keys are 1,952 bytes. Protocols with fixed-size headers, hardware security modules with key size limits, and HSM firmware that predates PQC all require updates or replacement.

Cryptographic libraries are ahead of most applications. OpenSSL 3.x supports PQC through the Open Quantum Safe (OQS) provider. BoringSSL (used by Chrome and Android) has integrated Kyber. The NIST-validated liboqs library provides reference implementations. But integrating these into production systems requires testing for performance regressions, especially on embedded systems and constrained IoT devices where ML-KEM's computational overhead may be significant.

Certificate authority infrastructure needs substantial updates. Issuing PQC certificates requires updating CA software, HSMs capable of ML-DSA operations, OCSP responders, and CRL distribution points. The entire PKI chain — root CAs, intermediate CAs, leaf certificates — needs to migrate in a coordinated way that maintains backward compatibility during a transition period that could span a decade.

What Organizations Need to Do Now

Conduct a cryptographic inventory. Map every system, service, and data flow that uses public-key cryptography. This includes TLS endpoints, VPNs, SSH infrastructure, code signing pipelines, PKI systems, encrypted databases, and any HSMs or smart cards. NIST SP 1800-38B provides a detailed methodology for this inventory process.

Prioritize by data sensitivity and longevity. Systems that transmit or store data requiring confidentiality beyond 2030 should be at the top of the migration queue. Harvest-now-decrypt-later attacks make the threat real today even though the quantum computer doesn't exist yet.

Enable hybrid cryptography where available. Hybrid modes (classical + PQC) provide quantum resistance without sacrificing classical security if the PQC algorithm turns out to have vulnerabilities. IETF RFC 9370 standardizes hybrid key exchange for TLS 1.3. Most modern TLS libraries support X25519MLKEM768 hybrid mode today.

Update cryptographic library dependencies. Upgrade to OpenSSL 3.3+, BoringSSL builds dated after January 2024, or equivalent with OQS provider support. Audit any vendored cryptographic code or hardware acceleration that may hardcode classical algorithm assumptions.

Engage your certificate authority and PKI vendors. Ask DigiCert, Sectigo, Let's Encrypt, and internal CA operators for their PQC migration roadmaps and timeline commitments. Build those dates into your own planning horizons.

Plan for performance testing. PQC algorithms are not uniformly slower, but they are different. ML-KEM is fast in software; hash-based signatures like SLH-DSA are slow. Benchmark your specific workloads — particularly anything doing high volumes of signature verification, like a CDN, load balancer, or authentication service at scale.

The quantum threat is not imminent in the sense of "a CRQC will exist next year." Credible estimates from IBM, Google, and academic researchers put cryptographically relevant quantum computing at 10–15 years away at minimum under current trajectories. But cryptographic migrations take 5–15 years to complete across complex infrastructure. NIST published the standards. The migration clock started. Organizations that begin systematic planning and early migration now will avoid crisis-mode scrambles when regulatory deadlines arrive — or when a quantum computing breakthrough moves the timeline.