NIST's Post-Quantum Cryptography Standards Are Finalized — Your Migration Clock Is Running

NIST finalized three post-quantum cryptographic standards in August 2024: ML-KEM (FIPS 203, based on CRYSTALS-Kyber), ML-DSA (FIPS 204, based on CRYSTALS-Dilithium), and SLH-DSA (FIPS 205, based on SPHINCS+). After a decade of evaluation and multiple algorithm rounds, these are production-ready. The migration clock started the day the standards dropped — not the day quantum computers arrive.

The practical timeline is not abstract. The US government has mandated that federal agencies begin PQC migration by 2030 for most systems, with classified infrastructure moving sooner. Industry is already ahead: Google Chrome shipped hybrid ML-KEM in TLS in 2023 and has since updated to the finalized FIPS 203 version. Apple added PQC to iMessage with iOS 17.4. Signal upgraded its protocol in 2024. If you operate infrastructure expected to stay secure for 10+ years — particularly anything involving asymmetric key exchange — migration is not optional.

Harvest-Now-Decrypt-Later Is an Active Threat

The reason urgency matters now, even though cryptographically-relevant quantum computers do not exist yet, is harvest-now-decrypt-later (HNDL). Nation-state adversaries are capturing encrypted traffic today with the intention of decrypting it once quantum capability arrives. Estimates from NIST, NSA, and CISA place cryptographically-relevant quantum computers (CRQCs) 10–15 years out — exactly the window where data captured in 2026 could be decrypted when it still has intelligence value.

If your application touches data that must stay confidential for a decade — financial records, health records, communications, IP, government contracts — the adversary does not need a quantum computer today. They need one while you still care about that data being secret. The capture is happening now.

Triage: What to Migrate and When

Not everything needs to move simultaneously. The correct triage order is key exchange first, signatures second, symmetric encryption last (or never).

1. Key Exchange — Highest Priority

RSA and ECDH key exchange are the first things quantum computers break. Replace them with ML-KEM (Kyber). The standard safe on-ramp is hybrid mode: run classical and PQC simultaneously. If ML-KEM has an undiscovered weakness, the classical algorithm still protects you. If a CRQC appears, the PQC layer covers you.

X25519MLKEM768 is the specific hybrid used by Chrome, Cloudflare, and AWS in production TLS today. Your web stack may already support it: OpenSSL 3.5 (released April 2025) includes full ML-KEM and ML-DSA support. Enabling it is typically a configuration flag, not a code change.

2. Digital Signatures — Medium Priority

ML-DSA (Dilithium) replaces RSA-PSS and ECDSA for signing. The urgency here is lower because signatures do not have the HNDL problem — a signature only needs to be valid at verification time, not a decade from now. Put code signing certificates, long-lived document signatures, and internal CA hierarchies on your 2027–2028 roadmap, not your 2026 sprint.

3. Symmetric Encryption — Low Priority

AES-256 and SHA-256 are not broken by quantum computers. Grover's algorithm halves their effective key length, which is why AES-256 has been the standard recommendation for years. If you are already using 256-bit symmetric keys, symmetric encryption requires no migration. If you are still on AES-128 for performance, upgrade to AES-256 — that is the extent of the work here.

Library Readiness in Mid-2026

The ecosystem has converged on the finalized FIPS standards across all major languages:

Go

The standard library's crypto/tls package supports X25519MLKEM768 as of Go 1.24. For direct ML-KEM operations outside of TLS, golang.org/x/crypto includes stable ML-KEM 768 and 1024 support. The API mirrors existing asymmetric key patterns: GenerateKey, Encapsulate, Decapsulate with typed byte slices.

Python

pyca/cryptography 44.0.0 (November 2024) added ML-KEM via its OpenSSL 3.5 backend. The interface follows the same generate_private_key / exchange pattern as existing EC operations. For environments where you cannot control the OpenSSL version, pqcrypto provides a direct binding to the reference C implementations.

Rust

The ml-kem crate from the RustCrypto project is a pure-Rust, no_std-compatible implementation fully compliant with FIPS 203. It supports ML-KEM-512, 768, and 1024 variants and is the right choice for embedded or WASM targets where you cannot link OpenSSL. For bridging to pre-standard Kyber deployments, pqcrypto-kyber remains available.

Java / JVM

BouncyCastle 1.77+ supports ML-KEM and ML-DSA with a stable API. OpenJDK 24 introduced ML-KEM as a preview API under JEP 496, with GA targeting JDK 25. For production JVM deployments today, BouncyCastle is the reliable path.

Enabling Hybrid PQC in Your Service Mesh

For internal service-to-service mTLS, hybrid PQC is achievable without application code changes. Envoy Proxy 1.32+ supports X25519+ML-KEM hybrid when compiled against OpenSSL 3.5. The change is a service mesh configuration update to your TLSParameters cipher suite list. Both Istio and Linkerd have documented migration paths for this configuration.

For edge TLS, Cloudflare and AWS CloudFront already negotiate X25519MLKEM768 when the client supports it. If you terminate TLS at a CDN or load balancer you do not control, check your provider's changelog — you may already have partial PQC coverage without knowing it.

A Concrete Three-Year Timeline

2026: Audit all key exchange across external-facing services. Identify OpenSSL versions fleet-wide. Enable X25519MLKEM768 on HTTPS endpoints (configuration change). Document all RSA and ECDH usage in non-TLS contexts: SSH keys, JWTs, internal PKI, any custom key derivation.

2027: Migrate non-TLS key exchange to ML-KEM. Begin internal CA hierarchy redesign. Move code signing to ML-DSA for new artifact releases. Evaluate SSH key migration (OpenSSH 9.x supports ML-KEM-based hybrid KEX).

2028–2030: Complete signature migration. Retire RSA from all new infrastructure. Achieve alignment with NIST SP 800-131C and applicable regulatory requirements (HIPAA guidance, PCI-DSS 5.0 PQC provisions, EU Cyber Resilience Act technical standards).

Actionable Takeaways

• Enable X25519MLKEM768 in TLS 1.3 on public endpoints today — this is a configuration change with negligible performance overhead on modern hardware, and it protects against HNDL immediately.
• Upgrade to OpenSSL 3.5+ or BouncyCastle 1.77+ before writing any new cryptographic code; these include the finalized FIPS 203, 204, and 205 implementations.
• Audit your RSA and ECDH surface area across TLS, SSH, JWT signing, internal PKI, and any custom key exchange — key exchange is highest priority, signatures are medium, symmetric is last.
• Use hybrid mode (classical + PQC simultaneously) as your migration path, not a hard cutover to pure-PQC; this matches what Google, Cloudflare, AWS, and Apple have deployed.
• If you handle data with a 10+ year confidentiality requirement, treat HNDL as an active current threat and put PQC key exchange migration on your 2026 engineering roadmap, not 2028.