# Cloudflare adds per-domain TLS key exchange visibility

> New analytics and log fields expose negotiated TLS key exchange groups, helping engineers assess post-quantum encryption on visitor and origin connections.

Canonical URL: https://www.devobs.io/news/news-event-69d122bb0a4d34d3a67e7906/
By: Lena Fischer
Published: 2026-10-02T11:28:06.772Z
Updated: 2026-10-02T11:28:06.772Z
Event date: 2026-09-29
Section: Security

Cloudflare says operators can now inspect negotiated TLS key exchange groups for traffic to individual domains through HTTP Traffic Analytics, Log Explorer and Logpush. The telemetry helps distinguish post-quantum key agreement from classical-only connections, with separate fields for visitor and origin traffic. [Cloudflare’s announcement](https://blog.cloudflare.com/post-quantum-visibility/) describes the features as available now.

## Where the data appears

Cloudflare describes the following views in its [announcement](https://blog.cloudflare.com/post-quantum-visibility/):

- **HTTP Traffic Analytics:** A TLS Key Exchange card shows groups negotiated on visitor-to-Cloudflare connections. Operators can also filter traffic by key exchange group.
- **Log Explorer and Logpush:** The new `ClientTLSKeyExchangeGroup` field can be enabled under the TLS category in the HTTP Requests dataset to inspect visitor-side key exchange in individual request logs.
- **Origin-side Logpush data:** `OriginTLSKeyExchangeGroup` exposes the group used on the Cloudflare-to-origin connection. Cloudflare says this origin-side group is not displayed in the HTTP Traffic Analytics dashboard.

## Read the group, not just the TLS version

Cloudflare identifies `X25519MLKEM768` as a hybrid ML-KEM key exchange group used for post-quantum encryption in TLS 1.3. Seeing TLS 1.3 alone is insufficient: the announcement also describes classical X25519 and P-256 key exchange with TLS 1.3 or earlier versions. The dashboard’s `None` bucket is not synonymous with plaintext, either. Cloudflare says it covers RSA key agreement or no TLS at all. [Source: Cloudflare](https://blog.cloudflare.com/post-quantum-visibility/).

If a domain shows no use of `X25519MLKEM768`, Cloudflare recommends first checking that TLS 1.3 is enabled. The company says there is no separate post-quantum setting for the visitor connection: it negotiates the hybrid group automatically when TLS 1.3 is enabled and the visitor supports it. Non-browser clients lacking TLS 1.3 or hybrid-group support are another possible explanation for mostly classical traffic. [Source: Cloudflare](https://blog.cloudflare.com/post-quantum-visibility/).

## Keep the measurements separate

For engineering teams, the practical implication is to assess visitor and origin connections independently. A high hybrid share on visitor-to-Cloudflare traffic does not establish that Cloudflare-to-origin connections also use hybrid key agreement.

When calculating percentages from HTTP request logs, treat them as traffic-weighted measurements—not counts of unique clients. Repeated requests from the same client can influence the result. Decide whether an adoption report is measuring the share of requests using hybrid key agreement or the number of distinct clients using it; those answer different questions.

Finally, key agreement is not certificate authentication. Cloudflare describes visibility into certificate and signature algorithms as future work. The newly announced key exchange telemetry should therefore not be read as proof of post-quantum certificate authentication. [Source: Cloudflare](https://blog.cloudflare.com/post-quantum-visibility/).

## Source references

- <https://blog.cloudflare.com/post-quantum-visibility/>