Cloudflare lets you see which traffic is post-quantum

Cloudflare customers can now see whether the traffic hitting their domains is actually protected with post-quantum encryption, rather than taking the platform's word for it at the aggregate level.

The company has added post-quantum TLS key exchange data to Logpush, Log Explorer and the HTTP Traffic Analytics dashboard, exposing the algorithm negotiated on each incoming connection.

From network averages to individual domains

Cloudflare already publishes Internet-wide post-quantum adoption figures through Cloudflare Radar. Those numbers say roughly 70% of browser-generated traffic reaching its network uses hybrid ML-KEM, the post-quantum key agreement standardised under FIPS 203.

The origin side of the same connection is far less prepared. Only about 15% of the origins Cloudflare connects to use hybrid ML-KEM, which is why the new per-domain telemetry matters more than another global chart.

Until now Cloudflare exposed the TLS version used at a domain, but not the cryptographic algorithms behind it, so customers could not answer a simple question about what fraction of their traffic was post-quantum.

Harvest now, decrypt later

The deadline driving this is not hypothetical. NIST said in 2024 that RSA and elliptic curve cryptography should be deprecated by 2030, and Cloudflare says it is targeting full post-quantum security by 2029.

The threat is harvest-now-decrypt-later: an adversary records encrypted traffic today and decrypts it once sufficiently powerful quantum computers exist. Data that stays sensitive for a decade is already exposed.

In TLS 1.3 the only recommended post-quantum key exchange group is X25519MLKEM768, which combines a classical X25519 exchange with ML-KEM so the shared secret stays safe if either half holds. Post-quantum encryption is not available in TLS 1.2 or earlier, and X25519MLKEM768 is now the preferred group in most major browsers.

What customers can actually do with it

The TLS key exchange group appears as a card in the HTTP Traffic dashboard and can be used as a filter, so an operator can isolate the connections still falling back to classical algorithms.

For line-by-line investigation, Cloudflare has added a ClientTLSKeyExchangeGroup field to the HTTP Requests dataset, plus OriginTLSKeyExchangeGroup to cover the Cloudflare-to-origin leg and give end-to-end visibility.

If a domain shows no post-quantum use at all, Cloudflare's first suggestion is to check that TLS 1.3 is switched on, since there is no separate post-quantum toggle and negotiation is automatic once TLS 1.3 is enabled. For origins too old to support modern cryptography, the recommended workaround is putting the origin behind Cloudflare Tunnel.

Our opinion

Cloudflare has spent this year announcing post-quantum features at a pace that makes the missing piece conspicuous in hindsight. Encrypting everything by default is only half a migration if nobody can prove what got encrypted.

The 70% versus 15% split between browsers and origins is the most useful fact in the announcement. It says the browser vendors have largely finished their half of the job while server estates have barely started, and it puts the weak end of the connection where it has always been - on infrastructure nobody wants to touch.

Exposing the key exchange group in logs is a genuinely better compliance argument than a dashboard percentage, because it turns a policy claim into an auditable per-connection record. Regulators asking for quantum-readiness evidence by 2030 will want exactly that.

The caveat is that Cloudflare's answer to a legacy origin is to route it through Cloudflare Tunnel, which is also the answer that keeps the traffic on Cloudflare. Permission to inspect encryption is being handed out by the same platform being inspected, and that is worth remembering when the audit trail is the selling point.