Post-Quantum Cryptography Migration Guide (2026)

NIST finalized three post-quantum cryptographic standards on August 14, 2024. Understanding their distinct roles is the prerequisite for any migration planning.

ML-KEM (FIPS 203), formerly CRYSTALS-Kyber, is a Key Encapsulation Mechanism. It establishes shared secrets for encrypted communication and is designed to replace RSA and ECDH key exchange in protocols like TLS. ML-KEM is the primary standard for securing data in transit. It operates on lattice-based mathematics (Module Learning With Errors), which is believed to be computationally hard for both classical and quantum computers. ML-KEM is already supported in recent versions of OpenSSL (3.x with liboqs), BoringSSL, and major TLS implementations.

ML-DSA (FIPS 204), formerly CRYSTALS-Dilithium, is a digital signature algorithm. It replaces ECDSA and RSA for signing operations: tokens, certificates, code signing, and authentication artifacts. ML-DSA produces larger signatures than ECDSA (approximately 2.4 KB versus 64 bytes for a 256-bit ECDSA signature), which has bandwidth and storage implications at scale.

SLH-DSA (FIPS 205), formerly SPHINCS+, is a hash-based digital signature algorithm with more conservative security assumptions than ML-DSA. It relies only on the security of its underlying hash function rather than lattice hardness assumptions. SLH-DSA is recommended for high-assurance applications where long-term signature validity matters, such as firmware signing and PKI root certificates, because its security does not depend on the continued hardness of a single mathematical problem.

A fourth standard, FN-DSA (FALCON, FIPS 206), has been finalized and is particularly suited for constrained environments due to its smaller signature size.

The most urgent argument for beginning PQC migration today is not the threat of a quantum computer breaking your encryption in 2026. It is the threat of adversaries collecting your encrypted traffic right now and storing it for decryption once quantum computing matures.

Harvest now, decrypt later (HNDL) attacks require no quantum capability at collection time. An adversary with access to network traffic intercepts and stores your encrypted TLS sessions, encrypted email, and encrypted file transfers today. When a cryptographically relevant quantum computer (CRQC) becomes available, they decrypt the entire historical collection.

For data with a confidentiality requirement extending beyond 2030 to 2035, the window for protection has already closed if that data is traversing networks today under RSA or ECDH key exchange. This applies acutely to: classified and government data; long-term intellectual property such as drug formulas and chip designs; attorney-client privileged communications; health records subject to decades-long retention requirements; and any data whose exposure would cause lasting harm regardless of when the decryption occurs.

Intelligence community assessments indicate that nation-state actors with advanced capabilities have been running HNDL collection operations for years. NIST's NISTIR 8547 draft guidance acknowledges that migration timelines must account for the time value of the data being protected, not just the timeline for quantum computing maturity.

You cannot migrate what you have not inventoried. The NIST NCCoE's PQC migration project identifies cryptographic visibility as the foundational workstream, and in practice it is the most time-consuming phase for enterprise organizations.

A cryptographic inventory must capture: every certificate in use and its signing algorithm; every TLS configuration and the key exchange mechanisms it supports; every application that performs its own cryptographic operations rather than delegating to the OS or a central library; every code signing key and the pipeline that uses it; every SSH key and its algorithm; every encrypted storage volume or database and its encryption configuration; and every third-party dependency that includes cryptographic functionality.

Automatic discovery tools can accelerate this process. Venafi, Keyfactor, and AppViewX offer certificate inventory and lifecycle management with quantum readiness assessment capabilities. For application-level crypto, static analysis tools with cryptographic pattern detection (Cryptosense Analyzer, IBM Guardium Key Lifecycle Manager) can identify hardcoded algorithms and library calls that require remediation.

The output of the inventory phase is a prioritized list of cryptographic assets ranked by: data sensitivity (what does this protect?), exposure (is this on public-facing infrastructure?), migration complexity (is this a standard library or custom implementation?), and compliance deadline (is this in scope for NSS or another regulatory framework?).

Hybrid cryptography, running classical and post-quantum algorithms in parallel, is the recommended transitional architecture for all organizations beginning PQC migration. It allows you to gain quantum resistance without sacrificing interoperability with systems that have not yet migrated.

In a hybrid TLS deployment, the key exchange uses both ECDH and ML-KEM simultaneously. A session key is derived from both exchanged secrets, typically using a KDF that combines them. An attacker must break both the classical and the post-quantum algorithm to compromise the session. Classical systems that do not support ML-KEM negotiate using ECDH alone. Systems with PQC support use the hybrid mode.

Major TLS libraries already support hybrid modes. Google Chrome has supported X25519Kyber768Draft00 since late 2023. Cloudflare has enabled hybrid PQC in its TLS termination. AWS, Azure, and Google Cloud have PQC roadmaps for their TLS infrastructure. Open-source implementations via the Open Quantum Safe project (liboqs) enable hybrid deployment in OpenSSL 3.x today.

For certificate migration, the hybrid approach involves issuing dual-algorithm certificates during the transition period, where the certificate itself uses a classical algorithm for compatibility but includes a PQC-signed extension. This requires PKI infrastructure updates but maintains compatibility with existing certificate validation chains.

Given the scope of a full PQC migration, sequencing matters as much as the technical choices. The recommended sequence prioritizes by data sensitivity and protocol exposure.

Phase 1 (now through 2026): Complete cryptographic inventory. Enable hybrid PQC for public-facing TLS endpoints. Migrate code signing infrastructure to ML-DSA or SLH-DSA. Establish cryptographic agility principles in your development standards so new systems are built to support algorithm replacement without major refactoring. Inventory and flag all data protected by RSA or ECDH with a confidentiality requirement beyond 2030.

Phase 2 (2026 through 2028): Migrate PKI root and intermediate CAs to PQC algorithms. Complete TLS migration for internal services. Replace RSA-encrypted data at rest for highest-sensitivity data categories. Update SSH infrastructure. Address third-party vendor cryptographic dependencies through contract requirements and procurement criteria.

Phase 3 (2028 through 2030): Complete migration of all systems to PQC-only (or hybrid where classical compatibility is required). Retire classical-only key exchange mechanisms. Establish ongoing cryptographic monitoring to detect algorithm deprecations and emerging weaknesses in deployed PQC algorithms.

For federal agencies and NSS operators, Phase 1 is not optional: CNSA 2.0 mandates beginning PQC adoption by January 2027 with full migration for most NSS use cases by 2033.