The Landscape After NIST Finalisation

In August 2024, NIST published three post-quantum cryptographic standards — FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+). A fourth standard based on FALCON (FN-DSA) is expected shortly. These are no longer draft candidates. They are finalised, assigned FIPS numbers, and carry compliance expectations.

For web operators, hosting providers, and infrastructure teams, the question has shifted from "which algorithms will win?" to "what do we change, and in what order?"

This article covers the practical migration steps relevant to web infrastructure — TLS configuration, certificate management, dependency auditing, and timeline planning. It is not a cryptography primer; it assumes you understand that sufficiently powerful quantum computers threaten RSA and elliptic-curve cryptography, and that the standards above are the replacements.

The Three Standards You Need to Know

ML-KEM (FIPS 203) — Key Encapsulation

ML-KEM replaces key-exchange mechanisms like ECDH. It is a lattice-based key encapsulation mechanism (KEM) with three parameter sets:

Parameter Set Security Level Public Key Size Ciphertext Size
ML-KEM-512 ~AES-128 equivalent 800 bytes 768 bytes
ML-KEM-768 ~AES-192 equivalent 1,184 bytes 1,088 bytes
ML-KEM-1024 ~AES-256 equivalent 1,568 bytes 1,568 bytes

For TLS key exchange, ML-KEM-768 is the expected default. Chrome and Firefox already ship hybrid key exchange using ML-KEM-768 combined with X25519 (the X25519MLKEM768 named group in TLS 1.3).

ML-DSA (FIPS 204) — Digital Signatures

ML-DSA replaces RSA and ECDSA for digital signatures. It appears in certificate chains — server certificates, intermediate certificates, and root certificates will eventually use ML-DSA.

Parameter Set Security Level Public Key Size Signature Size
ML-DSA-44 ~AES-128 equivalent 1,312 bytes 2,420 bytes
ML-DSA-65 ~AES-192 equivalent 1,952 bytes 3,309 bytes
ML-DSA-87 ~AES-256 equivalent 2,592 bytes 4,627 bytes

The signature and key sizes are substantially larger than ECDSA (which uses 32–64 byte signatures and 32–64 byte public keys). This has real implications for TLS handshake performance and certificate chain transmission.

SLH-DSA (FIPS 205) — Hash-Based Signatures

SLH-DSA is a stateless hash-based signature scheme. It is conservative (based only on hash-function security) but produces significantly larger signatures — ranging from approximately 7 KB to 49 KB depending on the parameter set. It serves as a fallback if lattice-based assumptions prove weaker than expected.

For most web infrastructure, ML-KEM and ML-DSA are the immediate priorities. SLH-DSA is relevant for high-assurance environments where conservative assumptions matter more than performance.

What Web Operators Should Do Now

Step 1: Inventory Your Cryptographic Dependencies

Before changing anything, understand what you currently depend on. Create an inventory covering:

  • [ ] TLS termination points — Which servers, load balancers, CDN edges, or reverse proxies terminate TLS? What software and version handles the handshake?
  • [ ] Certificate authorities — Who issues your certificates? Do they offer PQC certificates yet?
  • [ ] Key exchange algorithms — What does your TLS configuration currently negotiate? Check with openssl s_client or Qualys SSL Labs.
  • [ ] Signature algorithms in certificates — RSA-2048? RSA-4096? ECDSA P-256?
  • [ ] Code-signing certificates — Software releases, firmware, container images
  • [ ] SSH keys — Server host keys, deployment keys, developer access keys
  • [ ] VPN configurations — IPsec/IKEv2 settings, WireGuard keys
  • [ ] API authentication — JWTs signed with RSA or ECDSA, mutual TLS
  • [ ] Stored encrypted data — Anything encrypted today that must remain confidential for 10+ years (the "harvest now, decrypt later" threat)

Step 2: Enable Hybrid Key Exchange in TLS

This is the single most impactful change you can make today. Hybrid key exchange combines a classical algorithm (X25519 or P-256) with a post-quantum KEM (ML-KEM-768). If the PQC algorithm has an undiscovered weakness, the classical algorithm still provides security. If a quantum computer breaks the classical algorithm, the PQC algorithm still provides security.

For Cloudflare-fronted sites: Hybrid key exchange is enabled by default. Cloudflare has supported X25519Kyber768 (now X25519MLKEM768) since 2024. Verify by checking the TLS handshake details in your browser's security panel — the key exchange should show X25519MLKEM768.

For Nginx with OpenSSL 3.5+:

ssl_ecdh_curve X25519MLKEM768:X25519:P-256;

For Apache with OpenSSL 3.5+:

SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256

For HAProxy:

ssl-default-bind-curves X25519MLKEM768:X25519:P-256

Verification:

openssl s_client -connect your-domain.com:443 -groups X25519MLKEM768 2>&1 | grep "Server Temp Key"
# Should show: Server Temp Key: X25519MLKEM768

Step 3: Test for Handshake Size Impacts

ML-KEM adds approximately 1,100 bytes to the TLS ClientHello (for ML-KEM-768). This has caused real-world breakage:

  • Firewalls and intrusion detection systems that reject oversized ClientHello messages
  • Load balancers with small buffer defaults that truncate the handshake
  • Middleboxes and enterprise proxies that cannot parse the larger key shares
  • Network equipment with small MTU or fragmentation issues

Test by connecting with a client that sends a PQC key share and verifying the handshake completes:

# Using curl with OpenSSL 3.5+
curl -v --curves X25519MLKEM768 https://your-domain.com 2>&1 | grep "SSL connection"

# If the handshake fails, try without PQC to confirm the issue is size-related
curl -v --curves X25519 https://your-domain.com 2>&1 | grep "SSL connection"
  • [ ] Test from multiple network paths (different ISPs, VPN, mobile)
  • [ ] Test through any enterprise proxies or firewalls in your environment
  • [ ] Monitor TLS handshake error rates after enabling hybrid key exchange
  • [ ] Confirm that TCP Fast Open and TLS 1.3 0-RTT still function correctly

Step 4: Plan for PQC Certificates (But Do Not Rush)

PQC certificates (using ML-DSA signatures) are not yet widely deployed in the Web PKI. The transition requires:

  1. Root CAs issuing ML-DSA root certificates
  2. Browsers including those roots in their trust stores
  3. Intermediates and leaf certificates using ML-DSA
  4. The entire chain fitting within practical size limits

The challenge is that an ML-DSA-65 certificate chain (root + intermediate + leaf) will be approximately 10–15 KB, compared to roughly 3 KB for an ECDSA chain. This increases TLS handshake time, especially on high-latency connections.

What to do now:

  • [ ] Monitor your CA's PQC roadmap (Let's Encrypt, DigiCert, Sectigo all have published timelines)
  • [ ] Test with experimental PQC certificates in staging environments
  • [ ] Evaluate whether your TLS termination software supports ML-DSA certificates
  • [ ] Plan for hybrid certificates (containing both classical and PQC signatures) as a transition mechanism

Step 5: Address SSH and Internal Services

SSH is often overlooked in PQC planning. OpenSSH 9.x supports hybrid key exchange using [email protected], which combines a lattice-based KEM (Streamlined NTRU Prime) with X25519.

# Check current SSH key exchange algorithms
ssh -Q kex

# Force hybrid key exchange
ssh -o [email protected] user@host

For SSH host keys and user keys, ML-DSA support is in active development. Monitor OpenSSH release notes.

  • [ ] Enable hybrid key exchange on all SSH servers
  • [ ] Test automated deployment pipelines that use SSH
  • [ ] Plan for ML-DSA SSH keys when support stabilises

UK NCSC and International Guidance

The UK National Cyber Security Centre (NCSC) published migration guidance recommending that organisations begin planning now, with key milestones:

  • 2024–2026: Inventory cryptographic dependencies, enable hybrid key exchange where possible, begin testing PQC algorithms
  • 2027–2030: Migrate to PQC certificates, deprecate purely classical key exchange, update internal services
  • 2030–2035: Complete migration, remove classical-only fallbacks

The NCSC specifically advises against waiting for a "flag day" migration. The transition should be incremental, with hybrid modes providing backward compatibility.

The US Cybersecurity and Infrastructure Security Agency (CISA) echoes this with their Post-Quantum Cryptography Initiative, emphasising inventory and prioritisation as immediate actions.

Timeline for Web Infrastructure

Timeframe Action Priority
Now Inventory cryptographic dependencies High
Now Enable hybrid TLS key exchange (ML-KEM + X25519) High
Now Test for handshake size breakage High
Now Enable hybrid SSH key exchange Medium
2026–2027 Test PQC certificates in staging Medium
2027–2028 Deploy hybrid certificates in production Medium
2028–2030 Migrate code-signing to ML-DSA Medium
2030+ Deprecate classical-only configurations Low (currently)

Gotchas

"Post-quantum" does not mean "post-classical." PQC algorithms protect against quantum attacks, but they must also resist classical attacks. ML-KEM and ML-DSA are designed for both. Do not remove classical protections prematurely — use hybrid modes.

Performance is measurably different. ML-KEM key generation and encapsulation are fast — often faster than ECDH. But ML-DSA signature verification is slower than ECDSA, and the larger key and signature sizes increase bandwidth. Benchmark in your environment before deploying at scale.

Not all "Kyber" is ML-KEM. Early implementations used draft versions of Kyber (round 2, round 3) that are not compatible with the final FIPS 203 standard. Chrome's transition from X25519Kyber768Draft00 to X25519MLKEM768 in late 2024 caused some interoperability issues. Ensure your implementations use the finalised standard.

CDN support varies. Cloudflare has comprehensive PQC support. AWS CloudFront and Azure Front Door support is rolling out. Verify your specific CDN's capabilities before assuming hybrid key exchange is active.

Certificate transparency logs must accommodate larger PQC certificates. This is a CA and browser-ecosystem concern, but it affects monitoring tools that parse CT logs.

Verification Checklist

After implementing changes, verify each layer:

  • [ ] TLS handshake completes successfully with hybrid key exchange from multiple client types
  • [ ] No increase in TLS handshake error rates in monitoring
  • [ ] SSH connections succeed with hybrid key exchange
  • [ ] No firewall or middlebox interference with larger ClientHello
  • [ ] Cryptographic inventory document is complete and version-controlled
  • [ ] Team has reviewed NCSC and CISA PQC migration guidance
  • [ ] Staging environment includes PQC certificate testing capability
  • [ ] Monitoring alerts exist for TLS handshake failures

Further Reading