Cloudflare Adds Domain-Level Post-Quantum TLS Visibility

Cloudflare said on September 29, 2026 that customers can now see which TLS key exchange groups are used by traffic to their proxied domains. The new view helps site owners measure adoption of hybrid post-quantum TLS 1.3 without treating a domain or certificate as automatically quantum-safe.

What changed

Cloudflare has added a TLS Key Exchange view to HTTP Traffic Analytics for visitor-to-Cloudflare requests. The same information can appear in Log Explorer and Logpush through the ClientTLSKeyExchangeGroup field. For Cloudflare-to-origin connections, Logpush offers a separate OriginTLSKeyExchangeGroup field. Cloudflare announced these additions on September 29; they apply to domains whose web traffic is proxied through its service, with access to individual analytics and log products depending on the customer’s setup.

What the result means

A connection labeled X25519MLKEM768 used a hybrid TLS 1.3 key exchange that combines a conventional elliptic-curve method with ML-KEM. Classical groups such as X25519 or P-256 do not indicate that hybrid exchange. A NONE value is ambiguous: Cloudflare says it can mean RSA key exchange or no TLS. For origin logs, UNK can also mean there was no origin connection, such as a cache hit.

The measurement covers the key exchange on a particular connection. It does not establish that a whole website, its certificate authentication, or its DNS is post-quantum. Our earlier report on Cloudflare’s post-quantum DNSSEC validation concerns a different part of Internet security. Site owners reviewing the conventional certificate side of their setup can also see NicNames’ SSL certificate options; these are separate from Cloudflare’s new key-exchange telemetry.

Why site owners may care

For a domain already using Cloudflare’s proxy, the new data can reveal whether modern browsers are negotiating hybrid TLS and whether older or non-browser clients are still using classical methods. Cloudflare says there is no separate post-quantum switch for visitor connections: when TLS 1.3 is enabled and a client supports X25519MLKEM768, it is negotiated automatically. Owners should interpret the figures in the context of their actual visitor mix and check the visitor and origin legs separately before drawing conclusions about their security posture.