Post-Quantum Cryptography Migration: A Practical Guide

The clock is ticking. In June 2026, the White House published memorandum M-26-15, mandating that all US federal agencies migrate key establishment for high-impact systems to post-quantum cryptography (PQC) by December 31, 2030, and digital signatures by 2031. Private-sector organizations face similar pressure from the NSA’s CNSA 2.0 timelines, NIST’s 2035 deprecation target for quantum-vulnerable algorithms, and the very real threat of “harvest now, decrypt later” attacks.

This guide covers what PQC means in practice, what the key standards are, how to enable hybrid TLS today, and how to build a migration strategy that doesn’t leave you scrambling in 2030.

The Three NIST Standards You Need to Know

On August 13, 2024, NIST released the first three finalized PQC standards after an eight-year international competition that saw 82 candidate algorithms from 25 countries. Here is what landed:

Standard	Algorithm	Purpose	Renamed From
FIPS 203	ML-KEM	Key Encapsulation Mechanism (encryption)	CRYSTALS-Kyber
FIPS 204	ML-DSA	Primary Digital Signature	CRYSTALS-Dilithium
FIPS 205	SLH-DSA	Backup Digital Signature	Sphincs+

ML-KEM is the most urgent standard for most organizations because of the “harvest now, decrypt later” threat — encrypted data captured today can be stored and decrypted years later when a cryptographically relevant quantum computer (CRQC) exists. Key agreement must be upgraded before signatures.

ML-DSA is the primary signature algorithm for certificates, code signing, and document signing. It is lattice-based and efficient, but produces much larger signatures than ECDSA.

SLH-DSA is the conservative backup. It relies on hash-based cryptography (a different mathematical foundation than ML-DSA’s lattices), so if one is broken, the other remains secure. The tradeoff is enormous signature sizes — up to 50 KB for the highest security level.

Key Size Realities

A TLS handshake today with ECDSA + X25519 is roughly 4-6 KB on the wire. The same handshake with ML-KEM-768 + ML-DSA-65 can reach 20-50 KB. This has real implications:

• MTU fragmentation — larger handshake messages may fragment across multiple TCP segments, causing jumbo-frame issues on VPNs and middleboxes
• CDN and load-balancer limits — some hardware accelerators have fixed buffer sizes for TLS key exchange
• Certificate chain bloat — a certificate chain with ML-DSA signatures plus intermediate CA certificates can exceed 20 KB, compared to ~4 KB today

Choosing the right security level matters. ML-KEM-768 (AES-192 equivalent) is sufficient for most use cases; ML-KEM-1024 is available but comes with proportionally larger keys and slower performance.

Hybrid TLS: Deploying PQC Without Breaking the Internet

The most pragmatic approach to PQC migration today is hybrid key exchange — combining a classical algorithm (X25519 ECDH) with a post-quantum algorithm (ML-KEM) in a single TLS handshake. The connection is secure as long as at least one of the two algorithms remains unbroken.

This is not theoretical. Cloudflare enabled X25519 + Kyber hybrid key agreement for all websites and APIs on their network in October 2022. Google Chrome shipped X25519Kyber768 by default starting in Chrome 124 (April 2024).

Enabling Hybrid Key Exchange with OpenSSL 3.x and oqs-provider

If you control your TLS termination infrastructure, you can enable PQC today using OpenSSL 3.x’s provider architecture and the oqs-provider from the Open Quantum Safe (OQS) project.

# Install liboqs and oqs-provider
git clone https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/opt/oqs ..
make -j$(nproc) && make install

# Build oqs-provider
git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
cmake -DCMAKE_PREFIX_PATH=/opt/oqs ..
make -j$(nproc) && make install

With the provider built, configure OpenSSL to load it:

# /etc/ssl/openssl.cnf — add or modify the providers section
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqs_sect

[default_sect]
activate = 1

[oqs_sect]
activate = 1
module = /opt/oqs/lib/ossl-modules/oqsprovider.so

You can now test hybrid TLS by specifying the X25519MLKEM768 named group (standardized in IETF TLS WG drafts). Run an OpenSSL s_server with hybrid key exchange:

# Server
openssl s_server -cert server.crt -key server.key \
  -groups X25519MLKEM768 -www -port 4433

# Client (verify the negotiated group)
openssl s_client -connect localhost:4433 -groups X25519MLKEM768

If the connection succeeds and the negotiated group is X25519MLKEM768, you have a working hybrid TLS handshake. The client and server are now resistant to harvest-now-decrypt-later attacks.

Browsers and CDNs

If you use a CDN or reverse proxy, check whether it already supports hybrid TLS. Cloudflare has supported it since 2022. For custom origins, configure your upstream TLS stack (Nginx, HAProxy, or a Go/ Rust service) to negotiate X25519MLKEM768 as a supported group.

Nginx with OpenSSL 3.x + oqs-provider:

# /etc/nginx/nginx.conf — http block
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1;
ssl_protocols TLSv1.3;

This tells Nginx to prefer the hybrid PQ group, falling back to classical groups if the client does not support it.

A Phased Migration Strategy

Building on the White House M-26-15 four-phase model and NIST NCCoE’s crypto-agility guidance, here is a practical roadmap for any organization.

Phase 1: Cryptographic Discovery and Inventory (now — Q1 2027)

You cannot migrate what you cannot find. Build an inventory of every system, library, and protocol that performs cryptographic operations:

• TLS certificates and key exchange configurations on every server, load balancer, and API gateway
• Code-signing certificates and CI/CD signing workflows
• VPN and IPsec cryptographic profiles
• Database encryption-at-rest configurations (TDE, EFS, LUKS)
• Hardware Security Module (HSM) cryptographic capability
• Internal CA certificate chain and CRL signing

Several commercial and open-source tools can automate this, but even a manual inventory against network scanning output is a strong start. The key question per system: Can this component support hybrid or PQC-only cryptography, or must it be replaced?

Phase 2: Prioritize Key Establishment (2027–2028)

Start with the systems most exposed to “harvest now, decrypt later” attacks:

1. Public-facing TLS termination — web servers, CDN origins, API gateways. Enable X25519MLKEM768 as the preferred key-exchange group.
2. Internal TLS — service mesh, inter-service communication, database replication. Test hybrid key exchange in non-production first — older hardware accelerators and middleboxes may drop unknown named groups.
3. VPN concentrators — verify that MTU handling can accommodate the larger hybrid handshake. PQC key exchange adds ~2 KB to the IKE or TLS handshake payload.

For each system, testing should verify that hybrid connections succeed, latency is acceptable (typically a 5-15% increase in handshake time), and no session negotiation failures occur with existing clients.

Phase 3: Signature Migration (2028–2031)

Signatures are less urgent than key exchange (no harvest-now equivalent for signed data), but replacement takes longer because certificate chains must be re-issued:

1. Internal CA — generate new ML-DSA or hybrid (ML-DSA + ECDSA) cross-signed certificate authority keys
2. Code signing — update CI/CD pipelines to use PQC signing keys. Note that ML-DSA signatures on binaries increase the signed payload size significantly — use ML-DSA-44 or ML-DSA-65 for most internal signing
3. TLS certificates — deploy hybrid certificates (dual-cert chain with both classical and PQ signatures) during renewal. This avoids breaking legacy clients while future-proofing new connections
4. Document and email signing — S/MIME and OpenPGP both have PQC algorithm support in recent updates (OpenPGP v6 includes ML-KEM and ML-DSA)

Phase 4: Crypto-Agility as an Ongoing Practice

The final and most important phase is building crypto-agility — the ability to swap cryptographic primitives without major architecture changes.

NIST NCCoE defines crypto-agility through:

• Abstracted cryptographic interfaces — never hardcode algorithm identifiers. Use provider patterns (like OpenSSL 3.x providers) that allow drop-in algorithm replacement
• Automated inventory — continuous discovery of cryptographic usage, not a one-time audit
• Graceful degradation — prefer hybrid deployments that work with both classical and PQC clients during transition windows
• Testing infrastructure — regularly validate interoperability with the latest standardized algorithms and named groups

The organizations that succeed with PQC migration are not the ones that do a single big-bang upgrade in 2030. They are the ones that make crypto-agility a normal engineering practice today.

Common Pitfalls to Avoid

Waiting for “final” standards. NIST has already published final standards. ML-KEM and ML-DSA are not going to change. Deploy hybrid now.

Ignoring performance impact at scale. A 20-50 KB TLS handshake is fine for a few connections. For a CDN edge handling 100,000 handshakes per second, the bandwidth and CPU cost is significant. Profile before rolling out to production.

Assuming all clients support hybrid groups. Legacy IoT devices, embedded systems, and older OS crypto libraries may not negotiate unknown TLS named groups. Maintain a fallback path.

Overlooking hardware. HSMs, network accelerators, and smart cards may lack PQC support. Verify hardware roadmaps from your vendors — CISA’s January 2026 product categories list lists PQC-capable HSMs as “widely available,” but not all vendors have shipped firmware updates.

The Bottom Line

The migration to post-quantum cryptography is not a future problem. NIST published the standards in 2024. Chrome and Cloudflare have shipped hybrid TLS in production. The White House has set a 2030 key-establishment deadline. The core difficulty is not the algorithms — it’s the inventory, the testing, and the organizational planning required to touch every system that does cryptography.

Start with hybrid key exchange on your public-facing TLS endpoints. Build a cryptographic inventory. Deploy the oqs-provider in test environments. The goal is not perfection — it is eliminating the single point of failure where a quantum-capable adversary can decrypt your encrypted traffic retroactively. Every system you migrate before 2030 is one less emergency in 2029.