Post-quantum cryptography is the discipline of designing cryptographic algorithms that remain secure against attacks from quantum computers. The threat is not speculative: a sufficiently powerful quantum computer running Shor’s algorithm would break RSA, ECDSA, and ECDH in polynomial time, invalidating every certificate, VPN tunnel, and signed firmware update that depends on those primitives.
Your job, as a security engineer, is to understand which systems are exposed and how to move them to quantum-resistant alternatives before that window closes. This guide covers the NIST FIPS 203, 204, and 205 standards, the harvest now decrypt later threat model, migration sequencing, and a practical four-phase roadmap you can begin executing now.
Why NIST FIPS 203, 204, and 205 Are the Post-Quantum Cryptography Migration Baseline
In August 2024, NIST formally standardized three post-quantum cryptographic algorithms, giving the industry a concrete target for the first time. FIPS 203 specifies ML-KEM (Module Lattice Key Encapsulation Mechanism), derived from the Kyber algorithm. It is the primary standard for key exchange and key encapsulation, replacing RSA and ECDH in TLS, SSH, and IPsec. FIPS 204 specifies ML-DSA (Module Lattice Digital Signature Algorithm), derived from Dilithium, and is the primary standard for digital signatures, replacing ECDSA and RSA signing in code signing pipelines, certificate authorities, and document workflows. FIPS 205 specifies SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+, and is a conservative hash-based fallback for high-assurance signature use cases where independence from lattice assumptions is required.
These three standards are not drafts. They are finalized Federal Information Processing Standards. Any US federal contractor or agency operating under FedRAMP, FISMA, or CMMC must treat migration as a compliance obligation, not a future option. Private-sector organizations in financial services, healthcare, and critical infrastructure face parallel timelines from sector-specific regulators. The publication of FIPS 203, 204, and 205 also ended the waiting-for-standards objection that had stalled many enterprise migration programmes for years. The standards exist. The only remaining variable is your execution timeline.
The Harvest Now Decrypt Later Threat Already Applies to Data You Encrypted This Morning
“Harvest now decrypt later” is the attack model where an adversary records encrypted traffic today and stores it until a capable quantum computer becomes available to decrypt it retrospectively. This is not a theoretical scenario. Nation-state actors with the resources and motivation to target government communications, intellectual property, and financial data have strong incentives to harvest now, and the storage infrastructure to hold petabytes of ciphertext indefinitely costs less each year. If any data you encrypted in the last five years carries a confidentiality requirement extending ten or more years forward, that data is already exposed under this model.
The practical implication is that migration urgency is not tied to the date a quantum computer becomes operational. It is tied to the sensitivity lifetime of the data you are protecting today. A law firm’s client communications, a pharmaceutical company’s clinical trial data, or a defence contractor’s design documents all carry long sensitivity lifetimes. For those organizations, the harvest now decrypt later window opened years ago, and every month of delay extends the exposed surface. This is the core argument for treating the NIST PQC standards as an immediate operational priority rather than a roadmap item for 2028.
Hybrid Key Exchange as the First Migration Step in TLS and SSH
Hybrid key exchange combines a classical algorithm such as ECDH with a post-quantum algorithm such as ML-KEM in a single key agreement handshake. The derived session key is computed from both outputs, meaning an attacker must break both algorithms to recover the session key. This approach is the recommended first step for TLS and SSH migration because it provides quantum resistance immediately while maintaining backward compatibility and preserving protection against any weaknesses in the newer lattice algorithms that cryptanalysts have not yet identified through years of scrutiny.
Google deployed hybrid key exchange combining X25519 with Kyber-768 in Chrome and its own servers in 2023, before the NIST standards were finalized. Cloudflare and AWS followed with similar hybrid deployments in their TLS stacks. OpenSSH 9.0, released in April 2022, already defaults to a hybrid sntrup761x25519 key exchange algorithm as a precautionary measure. The implementation precedent is established and production-grade. For your own infrastructure, the migration path starts with enabling hybrid key exchange in TLS 1.3 where your libraries support it, then cutting over to pure ML-KEM once quantum-resistant negotiation is universal across your client population.
CNSA 2.0 Timelines and What They Mean for Enterprise Planning
The US National Security Agency published the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) in September 2022, establishing explicit migration timelines for systems protecting national security information. The published deadlines, in order of urgency, are:
- Software and firmware signing: support CNSA 2.0 algorithms by 2025, exclusive use by 2030. This category is the highest priority because a compromised signing key undermines every software update pushed to every device in your fleet.
- Networking equipment (routers, switches, VPN gateways): support CNSA 2.0 by 2026, exclusive use by 2033.
- Traditional PKI (certificate authorities, TLS): support deadline 2030, exclusive use by 2035.
These dates apply to NSS systems directly, but they serve as the most authoritative public signal available for private-sector planning horizons. A practical starting audit covers your code signing infrastructure, the algorithms your CI/CD pipeline uses, and the certificate lifetimes involved. Many organizations will discover they are running SHA-256 with RSA-4096 or ECDSA P-384, which are classical-strong but quantum-vulnerable, and that the existing toolchain already supports plugging in ML-DSA as an alternative signer once the relevant library versions are deployed.
Crypto Agility Is the Architectural Property You Need Before the Algorithm
Crypto agility is the design property of a system that allows cryptographic algorithms to be replaced without requiring architectural redesign. A cryptographically agile system abstracts algorithm selection behind interfaces or configuration parameters, so that swapping from ECDSA to ML-DSA is an operator decision rather than a multi-month engineering project. The organizations that will complete PQC migration on schedule are the ones that have already built, or can quickly retrofit, this property into their authentication and key management systems. The ones that have not will discover the problem at the worst possible moment.
Implementing crypto agility means auditing every place in your codebase and infrastructure where a cryptographic algorithm is hardcoded. That includes TLS cipher suite lists, SSH host key algorithms, JWT signing algorithms, database-at-rest encryption settings, HSM key type configurations, and any custom protocol implementations. For teams building new systems, the right pattern is a key management abstraction layer that takes an algorithm identifier as input and routes to the appropriate implementation, rather than calling a cryptographic function directly with a hardcoded algorithm string. This discipline pays compounding returns: it enables you to respond to the next algorithm deprecation in weeks rather than years.
Your cloud security architecture is the logical place to begin this audit, because cloud key management services such as AWS KMS, Azure Key Vault, and Google Cloud KMS are already publishing ML-KEM and ML-DSA support roadmaps, and their API surfaces are well-defined enough to build the agility layer against today.
Inventorying Your Cryptographic Attack Surface Before You Migrate Anything
Migration without inventory produces gaps. The first concrete step in any PQC programme is building a cryptographic bill of materials (CBOM) for your environment. A CBOM documents every algorithm in use, every key type and length, the systems and services that depend on each key, and the estimated sensitivity lifetime of the data those keys protect. This differs from a standard vulnerability scan because the underlying algorithms are not currently broken. A CBOM captures quantum vulnerability, a forward-looking risk category that standard scanners do not flag and most asset management tools do not track.
Several tools are available to automate CBOM generation. IBM’s Cryptography Bill of Materials tool, Crypto4A’s discovery platform, and the open-source cbomkit project from IBM Research each take different approaches to scanning compiled binaries, container images, and network traffic captures. None of them is a complete solution in isolation, but any one of them will surface hardcoded algorithm references and certificate types faster than a manual audit of a large codebase. Start the scan in a non-production environment, validate the output against known cryptographic calls in a system you understand well, then scale to your full estate.
This inventory work connects directly to your cloud security compliance obligations under frameworks like NIS2 and ISO 27001, both of which require documented controls over cryptographic key management and formal assessments of emerging threats to data confidentiality.
Post-Quantum Cryptography Library Support in TLS, SSH, and PKI as of Mid-2026
OpenSSL 3.5, released in April 2025 as a Long Term Support version, includes native support for ML-KEM and ML-DSA, making it the first major upstream TLS library to ship the FIPS 203 and 204 algorithms without third-party plugins. For environments running OpenSSL 3.x today, the Open Quantum Safe project’s liboqs and the oqs-provider plugin deliver ML-KEM and ML-DSA in a form that integrates with the existing OpenSSL provider architecture. Botan 3.x includes ML-KEM, and GnuTLS has experimental support in its development branch. The library readiness picture is materially better in mid-2026 than it was eighteen months ago. The gap between available in a library and deployed in production is now primarily an organizational and testing challenge, not a software availability problem.
For PKI, the challenge is larger because certificate lifecycles, browser trust stores, and CA/Browser Forum policy all move slowly. Hybrid certificates that embed both classical and post-quantum public keys are being piloted by several certificate authorities, and the IETF is actively standardizing composite key and certificate formats in the lamps and pquip working groups. Enterprise PKI administrators should track the Let’s Encrypt and DigiCert roadmap announcements; both have committed to PQC certificate support ahead of the CNSA 2.0 milestones. Internal PKI operated on Windows CA or OpenSSL-based tooling can begin issuing ML-DSA test certificates in isolated environments today, giving operations teams hands-on experience before the production cutover.
Building a Practical 2026 Post-Quantum Cryptography Migration Roadmap in Four Phases
A realistic 2026 roadmap for most enterprise security teams has four phases. The first is discovery: complete the CBOM, classify assets by sensitivity lifetime, and identify the highest-priority migration targets. This phase should take six to eight weeks for an organization with mature configuration management. The second phase is hybrid enablement: deploy hybrid TLS key exchange on public-facing services, enable hybrid SSH key exchange on infrastructure access pathways, and update code signing pipelines to dual-sign with both the existing ECDSA key and a new ML-DSA key. The dual-signing approach mirrors how SHA-1 was retired: both signatures are valid during the transition, and the legacy one is removed once the new one is universally accepted by relying parties.
The third phase is PKI modernization: issue new internal CA hierarchies under ML-DSA, begin short-lifetime certificate programmes that reduce the cost of future algorithm rotation, and pilot composite certificate issuance for a subset of services. The fourth phase is sunset: remove classical-only cipher suites from TLS configurations, revoke and replace RSA and ECDSA code signing certificates, and update compliance documentation to reflect the new algorithm baseline. Each phase has clear entry and exit criteria, which is what separates a roadmap from a wish list.
Security teams that have completed phase one ahead of the CNSA 2.0 software signing deadline consistently report the same finding: the CBOM surfaces three to four times more hardcoded algorithm references than estimated before scanning, and the CI/CD pipeline is almost always the first component that needs refactoring. Treating post-quantum cryptography as a phased engineering programme with verifiable milestones is the only approach that produces auditable, repeatable results at enterprise scale.
Frequently Asked Questions
What is post-quantum cryptography?
Post-quantum cryptography refers to cryptographic algorithms designed to resist attacks from quantum computers. Unlike classical cryptography based on RSA or elliptic curves, which Shor’s algorithm can break, post-quantum algorithms rely on mathematical problems such as lattice-based hardness that current quantum computers cannot solve efficiently, even at scale.
When do I need to migrate to post-quantum cryptography?
The urgency depends on your data’s sensitivity lifetime. If any data you protect today must remain confidential for ten or more years, migration is already overdue because of harvest now decrypt later attacks. CNSA 2.0 sets 2030 as the support deadline for NSS systems, making 2025 to 2027 the practical window for enterprise migration planning and initial deployment.
What is harvest now decrypt later?
Harvest now decrypt later is an attack where an adversary captures and stores encrypted traffic today, then decrypts it retrospectively once a capable quantum computer becomes available. The attack does not require a quantum computer now. Any data with a long confidentiality requirement, such as legal, medical, or government records, is already at risk from adversaries running this strategy.
Is post-quantum cryptography ready for production?
Yes, for key exchange and digital signatures. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. OpenSSL 3.5, AWS KMS, and Cloudflare have all committed to or shipped production support. Hybrid deployments combining classical and post-quantum algorithms are already running at scale in major cloud providers and browsers.
