When should I start migrating to post-quantum cryptography?

Now. NIST finalized the PQC standards in August 2024, and the NSA's CNSA 2.0 timeline requires national security systems to support PQC by 2025 and use it exclusively by 2030. The harvest-now-decrypt-later threat means adversaries are already capturing encrypted traffic to break later.

What is the difference between ML-KEM and RSA?

RSA relies on integer factoring, which a quantum computer can solve efficiently using Shor's algorithm. ML-KEM uses the Module Learning With Errors lattice problem, which no known quantum algorithm can solve efficiently. ML-KEM keys are larger (1,184 bytes vs 256 bytes for ECDH) but provide quantum resistance.

What is a hybrid key exchange in post-quantum migration?

A hybrid key exchange combines a classical algorithm like X25519 with a post-quantum algorithm like ML-KEM-768 in a single TLS handshake. If either algorithm is later found to be broken, the other still protects the session. IETF and NIST recommend hybrids during the transition period.

Does AES-256 need to be replaced for post-quantum security?

No. Grover's algorithm reduces AES-256 to approximately 128-bit security against quantum attack, which remains far beyond any practical threat. Only asymmetric algorithms like RSA, ECDH, and ECDSA require replacement. AES-256 and SHA-256 are quantum-safe.

What is CNSA 2.0 and who does it apply to?

CNSA 2.0 is the NSA's Commercial National Security Algorithm Suite 2.0, published in September 2022. It mandates specific post-quantum algorithms and deadlines for all US National Security Systems. Many private organizations use it as a best-practice benchmark even when not legally required.

PQC Migration Checklist: RSA to ML-KEM Step by Step

Q: What is post-quantum migration?

Post-quantum migration is the process of replacing quantum-vulnerable cryptographic algorithms like RSA and ECC with quantum-resistant alternatives such as ML-KEM (FIPS 203) and ML-DSA (FIPS 204). The goal is to protect data before a cryptographically relevant quantum computer can break current encryption.

Introduction

The NSA expects adversaries to store your encrypted traffic today and break it the moment a quantum computer is powerful enough. They call this harvest now, decrypt later (HNDL), and it means every RSA-encrypted VPN session, TLS handshake, and API call your organization transmits right now is potentially compromised in advance. NIST finalized three post-quantum cryptography standards in August 2024 — and gave the world a countdown. For national security systems, the NSA’s CNSA 2.0 advisory mandates exclusive use of post-quantum algorithms by 2030. For everyone else, the message is equally clear: waiting for a quantum computer to arrive before starting your PQC migration (post-quantum migration) is already too late.

The migration from RSA and ECC to ML-KEM (FIPS 203) and ML-DSA (FIPS 204) is not a single configuration change. It requires a cryptographic inventory, a risk-based prioritization framework, infrastructure testing for dramatically larger key sizes, and a phased rollout that protects backward compatibility. This checklist walks you through every step, from discovery to validation, with the exact compliance deadlines and legal citations you need to justify the project to leadership.

What Is Post-Quantum Migration?

Post-quantum migration is the systematic process of replacing cryptographic algorithms vulnerable to quantum attacks with NIST-standardized quantum-resistant alternatives. The algorithms being retired — RSA, ECDH, ECDSA, and classical Diffie-Hellman — all depend on mathematical problems (integer factoring and the discrete logarithm problem) that Shor’s algorithm can solve efficiently on a quantum computer.

The replacements are built on entirely different mathematics. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) replaces RSA and ECDH for key agreement. ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204) replaces RSA and ECDSA for digital signatures. SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205) provides a conservative hash-only backup for signatures. All three were finalized by NIST in August 2024 after an eight-year public standardization process.

The migration is not optional for federal systems. NIST IR 8547 (published November 2024) provides the transition framework, while the NSA’s CNSA 2.0 advisory sets specific deadlines. But private organizations face the same underlying threat: any data encrypted with RSA today that must remain confidential for ten or more years is already at risk from HNDL. To understand the mathematical foundations behind the algorithms being replaced, see our guide on post-quantum cryptography standards.

How Post-Quantum Migration Works

The migration follows five phases. Each phase has a clear deliverable and a compliance checkpoint.

Cryptographic inventory. Before you can migrate, you need to know where every asymmetric algorithm lives. This means cataloging every TLS certificate, SSH host key, code signing certificate, VPN configuration, JWT signing algorithm, API authentication mechanism, and DNSSEC zone that uses RSA, ECDH, ECDSA, or classical DH. The result is a Cryptographic Bill of Materials (CBOM) — a complete map of your quantum-vulnerable surface area.
Risk-based prioritization. Not all cryptographic assets face equal HNDL risk. Data with a confidentiality lifetime exceeding ten years (medical records, trade secrets, classified communications, attorney-client privilege) should migrate first. Short-lived session tokens that expire in minutes are lowest priority. Classify each asset by sensitivity lifespan, natural rotation cadence, and regulatory exposure.
Architecture for crypto-agility. Before swapping algorithms, your infrastructure must support algorithm negotiation without hardcoded assumptions. This means ensuring your TLS libraries, key management services, certificate infrastructure, and application code treat algorithms as configurable policy — not embedded constants. Crypto-agility is the design principle that allows you to swap ML-KEM-768 for ML-KEM-1024 (or a future standard) without rewriting your application.
Hybrid deployment and testing. During the transition period, deploy hybrid key exchange that combines a classical algorithm (X25519) with a post-quantum algorithm (ML-KEM-768) in a single handshake. This approach, already deployed by Google Chrome and Cloudflare, ensures that if either algorithm is later found weak, the other still protects the session. Test for increased packet sizes (ML-KEM-768 adds approximately 1,100 bytes to the handshake), MTU fragmentation, and latency impact.
Validation and compliance verification. After deployment, verify that every system in your CBOM has been migrated, that classical-only configurations are disabled where required, and that continuous monitoring detects any non-compliant algorithm usage. For CNSA 2.0-regulated systems, this must be documented and auditable.

Watch for the CNSA 2.0 deadline breakdown and the phased approach to replacing RSA key exchange with ML-KEM — this maps directly to the five migration phases described above.

Post-Quantum Migration vs Algorithm Upgrade

Migrating to post-quantum cryptography is fundamentally different from a routine algorithm upgrade like moving from SHA-1 to SHA-256. Here is how the two compare across the dimensions that determine project scope and risk.

Dimension	Routine Algorithm Upgrade (e.g., SHA-1 → SHA-256)	Post-Quantum Migration (RSA → ML-KEM)
Reason for change	Known weakness exploited today	Anticipated future threat (HNDL)
Key size impact	Minimal (32 → 32 bytes for hash output)	Dramatic (256 bytes ECDH → 1,184 bytes ML-KEM-768)
Protocol changes	Usually drop-in replacement	Requires hybrid negotiation, new TLS extensions
Backward compatibility	Broad — most systems support both	Limited — older clients do not support PQC
Regulatory mandate	Deprecated by browsers/CAs over years	CNSA 2.0 mandates exclusive use by 2030
Inventory scope	Hashes in specific applications	Every asymmetric key in the entire organization
Risk of inaction	Active exploit today	Data stolen today becomes readable in 10–15 years

Real-World Use Cases

Federal contractor TLS migration. A defense contractor operating under CNSA 2.0 requirements must upgrade all networking equipment to support PQC exclusively by 2030 (NSA CNSA 2.0, Annex). They begin by enabling X25519Kyber768 hybrid key exchange on their load balancers and API gateways. Internal mTLS between microservices migrates next. Each service’s mTLS configuration is updated to negotiate ML-KEM-768 alongside X25519, with monitoring that flags any connection still using classical-only key exchange.

Healthcare long-term record protection. A hospital system retains patient records for 30 years under HIPAA retention requirements. Data encrypted with RSA-2048 today could be captured via HNDL and decrypted in 2035. The hospital’s migration prioritizes its encryption at rest layer — re-encrypting archive databases using ML-KEM-derived symmetric keys — before addressing shorter-lived TLS connections.

Financial services code signing. A bank’s code signing certificates use RSA-4096 keys with a five-year validity period. A certificate issued in 2025 will still be validating software signatures in 2030. Migrating to ML-DSA-65 for code signing ensures that firmware updates signed today cannot be forged by a future quantum adversary. The bank uses its hardware security module to generate and protect the new ML-DSA private keys.

PQC Migration Compliance Checklist

Use this checklist to track your organization’s progress through each migration phase. Each item cites the specific standard or advisory that drives the requirement.

Phase 1: Discovery and Inventory

Complete a Cryptographic Bill of Materials (CBOM) identifying every instance of RSA, ECDH, ECDSA, and DH across your infrastructure (NIST IR 8547, Section 3.1).
Catalog all TLS certificates, SSH host keys, code signing certificates, VPN configurations, and API authentication mechanisms using asymmetric cryptography (NIST IR 8547, Section 3.1).
Identify all third-party vendors and libraries that implement or depend on quantum-vulnerable algorithms (NIST IR 8547, Section 3.2).
Classify each cryptographic asset by data sensitivity lifespan — prioritize assets protecting data that must remain confidential for 10+ years (NSA CNSA 2.0, Section 1).
Document key sizes, algorithm identifiers, and certificate expiration dates for every asset in the CBOM (NIST IR 8547, Section 3.1).

Phase 2: Architecture and Crypto-Agility

Verify that TLS libraries support algorithm negotiation without hardcoded algorithm identifiers — upgrade OpenSSL to 3.2+, BoringSSL, or Rustls where needed (NIST IR 8547, Section 4).
Confirm that key management infrastructure (KMS/HSM) supports ML-KEM-768 and ML-DSA-65 key generation and storage (FIPS 203, Section 7; FIPS 204, Section 7).
Ensure certificate infrastructure (CA, OCSP, CRL) can handle ML-DSA-65 signature sizes of approximately 3,309 bytes per signature (FIPS 204, Section 8).
Update internal policies to mandate crypto-agility: algorithms must be configurable at the policy layer, not embedded in application logic (NIST IR 8547, Section 4).

Phase 3: Hybrid Deployment

Enable hybrid key exchange (X25519 + ML-KEM-768) on all external-facing TLS endpoints (CNSA 2.0 Annex, “Software/Firmware Signing: support and prefer by 2025”).
Enable hybrid key exchange on internal mTLS connections between services and databases (CNSA 2.0 Annex, “Networking Equipment: support and prefer by 2026”).
Test for MTU fragmentation — ML-KEM-768 adds approximately 1,100 bytes to TLS ClientHello, which may exceed standard 1,500-byte MTU on some network paths (FIPS 203, Section 8).
Validate that hybrid handshakes complete within acceptable latency thresholds for your SLA requirements.
Deploy ML-DSA-65 for code signing and software update verification alongside existing RSA/ECDSA signatures (CNSA 2.0 Annex, “Software/Firmware Signing: exclusively use by 2030”).

Phase 4: Validation and Monitoring

Implement continuous cryptographic monitoring that detects and alerts on any connection negotiating classical-only (non-hybrid) key exchange (NIST IR 8547, Section 5).
Verify that all CNSA 2.0-regulated systems are on track for exclusive PQC use by 2030 for networking equipment and by 2033 for operating systems (CNSA 2.0 Annex, Table 1).
Conduct a post-migration CBOM audit confirming that every quantum-vulnerable asset identified in Phase 1 has been migrated or has a documented exception (NIST IR 8547, Section 5).
Archive migration documentation for audit readiness — include before-and-after algorithm inventories, test results, and exception justifications.

Common Mistakes to Avoid

The most damaging mistake is treating post-quantum migration as a future project. The HNDL threat is active now — adversaries capturing your encrypted traffic today do not need a quantum computer until they want to read it. Every month of delay extends the window of vulnerable data. If your organization handles data with a confidentiality lifespan exceeding ten years, the migration should already be underway.

Another critical error is attempting to migrate everything at once. Post-quantum migration is a multi-year infrastructure project, not a weekend upgrade. Organizations that try to replace every RSA key simultaneously introduce catastrophic risk of breaking authentication, certificate chains, and interoperability with partners who have not yet migrated. The hybrid approach exists precisely to prevent this.

Many teams also overlook the key size impact on existing infrastructure. ML-KEM-768 public keys are 1,184 bytes — roughly 18 times larger than an ECC P-256 public key. ML-DSA-65 signatures are 3,309 bytes, approximately 46 times larger than an ECDSA P-256 signature. These size increases can cause MTU fragmentation in TLS handshakes, buffer overflows in legacy systems that assumed fixed key sizes, and significant bandwidth increases in certificate-heavy protocols like DNSSEC.

Finally, do not confuse post-quantum migration with symmetric algorithm replacement. AES-256 and SHA-256 are not threatened by quantum computers. Grover’s algorithm reduces AES-256 to approximately 128-bit quantum security, which remains impractical to attack. Migrating symmetric algorithms to “quantum-safe” alternatives is unnecessary and wastes resources that should go toward replacing RSA, ECDH, and ECDSA.

Getting Started

Begin with a scoping exercise. Identify your three highest-risk cryptographic assets — typically your TLS termination layer, your encryption key rotation infrastructure, and any long-lived signing keys. Run those three through the Phase 1 checklist above. This gives you a concrete deliverable (a partial CBOM) and a realistic estimate of the full inventory effort.

Next, verify that your TLS library stack supports hybrid key exchange. OpenSSL 3.2 and later include ML-KEM support. BoringSSL (used by Google Chrome) and Rustls both support X25519Kyber768 hybrid. If your stack is current, enabling hybrid key exchange on a single endpoint is a low-risk first step that immediately protects new sessions against HNDL.

For organizations subject to CNSA 2.0, the timeline is non-negotiable. Software and firmware signing must support PQC by 2025 and use it exclusively by 2030. Networking equipment follows the same schedule. Operating systems must support PQC by 2027 and use it exclusively by 2033. Map your infrastructure categories against the CNSA 2.0 Annex table and build your project plan backward from those deadlines.

To understand the cryptographic algorithms being replaced, read our companion article on post-quantum cryptography standards. For the key management infrastructure that will store your new ML-KEM and ML-DSA keys, see RSA vs ECC: choosing the right public key algorithm.