Post-quantum TLS: what's actually shipping in 2026

NIST finalized FIPS 203 (ML-KEM, the Kyber successor) in August 2024. Twenty months later, post-quantum key exchange isn't science fiction — it's ~25% of Chrome's TLS 1.3 handshakes per Cloudflare's published telemetry. If you operate web infrastructure and haven't looked at this, you're already behind. Here's the operational state in 2026.

The threat the math is solving

Shor's algorithm running on a sufficiently large quantum computer breaks ECDH and RSA in polynomial time. Estimates of when "sufficiently large" exists range from 2030 to 2045. The risk for TLS today is "harvest now, decrypt later" (HNDL): a state-level adversary records your TLS traffic now and decrypts it in 2035. Forward secrecy doesn't save you — ECDH ephemerals are also breakable.

ML-KEM (a lattice-based KEM) replaces the key exchange step. The handshake is otherwise unchanged. Authentication (your X.509 cert chain) is still RSA/ECDSA — that's a separate migration (ML-DSA, FIPS 204, much harder rollout).

Hybrid is the only sensible deployment

Pure ML-KEM isn't deployed in production. The risk: a yet-undiscovered weakness in the lattice problem makes the whole scheme breakable classically. We've seen this before (SIDH/SIKE got cryptanalyzed in 2022 after years of "promising candidate" status).

Hybrid combines both: X25519MLKEM768 performs both X25519 and ML-KEM-768, and the shared secret is HKDF-mixed from both outputs. To break the handshake an attacker needs to break both primitives. This is the IETF consensus and what Chrome+Cloudflare ship.

What the +1184 bytes break

The ClientHello jumps from ~600 bytes to ~1700 bytes. This crosses the 1500-byte Ethernet MTU and matters for two reasons:

• UDP/QUIC. A QUIC initial packet now arrives in two datagrams. Some middleboxes drop the second. Cloudflare reported handshake failures localized to specific ASNs (mostly enterprise NAT/firewall vendors) when they enabled hybrid in 2023.
• TCP TLS. The TLS record fragments across multiple TCP segments. Mostly transparent, but we've seen broken TLS-inspecting proxies (Palo Alto, Fortinet older versions) reject the fragmented hello.

You will not spot this in normal monitoring. Affected users see "your connection isn't private" and switch browsers. Watch for spikes in your TLS handshake error rate when you turn hybrid on.

Server-side: who supports what

The minimum viable deployment

For nginx in 2026:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;

Order matters: hybrid first, classical fallback. A client that doesn't speak hybrid (older browser, your monitoring tool, your Go service) negotiates X25519. A client that speaks hybrid uses it. Zero migration cost for the long tail.

What about authentication (signatures)?

ML-DSA is not yet deployed for TLS certs in 2026. Reasons:

• WebPKI roots aren't issuing ML-DSA chains. Let's Encrypt has experimental support but no production rollout.
• ML-DSA signatures are ~3 KB vs ECDSA's ~70 bytes. Cert chain explodes from ~3 KB to ~12 KB. Painful for QUIC.
• The HNDL threat doesn't apply to signatures — by the time a quantum computer can break ECDSA, you've rotated certs many times. The classical chain stays useful while we wait.

Plan for hybrid signatures circa 2027-2028. For now, focus on hybrid KEM.

UnveilScan and PQ

Our tls_extended checker reports the negotiated key exchange group. If your endpoint advertises X25519MLKEM768, it shows in the raw_data block. We don't currently emit a finding for "you don't have PQ" — it's not a security defect, it's a future-proofing gap. We'll likely add an INFO-tier finding for this in late 2026 once the hybrid rollout passes 50% market share.