Post-Quantum TLS in 2026: What's Already Live in Your Browser
Post-quantum cryptography stopped being a slideware topic somewhere around late 2024. Today, every major browser ships a post-quantum-safe key exchange by default, NIST has standardised the algorithms, and the first quantum-safe TLS certificates are being issued in test environments. Here's what's actually deployed, what's coming next, and what you should do about it.
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:
| Standard | Algorithm | Replaces | Used For |
|---|---|---|---|
| FIPS 203 | ML-KEM (CRYSTALS-Kyber) | RSA, ECDH, X25519 | Key encapsulation / TLS key exchange |
| FIPS 204 | ML-DSA (CRYSTALS-Dilithium) | RSA-PSS, ECDSA | Digital signatures / certificates |
| FIPS 205 | SLH-DSA (SPHINCS+) | RSA-PSS, ECDSA | Stateless hash-based signatures (firmware, backup) |
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, May 2026
| Implementation | Status | Notes |
|---|---|---|
| Chrome / Edge | Enabled by default | Since Chrome 131 (Nov 2024) |
| Firefox | Enabled by default | Since Firefox 132 (Oct 2024) |
| Safari (macOS / iOS) | Enabled by default | Since Safari 18.2 (Dec 2024) / iOS 18.2 |
| OpenSSL | Native support | OpenSSL 3.5 LTS (2025) |
| BoringSSL | Native support | Powers Chrome, Cloudflare, AWS endpoints |
| Cloudflare edge | Enabled everywhere | Reports >40% of TLS 1.3 handshakes are PQ-hybrid |
| AWS, Google, Apple endpoints | Enabled | iCloud, GCP load balancers, AWS s2n-tls |
| nginx (with OpenSSL 3.5) | Available, not default | Add X25519MLKEM768 to ssl_ecdh_curve |
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
- Upgrade OpenSSL/BoringSSL. OpenSSL 3.5 LTS is the practical floor.
- Add
X25519MLKEM768to your supported groups. Keep classical X25519 in the list so older clients still work. - Test with our PQC checker to confirm the hybrid is being negotiated.
- 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
- Use modern, vetted libraries (OpenSSL 3.5+, BoringSSL, rustls). Never hand-implement ML-KEM.
- Plan for hybrid certificate handling — larger chains, longer handshakes, new signature algorithm IDs.
- Audit your dependencies. Many cryptographic libraries pinned to older releases lack PQ support. Pin updates.
If you set policy
- NSA CNSA 2.0 requires CNSSP-15 systems to use FIPS 203/204 from 2027, with full migration by 2033.
- UK NCSC and BSI Germany published similar transition guidance in 2024–25.
- 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.