Post-Quantum TLS in 2026: Most Browser Traffic Is Already Protected. Is Your Site?

Every HTTPS connection starts with a key exchange: browser and server agree on a secret key over a network anyone can watch. Today that exchange almost always uses elliptic-curve Diffie-Hellman, usually the curve X25519. Its security rests on a maths problem — the discrete logarithm on elliptic curves — that classical computers can't solve in any useful time.

A large enough quantum computer could. Shor's algorithm solves exactly that problem efficiently. No quantum computer today is anywhere near large enough, and estimates of when one might be range from several years to never.

The reason to act now anyway is "harvest now, decrypt later". An adversary can record encrypted traffic today and store it. If a capable quantum computer appears in ten years, everything recorded can be decrypted then: medical records, diplomatic cables, private messages, credentials that are still valid. For data that must stay secret for a decade or more, the threat is already here.

Only the key exchange needs fixing urgently for this reason. Certificates and signatures prove who you're talking to *at the moment of connection*; forging one later doesn't help decrypt a recording.

In August 2024 NIST published FIPS 203, standardising ML-KEM (formerly known as Kyber), a key-encapsulation mechanism based on lattice problems that no known quantum algorithm solves efficiently.

Browsers didn't switch to ML-KEM alone. They deployed a hybrid: X25519MLKEM768 runs a classical X25519 exchange and an ML-KEM-768 exchange at the same time and combines both secrets. An attacker has to break both. If ML-KEM turns out to have an undiscovered weakness — it's much newer than elliptic curves — the connection is still as strong as classical TLS today. If quantum computers arrive, ML-KEM still holds.

Chrome made the hybrid its default in late 2024, and Edge, Firefox and Apple's platforms followed. Because the browser offers it automatically, a site gets post-quantum key exchange as soon as its server or CDN supports it — no certificate change and no configuration on the user's side.

The cost is size, not speed. An ML-KEM-768 key share is about 1.2 KB instead of 32 bytes for X25519, which makes the TLS ClientHello larger than one network packet. That broke a small number of middleboxes that assumed a ClientHello always fits in a single packet, but the computation itself is fast.

Cloudflare publishes the most detailed numbers because it sees a large share of web traffic. Its figures show how quickly the change happened:

• Start of 2025: 29% of human traffic to Cloudflare used post-quantum key exchange.
• December 2025: 52%.
• Spring 2026: "over two-thirds" of human-generated TLS traffic.
• 29 September 2026: about 70% of browser traffic to Cloudflare is protected with hybrid ML-KEM.

The other half of the picture is much less advanced. In the same post, Cloudflare reported that only about 15% of origin servers it connects to support hybrid ML-KEM. So a visitor's connection to a CDN is often post-quantum, while the CDN's connection back to the site's own server frequently isn't.

When we tested a few well-known sites on 20 October 2026, Cloudflare, Google and lookmyip.com (served through our hosting provider's edge network) negotiated X25519MLKEM768. GitHub negotiated classical X25519.

You need OpenSSL 3.5 or later, which includes ML-KEM. Check with openssl version. Then offer the hybrid group first, with X25519 as a fallback, and see which one the server picks:

$ echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com \
    -groups X25519MLKEM768:X25519 2>/dev/null | grep -i 'group\|temp key'
Negotiated TLS1.3 group: X25519MLKEM768

A server without post-quantum support falls back to the classical curve:

$ echo | openssl s_client -connect github.com:443 -servername github.com \
    -groups X25519MLKEM768:X25519 2>/dev/null | grep -i 'group\|temp key'
Peer Temp Key: X25519, 253 bits

Offering *only* the hybrid group (-groups X25519MLKEM768) to a server that doesn't support it ends in a handshake failure, which is a quick yes-or-no test.

In a browser, Chrome's DevTools shows it too: open the Security panel and look at the connection's key exchange, which reads X25519MLKEM768 when the hybrid is in use.

Behind a CDN: Cloudflare, Google Cloud and Vercel's edge networks already negotiate hybrid ML-KEM with browsers by default, and other large CDNs have been rolling it out — test yours with the command above. Check the connection from your CDN to your origin separately; that's where most sites are still classical.

nginx, Apache, HAProxy and others built on OpenSSL: upgrade to OpenSSL 3.5 or later. It offers X25519MLKEM768 by default, so a server built against it typically negotiates the hybrid with modern browsers without configuration changes. If your configuration sets an explicit group list (ssl_ecdh_curve in nginx), add X25519MLKEM768 at the front.

Go: crypto/tls enables X25519MLKEM768 by default from Go 1.24. Recent BoringSSL and AWS-LC builds also support it.

Older systems: Linux distributions with long support cycles may still ship OpenSSL 3.0, which has no ML-KEM. The usual route is a TLS-terminating proxy or load balancer in front that does support it.

TLS 1.3 is required: the hybrid groups are only defined for TLS 1.3.

Hybrid key exchange protects confidentiality. Several things still rely on classical cryptography:

• Certificates and signatures. Every certificate on the web is still signed with RSA or ECDSA. Post-quantum signature schemes (NIST's ML-DSA, FIPS 204) produce much larger signatures, and fitting them into TLS without slowing every handshake is an active area of work. This is less urgent: as explained above, signatures can't be broken retroactively. Cloudflare has set 2029 as its target for full post-quantum security, including authentication.
• TLS 1.2 connections, which can't use the hybrid groups at all.
• Everything outside HTTPS: SSH (OpenSSH has used a hybrid post-quantum exchange by default since version 9.0, so it's in better shape than most), VPNs, email transport between mail servers, and DNSSEC.

For most website operators the action list is short: make sure your CDN or server offers X25519MLKEM768 to browsers, check the hop from CDN to origin, and keep TLS libraries current so the certificate changes arrive through normal updates when they're ready.