Why Post-Quantum Cryptography Migration Cannot Wait
The threat model for post-quantum cryptography migration is not “quantum computers will break TLS tomorrow.” Instead, it is “adversaries are recording encrypted traffic today and will decrypt it whenever cryptographically relevant quantum computers arrive.” This “harvest now, decrypt later” model means data with multi-decade confidentiality requirements (medical records, intellectual property, classified information) is already at risk regardless of when CRQCs actually emerge.
Furthermore, NIST finalized the first three post-quantum standards in 2024, and major TLS implementations now support hybrid key exchange in production. Consequently, enterprises have no remaining excuse to defer planning. In this guide I will walk through the algorithm choices, deployment patterns, and inventory strategies we used across a regulated financial services migration covering 1,400 services.
The NIST PQC Standards You Need to Know
Three FIPS standards anchor the migration. FIPS 203 specifies ML-KEM (formerly Kyber), a lattice-based key encapsulation mechanism that replaces RSA and ECDH for key establishment. FIPS 204 specifies ML-DSA (formerly Dilithium), a lattice-based digital signature algorithm. Additionally, FIPS 205 specifies SLH-DSA (formerly SPHINCS+), a hash-based signature scheme used as a hedge against unknown lattice attacks.
For most enterprises, ML-KEM-768 and ML-DSA-65 hit the sweet spot of NIST Level 3 security with manageable key and signature sizes. SLH-DSA produces much larger signatures (around 17KB for the hash-based variant) and is reserved for root-of-trust scenarios like firmware signing where signature bandwidth is acceptable. Refer to the NIST Post-Quantum Cryptography project for canonical specifications.
TLS 1.3 Hybrid Key Exchange Today
Hybrid key exchange combines a classical algorithm (X25519) with a post-quantum KEM (ML-KEM-768) so the resulting session key is secure as long as either component is unbroken. The IANA-registered codepoint X25519MLKEM768 is now supported by Chrome, Firefox, BoringSSL, OpenSSL 3.5, and major load balancers. This is the recommended deployment posture for the next 3–5 years.
However, hybrid handshakes increase the ClientHello size enough to trigger TCP segmentation, which exposed bugs in some middleboxes during early rollouts. Cloudflare published detailed measurements showing roughly 0.05% of connections fail outright due to MTU-sensitive intermediaries. Consequently, you must monitor TLS handshake error rates carefully during initial deployment.
// Java 24+ TLS configuration with hybrid PQC key exchange
import javax.net.ssl.*;
import java.security.*;
import java.security.spec.*;
public class HybridTLSServer {
public static SSLContext createHybridContext(KeyStore ks, char[] pwd) throws Exception {
// Java 24 enables ML-KEM and X25519MLKEM768 by default in TLS 1.3
System.setProperty("jdk.tls.namedGroups",
"x25519mlkem768,x25519,secp256r1,secp384r1");
System.setProperty("jdk.tls.signatureSchemes",
"ml_dsa_65,ecdsa_secp256r1_sha256,rsa_pss_rsae_sha256");
KeyManagerFactory kmf = KeyManagerFactory.getInstance("PKIX");
kmf.init(ks, pwd);
TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX");
tmf.init(ks);
SSLContext ctx = SSLContext.getInstance("TLSv1.3");
ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), SecureRandom.getInstanceStrong());
SSLParameters params = ctx.getDefaultSSLParameters();
params.setProtocols(new String[] { "TLSv1.3" });
params.setNamedGroups(new String[] { "x25519mlkem768", "x25519" });
return ctx;
}
}
Building a Cryptographic Bill of Materials
You cannot migrate what you cannot find. The Cryptography Bill of Materials (CBOM) extension to CycloneDX gives you a structured inventory of every algorithm, key length, certificate, and protocol in your software supply chain. We generated CBOMs for all 1,400 services using a combination of static analysis (CryptoREPL, IBM CBOMkit) and runtime tracing of TLS connections.
The output revealed surprises: 14% of internal services still used SHA-1 in HMAC contexts, three legacy systems used 1024-bit RSA, and one critical service depended on a hardcoded RC4 cipher for compatibility with a vendor library. Subsequently, we prioritized those discoveries before tackling PQC migration. This kind of inventory work pairs well with our secret scanning guide for full supply chain visibility.
Certificate Lifecycle and Bigger Keys
ML-DSA-65 public keys are roughly 1,952 bytes and signatures are roughly 3,309 bytes, compared to 32 bytes and 64 bytes for Ed25519. Consequently, certificates roughly triple in size, which has cascading effects on TLS handshake bandwidth, OCSP responses, and certificate transparency logs. For high-volume CDN edges, this is meaningful.
Additionally, the certificate authority ecosystem is still rolling out PQC issuance. Let’s Encrypt published a roadmap targeting 2027 for production PQC certificates, while DigiCert and GlobalSign have early-access PQC programs available now. For internal PKI, you can move faster: Smallstep, HashiCorp Vault, and AWS Private CA all support ML-DSA issuance in their current releases.
Migration Phases That Actually Work
We structured the rollout in five phases over 18 months. Phase 1 was inventory and CBOM generation. Phase 2 was hybrid TLS deployment for external-facing services with feature flags. Phase 3 covered internal mTLS migration. Phase 4 addressed signing operations (JWT, code signing, document signing). Finally, Phase 5 was deprecation of classical-only paths once telemetry showed sufficient hybrid adoption.
Critically, we never disabled classical algorithms during the rollout. Hybrid mode keeps classical algorithms as a fallback, and removing them prematurely creates outages when intermediaries do not support PQC. The defensive posture is “add PQC, keep classical, monitor, then deprecate” over a multi-year horizon similar to patterns in our mTLS and certificate pinning guide.
# nginx 1.27+ with OpenSSL 3.5 hybrid PQC configuration
server {
listen 443 ssl http2;
listen 443 quic reuseport;
server_name api.example.com;
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;
# Hybrid PQC key exchange - X25519+ML-KEM-768
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1;
# Dual-stack certificates: classical + PQC
ssl_certificate /etc/nginx/certs/api-ecdsa.crt;
ssl_certificate_key /etc/nginx/certs/api-ecdsa.key;
ssl_certificate /etc/nginx/certs/api-mldsa65.crt;
ssl_certificate_key /etc/nginx/certs/api-mldsa65.key;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# Telemetry for handshake monitoring
log_format pqc_handshake '$remote_addr $ssl_protocol $ssl_cipher $ssl_curve $request_time';
access_log /var/log/nginx/pqc.log pqc_handshake;
}
Cloud Provider Rollout Timelines
AWS announced PQC support for AWS KMS, ACM, and CloudFront with ML-KEM hybrid handshakes in early 2026 across all regions. Google Cloud Load Balancing supports X25519MLKEM768 since late 2024 in the global tier. Cloudflare led the field, enabling X25519Kyber768Draft00 in 2023 and migrating to the standardized X25519MLKEM768 codepoint in mid-2024.
For HSM-backed signing operations, support lags. AWS CloudHSM added ML-DSA in early 2026, while Thales Luna and Entrust nShield are shipping PQC firmware updates throughout 2026. Plan accordingly: HSM-bound keys cannot be migrated by software changes alone.
In conclusion, post-quantum cryptography migration is a multi-year program, not a sprint. Start with cryptographic inventory, deploy hybrid TLS to externally-facing services first, plan for tripled certificate sizes, and never remove classical algorithms until telemetry proves it safe. The data you protect today must remain confidential for decades, and adversaries are already harvesting. After 18 months on this program, our hybrid TLS coverage hit 94% of services and our remaining classical-only paths are now scheduled for retirement by Q3 2027.