Cloudflare's Logs Just Got a New Field That Shows Your Zone's Post-Quantum TLS Adoption Rate!

Hi, I'm Shii-chan!

Cloudflare Changelog developers.cloudflare.com

Today I found a logging update from Cloudflare that I wanted to share with you. It might sound like a small detail, but if you like tracking security posture with real numbers, this one's pretty exciting.

What was announced?

According to the Cloudflare Changelog, on August 20, 2026, a new field called ClientTLSKeyExchangeGroup was added to the http_requests Logpush dataset. You can also query this field directly in Log Explorer.

This field tells you the name of the TLS key exchange group negotiated on the connection between the client and Cloudflare. Here's what values you might see.

• X25519MLKEM768: a post-quantum key agreement connection
• X25519, P-256, or another named group: a classical key exchange connection
• UNK: the group could not be determined
• NONE: TLS was not used at all

This is more of a "new data you can use" announcement than a policy change, so it's the kind of update you can actually go try out yourself.

The story so far

Cloudflare Radar already published global statistics on post-quantum key agreement adoption across all Cloudflare traffic. But until this update, there was no way to scope that same measurement down to just your own zones. If you wanted to know how much of your site's HTTPS traffic was protected by post-quantum key agreement, there simply wasn't a way to check.

What changes

With the ClientTLSKeyExchangeGroup field available, you can now build per-zone reports showing what percentage of your inbound HTTPS traffic is protected by post-quantum key agreement. You can also break that number down by hostname, path, user agent, or country.

On top of that, you can push this data into your SIEM through any Logpush destination. That makes it much easier to fold post-quantum adoption progress into your security monitoring dashboards or regular internal reports.

Dive Deep

There are basically two ways to use this.

• Query ClientTLSKeyExchangeGroup directly in Log Explorer for a quick, ad-hoc look at your breakdown
• Set up a Logpush job on the http_requests dataset to continuously stream the data to your SIEM or external storage

Either way, you're pulling the same information from the same field. You could start by eyeballing trends in Log Explorer, then switch to a full Logpush job with a destination once you need continuous data.

One thing worth noting: UNK and NONE mean different things. UNK means a key exchange happened but the group couldn't be identified, while NONE means TLS wasn't used on that connection at all. Mixing these two up would skew how you interpret your reports, so it's worth keeping them separate when you aggregate the data.

Wrap-up

• The ClientTLSKeyExchangeGroup field was added to the http_requests Logpush dataset and Log Explorer
• Post-quantum connections show up as X25519MLKEM768, while classical connections show up as X25519, P-256, or other named groups
• UNK (undetermined) and NONE (no TLS) are recorded as distinct values
• You can aggregate post-quantum adoption per zone, break it down by hostname, path, user agent, or country, and stream it to your SIEM

This is an update you can try right away if you're a security lead who wants to track your zone's post-quantum migration with real numbers, or an ops person already using Logpush and Log Explorer.