Post-Quantum TLS in 2026: What's Already Live in Your Browser

Post-quantum TLS is deployed, not theoretical. Every major browser negotiates the hybrid key exchange X25519MLKEM768 by default today, and over two-thirds of browser traffic reaching Cloudflare is now post-quantum protected (June 2026). It protects the key exchange — defeating "harvest now, decrypt later" — while post-quantum certificates remain years out. To get it, you need a TLS 1.3 stack built against OpenSSL 3.5+ (or equivalent) with the hybrid group enabled; on most CDNs you already have it for free.

The Threat: Harvest Now, Decrypt Later

A sufficiently large quantum computer running Shor's algorithm breaks RSA, DH, and ECDH in polynomial time. We don't have one yet. The optimistic estimates put a cryptographically-relevant quantum computer (CRQC) at 10–20 years away; the pessimistic ones at fewer than ten. The exact number doesn't matter, because of one attacker behaviour:

This is why the rollout is happening now, years before quantum computers can break anything. Key exchange (the part that establishes the symmetric session key) is the urgent fix; signatures (certificates) can wait, because forging a signature retroactively is useless.

What NIST Standardised

On 13 August 2024, NIST published the first three post-quantum standards. These replace roughly the entire current asymmetric stack:

A fourth — FN-DSA (Falcon) — is in draft as FIPS 206 for cases where signature size matters more than verification speed.

What's Live in TLS 1.3 Today

X25519MLKEM768 — the hybrid that won

The current production deployment is a hybrid: classical X25519 ECDH combined with ML-KEM-768. The shared secret is derived from both, so it stays secure if either primitive breaks. The IETF assigned codepoint 0x11EC for this group, published as RFC 9794 (draft-kwiatkowski-tls-ecdhe-mlkem) in early 2025.

Browser and server support, as of July 2026

Enabling the hybrid on nginx

# nginx with OpenSSL 3.5+
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

The hybrid group adds roughly 1.1 KB to the ClientHello and a similar amount to the ServerKeyExchange — the only real cost. CPU overhead is negligible because ML-KEM is fast (often faster than the X25519 it accompanies).

What About Certificates?

Key exchange got PQ-safe first because of harvest-now-decrypt-later. Certificates are next, but the timeline is longer:

• Let's Encrypt has been issuing experimental ML-DSA-44 certificates from a staging root since late 2025. Production issuance is gated on browser root-store inclusion.
• Mozilla opened its CCADB programme to PQ roots in early 2026; first inclusion decisions are expected late 2026 / early 2027.
• Chrome (Chromium) has reserved codepoints and signature schemes; shipping support for PQ certificate validation is in nightly builds.
• Signature size is the bottleneck. An ML-DSA-65 signature is ~3.3 KB, versus 64 bytes for ECDSA P-256. Full PQ chains will materially increase handshake bytes. Expect hybrid certificates (classical + PQ) as the transitional form.

What You Should Actually Do

If you run servers

1. Upgrade OpenSSL/BoringSSL. OpenSSL 3.5 LTS is the practical floor.
2. Add X25519MLKEM768 to your supported groups. Keep classical X25519 in the list so older clients still work.
3. Test with our PQC checker to confirm the hybrid is being negotiated.
4. Inventory your high-sensitivity flows. Anything with a 10-year-plus confidentiality requirement should be on PQ today — not after audit.

If you build software

1. Use modern, vetted libraries (OpenSSL 3.5+, BoringSSL, rustls). Never hand-implement ML-KEM.
2. Plan for hybrid certificate handling — larger chains, longer handshakes, new signature algorithm IDs.
3. Audit your dependencies. Many cryptographic libraries pinned to older releases lack PQ support. Pin updates.

If you set policy

1. Executive Order 14412 (signed 22 June 2026) puts hard dates on US federal PQC migration. Agencies had to name a migration lead by July 2026 and submit migration plans to OMB by September 2026. High Value Assets and high-impact systems must reach post-quantum encryption by 31 December 2030 and post-quantum authentication (signatures) by 31 December 2031. Covered federal contractors must comply with NIST PQC standards by 31 December 2030 — a year ahead of the agencies' own signature deadline. National Security Systems are excluded and run to the NSA's separate timeline.
2. NSA CNSA 2.0 requires CNSSP-15 systems to use FIPS 203/204 from 2027, with full migration by 2033.
3. UK NCSC and BSI Germany published similar transition guidance in 2024–25.
4. Get the cryptographic inventory done in 2026. Migration in 2027–28. Audit in 2029.

Common Misconceptions

"My provider is Cloudflare, I'm fine."

Cloudflare's edge negotiates PQ-hybrid with browsers, but the connection from Cloudflare to your origin is a separate TLS session. If your origin doesn't support PQ, the leg from edge to origin is still harvestable. Enable it on both sides.

"TLS 1.3 already protects me."

TLS 1.3 forward secrecy means a current key-exchange compromise won't expose past sessions — but only if the underlying primitive (X25519) stays secure. Against a future CRQC, X25519 isn't secure. Forward secrecy is necessary, not sufficient.

"This is years away."

The deployment is happening now. Chrome and Firefox have negotiated hundreds of billions of PQ-hybrid handshakes since late 2024. Whether the threat materialises in 2032 or 2042 is a separate question from whether your traffic is being recorded today.

Related Articles