NIST's Post-Quantum Cryptography Standards Are Final — Here's the Migration Timeline Every Organization Needs to Know

The Standards Are Final. The Clock Is Running.

In August 2024, the National Institute of Standards and Technology (NIST) published FIPS 203, FIPS 204, and FIPS 205 — the first finalized post-quantum cryptography (PQC) standards in history. After nearly a decade of evaluation, the agency standardized three algorithms: ML-KEM (Module Lattice Key Encapsulation Mechanism, based on Kyber), ML-DSA (Module Lattice Digital Signature Algorithm, based on Dilithium), and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, based on SPHINCS+). A fourth algorithm, FN-DSA (based on Falcon), is expected to be standardized in a follow-on FIPS publication. These are not proposals or drafts. They are standards, and NIST's guidance is clear: begin migration now.

The urgency is not about what quantum computers can do in 2026 — it is about what they will be able to do in 2030 to 2035 and what adversaries are already doing today. The harvest-now-decrypt-later threat model means that nation-state actors and well-resourced attackers are capturing encrypted traffic right now, storing it, and betting that a cryptographically relevant quantum computer (CRQC) will eventually break it. Any data that must remain confidential for more than five to ten years is already at risk. That means health records, financial contracts, government communications, and intellectual property.

What Quantum Computers Can Actually Break — and When

Today's quantum computers are noisy, small-scale machines. IBM's Heron processor and similar systems operate in the range of hundreds to low thousands of physical qubits, far below the millions of error-corrected logical qubits needed to run Shor's algorithm against RSA-2048 or ECDSA P-256. Current machines cannot break any production cryptographic system. The realistic estimate for a CRQC capable of breaking RSA-2048 is between 2030 and 2035, with some optimistic projections placing it earlier if error correction advances faster than expected.

What Shor's algorithm breaks: RSA (all key sizes in practical use), Diffie-Hellman key exchange (including finite-field and elliptic-curve variants), and ECDSA/EdDSA signatures. What it does not break: symmetric ciphers like AES-256, which require only doubling the key size (Grover's algorithm provides only a quadratic speedup). TLS 1.3, as deployed today, relies on ECDHE for key exchange and ECDSA or RSA for certificate authentication — both are vulnerable long-term. SHA-256 and SHA-3 are considered quantum-resistant at current output sizes with modest security margin reduction.

The Three New Algorithms: Technical Details

ML-KEM (FIPS 203 / Kyber) is the primary standard for key encapsulation — the mechanism used to establish shared secrets in protocols like TLS. It operates on module lattice problems (specifically the Module Learning With Errors problem). At the ML-KEM-768 parameter set (roughly 128-bit quantum security), public keys are 1,184 bytes and ciphertexts are 1,088 bytes — larger than RSA-2048's 256-byte public key, but the performance story is compelling: ML-KEM-768 achieves roughly 15,000–20,000 encapsulations per second on a modern server core, compared to approximately 3,000–5,000 RSA-2048 operations per second for key generation. Decapsulation is similarly fast. Key generation in ML-KEM is dramatically faster than RSA key generation.

ML-DSA (FIPS 204 / Dilithium) is the primary standard for digital signatures. At ML-DSA-65 (approximately 128-bit quantum security), signature sizes are 3,293 bytes and public keys are 1,952 bytes. Signing throughput reaches approximately 5,000–8,000 signatures per second per core, with verification faster still. By comparison, ECDSA P-256 signs at roughly 20,000–40,000 operations per second — ML-DSA is slower but the gap is manageable for most applications. The larger signature sizes are the main integration challenge, particularly for certificate chains and constrained environments.

SLH-DSA (FIPS 205 / SPHINCS+) is a hash-based signature scheme providing a conservative, well-understood security foundation. It relies only on the security of the underlying hash function (SHA-256 or SHAKE), not on lattice hardness assumptions. The tradeoff is performance and size: SLH-DSA-128s produces 7,856-byte signatures and signs at roughly 100–500 operations per second depending on parameter set. It is best suited for high-assurance use cases — firmware signing, root certificate authorities, or any context where signing is infrequent and signature size is acceptable.

Hybrid Key Exchange: The Safe Bridge

Because the new algorithms are less battle-tested than RSA and ECDH — which have decades of real-world cryptanalysis behind them — the recommended migration path is hybrid key exchange: combining a classical algorithm with a post-quantum one so that security holds as long as either remains unbroken. IETF RFC 9180 (HPKE) and draft standards for TLS 1.3 PQC hybrid key exchange define concrete mechanisms. Google Chrome has already enabled X25519+ML-KEM-768 hybrid key exchange by default as of Chrome 131 (late 2024). Cloudflare, AWS, and Azure are all deploying or have deployed hybrid PQC in their TLS termination infrastructure. The performance overhead of adding ML-KEM to an existing TLS handshake is roughly 1–2 milliseconds of additional latency and about 2 KB of additional handshake data — negligible for most applications.

Migration Timeline by Organization Size

Large enterprises and critical infrastructure (2024–2027): Begin cryptographic inventory now. Identify all systems using RSA, ECDSA, ECDH, and Diffie-Hellman. Prioritize long-lived secrets and high-sensitivity data stores. Deploy hybrid TLS with ML-KEM on internet-facing services. Update certificate issuance pipelines to support ML-DSA. Work with vendors on firmware and HSM support timelines. NIST recommends large organizations complete primary migration by 2030.

Mid-size organizations (2025–2028): Leverage cloud provider PQC support (AWS Certificate Manager, Google Cloud, Azure are adding PQC certificate options). Enable hybrid PQC in load balancers and API gateways as configuration options become available. Update VPN and remote access solutions — many vendors (Cisco, Palo Alto, Fortinet) have announced or shipped PQC support.

Small organizations (2026–2030): Follow your software and cloud vendors. Update TLS libraries (OpenSSL 3.x, BoringSSL, and liboqs already support ML-KEM and ML-DSA). Migrate certificate authorities when your CA supports FIPS 203/204. The bulk of the work will come as standard tooling upgrades.

Migration Checklist

• Inventory: Catalog all cryptographic dependencies — TLS certificates, SSH keys, code-signing certificates, VPN configurations, encrypted data at rest, and HSM-stored keys.
• Prioritize by data lifetime: Any secret that must remain confidential past 2030 needs protection today against harvest-now-decrypt-later attacks.
• Enable hybrid TLS: Deploy X25519+ML-KEM-768 on all TLS 1.3 endpoints. Most major CDN and load balancer vendors support this now or in 2025 releases.
• Update certificate chains: Plan migration to ML-DSA certificates. Monitor your CA's roadmap and test in staging with liboqs or OQS-enabled OpenSSL builds.
• Audit code-signing pipelines: Replace ECDSA-based signing with ML-DSA or SLH-DSA for firmware, container images, and software packages.
• Evaluate HSM and key management: Confirm your HSM vendor supports FIPS 203/204/205. Thales, Entrust, and AWS CloudHSM have published PQC roadmaps.
• Update SSH: OpenSSH 9.0+ supports hybrid ML-KEM key exchange. Enable it for privileged access infrastructure.
• Test performance in your environment: Run ML-KEM and ML-DSA benchmarks with liboqs before committing to parameter set choices.
• Train your team: Security engineers need to understand lattice-based cryptography assumptions at a conceptual level to evaluate vendor claims and implementation quality.
• Set a hard deadline: NIST recommends deprecating RSA and ECC for key establishment and signatures by 2030. Build that date into your security roadmap now.

The post-quantum transition is the largest cryptographic infrastructure migration since the SSL-to-TLS shift — and it has a harder deadline. The algorithms are finalized, the implementations are maturing, and the browsers and cloud providers are already moving. The only variable is whether your organization will migrate on its own schedule or scramble when the threat becomes acute.