Cloudflare now logs the TLS key-exchange group negotiated on every proxied request, exposed as the ClientTLSKeyExchangeGroup field in Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard. That makes post-quantum adoption a per-domain, per-request metric you can baseline today. The catch: the number measures hybrid encryption only, not post-quantum authentication, and a low share usually points at your non-browser clients rather than your server configuration.
What shipped: one field, three surfaces
On 2026-09-29, Cloudflare’s announcement introduced post-quantum visibility tooling across its Application Security and Logs products. The core addition is a single log field: ClientTLSKeyExchangeGroup, found under the TLS category in the HTTP Requests dataset. Enabling it records, for each request, which key-exchange group the client and server negotiated. The same data feeds three consumption surfaces:
- Logpush, for operators who stream request logs into their own warehouse or SIEM and want to compute shares themselves.
- Log Explorer, for ad-hoc queries against connection logs without standing up a pipeline.
- HTTP Traffic Analytics, for graphing adoption over time directly in the dashboard.
Per Cloudflare’s announcement, the value you are watching for is X25519MLKEM768, the hybrid post-quantum group. Classical values are X25519, P-256, P-384, and None, and a small number of visitors may still negotiate the now-deprecated X25519Kyber768Draft00, the pre-standardization hybrid Cloudflare implemented before the IETF finalized X25519MLKEM768. Decide up front whether that value counts toward your PQ share, because it is post-quantum key exchange even though it is not the recommended group. The measurement surface is documented in Cloudflare’s 2026-09-29 announcement and scoped to Cloudflare-proxied traffic; the supporting adoption figures below come from 2026 preprints that have not, to our knowledge, been independently replicated.
What X25519MLKEM768 actually is, and why TLS 1.3 is the floor
X25519MLKEM768 is a hybrid construction. Per Cloudflare’s post, it runs classical ECDHE over the X25519 curve and the ML-KEM key encapsulation mechanism in parallel; TLS then combines the two shared secrets and encrypts traffic with the result. The security property is conservative: an attacker has to break both halves to recover the session key, so the classical half protects against a flaw in ML-KEM and the ML-KEM half protects against a future quantum machine breaking elliptic-curve Diffie-Hellman. Cloudflare states it is the only recommended post-quantum key-exchange algorithm in TLS 1.3 and that it is now preferred by most major browsers.
The protocol floor matters for how you read your logs. Post-quantum encryption is not available in TLS 1.2 or earlier, and this is a structural fact, not a configuration choice. A 2026 measurement study of internet PQ readiness (arXiv:2606.16473) explains the mechanism: TLS 1.2 couples classical key agreement tightly inside its cipher suites, leaving no extension point for the KEM paradigm that ML-KEM uses, which also brings significantly larger key material. TLS 1.3’s redesigned handshake is what made a pluggable hybrid group possible. The practical consequence is that every client stuck on TLS 1.2 is a client that cannot negotiate X25519MLKEM768 no matter what you do on the server side, so your PQ share is bounded from above by your TLS 1.3 share.
The baseline checklist
Building the baseline is mechanical, and most of the work is deciding what denominator to use before you look at the number.
- Enable the field. Turn on
ClientTLSKeyExchangeGroupunder the TLS category in the HTTP Requests dataset. If you use Logpush, confirm the field is included in your job configuration; the field starts appearing in your logs from the moment it is enabled, so plan for baselines to start at enablement rather than assuming backfill. - Pick your denominator deliberately. The share “X25519MLKEM768 / all requests” and the share “X25519MLKEM768 / TLS 1.3 requests” answer different questions. The first measures your traffic’s actual quantum-resistant-encryption coverage. The second isolates client capability among clients that could negotiate PQ. Report both, or stakeholders will conflate them.
- Segment by client type before drawing conclusions. The key exchange group can now also be a filtering term in the HTTP Traffic dashboard, so isolating the traffic that is not negotiating
X25519MLKEM768takes one click; attributing that traffic is the part the dashboard will not do for you. Split the classical share by user agent or, better, by your own inventory of API clients, mobile SDKs, IoT devices, and partner integrations. This is the same discipline that applies whenever edge telemetry gets read as a behavioral verdict, the pattern behind Cloudflare’s bot-traffic measurement dispute: a share on a vendor dashboard is a measurement, not an attribution. - Baseline per domain, not per account. A marketing site with pure browser traffic and an API endpoint with embedded-device traffic will produce wildly different shares from the same correct server configuration. Aggregating them produces a number that describes neither.
- Snapshot now, trend later. The value of the field compounds: a one-time reading tells you where you are, a time series tells you whether client upgrades (browser rollouts, SDK updates, firmware refreshes) are actually moving the tail.
A mostly-classical share is a client story, probably
If your dashboard shows the vast majority of traffic on classical X25519, P-256, P-384, or None, Cloudflare’s own interpretation is that “it might be because most visitors to that domain are non-browser clients that lack support for X25519MLKEM768 and/or TLS 1.3.” Note the hedge: “might be.” That is an inference from network-wide patterns, not a measured diagnosis of your domain, and the honest way to use it is as the hypothesis to test first, not as an answer.
The reasoning behind the hypothesis is sound. Browsers already prefer the hybrid group, so browser traffic should convert on its own. What remains classical is the long tail of programmatic clients: API consumers pinned to old TLS libraries, mobile apps on stale SDKs, hardware that ships a TLS 1.2 stack, cron jobs using a decade-old libcurl. That tail is also where the organizational burden now sits. Browsers upgrade themselves; the owners of a partner integration or an embedded fleet do not, and the new per-request visibility converts their lag into your dashboard number. PQ migration stops being a procurement line item and becomes an observable property of traffic, which means someone gets asked why the number is low. If you run a domain whose traffic is dominated by non-browser callers, the inventory habit described in our bot-defense build-vs-buy analysis applies here too: enumerate which clients, which integrations, which libraries before you treat any vendor surface as ground truth.
Before accepting the non-browser story for a specific domain, rule out the cheap failure modes on your side: confirm TLS 1.3 is actually enabled for the hostname, confirm you are looking at proxied traffic (the field cannot see connections that terminate at your origin directly), and check whether a small number of high-volume classical clients are dominating the share. Only then does the classical remainder become a client-capability finding you can hand to the owners of those clients.
Encryption is not authentication
This is the caveat that should change how a dashboard share gets presented upward. ClientTLSKeyExchangeGroup measures the key-exchange half of the migration only. A TLS connection authenticated with a classical certificate but keyed with X25519MLKEM768 is protected against harvest-now-decrypt-later attacks on the session content, but the server’s identity still rests on signatures a quantum adversary could eventually forge.
The independent measurement record says that second half has not started. arXiv:2606.16473 observed 0% adoption of hybrid post-quantum certificates in its 2026 scan of 32,011 domains, “leaving the authentication layer vulnerable to quantum-enabled attacks such as certificate forgery.” As a single preprint measurement it deserves caution, but the direction is consistent with the economics. Post-quantum authentication is expensive in bytes: per arXiv:2604.04191, ML-DSA-65 produces 3,309-byte signatures and 1,952-byte public keys, over 50 times larger than Ed25519, and those bytes multiply across every certificate in a chain on every full handshake. Size pressure of that order is what motivates alternative certificate constructions such as Merkle Tree Certificates, and Cloudflare announced the same day that it is launching a certificate authority that will support post-quantum Merkle Tree Certificates. Cloudflare’s framing, and the framing this checklist adopts, is that PQ migration has two halves with different clocks: hybrid encryption, which browsers are already negotiating broadly, and PQ authentication, which is still waiting on certificate infrastructure. A dashboard that shows the first half and not the second is useful precisely because it does not pretend to show both.
| What you want to know | Where the answer lives | What the new field tells you |
|---|---|---|
| Is session encryption PQ-protected per request? | ClientTLSKeyExchangeGroup = X25519MLKEM768 | Yes, directly |
| Can a client negotiate PQ at all? | TLS version + key-exchange group together | Indirectly: TLS 1.3 is required, and TLS 1.2 clients structurally cannot |
| Is server identity PQ-authenticated? | Certificate chain signatures (ML-DSA, Merkle Tree Certificates) | No; this half sat at 0% observed adoption in 2026 measurement (arXiv:2606.16473) |
| Why is my share classical-heavy? | Your own logs segmented by client type | Not directly; the vendor’s non-browser explanation is a hypothesis, not a diagnosis |
| What does hybrid cost per handshake? | Handshake byte counts | Nothing; measured separately at a median of 1,176 bytes client-to-server and 1,088 bytes server-to-client |
The overhead check
The hybrid group is not free. Relative to a classical baseline, X25519MLKEM768 adds a median of 1,176 bytes client-to-server and 1,088 bytes server-to-client per handshake, per a 2026 deployment study (arXiv:2607.29005). For browser traffic on broadband, that is noise. For the non-browser long tail, it can be the actual reason a client stays classical: a metered cellular IoT device, a satellite uplink, or a firmware image sized to the kilobyte may rationally defer the extra handshake bytes. When you segment your classical tail and find constrained clients, the overhead figure gives you a concrete quantity to discuss with their owners rather than a vague appeal to upgrade. It also cuts the other direction: if a client library claims PQ support but your field shows classical negotiation, the handshake-size sensitivity of the path (middleboxes, MTU issues with the larger ClientHello) is a plausible suspect, though middlebox behavior is something to test in your own environment rather than assume.
Before you call it a readiness score
The measurement checklist, condensed: enable ClientTLSKeyExchangeGroup in the HTTP Requests dataset, baseline per domain with both the all-requests and TLS-1.3-only denominators, segment the classical share by client type before attributing it, track the trend rather than the snapshot, and report the number as hybrid-encryption coverage, never as post-quantum readiness, because the certificate half sat at 0% observed adoption in a 2026 scan of 32,011 domains (arXiv:2606.16473).
The limitations are as much a part of the deliverable as the number. Every mechanic described here is vendor-documented and applies only to Cloudflare-proxied traffic; what your origin sees on direct connections, and what non-Cloudflare front ends negotiate, is outside the field’s reach. The supporting studies are preprints without confirmed replication. The vendor’s explanation for classical-heavy traffic is explicitly hedged, and none of it tells you when the authentication half of your own stack will move. Treat the share as the best available instrument for the encryption half of the migration, verify the attribution in your own logs, and keep the certificate question on a separate line of the same report.
Frequently Asked Questions
What is the overhead of X25519MLKEM768 per handshake?
Relative to a classical baseline, X25519MLKEM768 adds a median of 1,176 bytes client-to-server and 1,088 bytes server-to-client per handshake, per a 2026 deployment study (arXiv:2607.29005).
Does the new field measure post-quantum authentication?
ClientTLSKeyExchangeGroup measures the key-exchange half of the migration only. A TLS connection authenticated with a classical certificate but keyed with X25519MLKEM768 is protected against harvest-now-decrypt-later attacks on the session content, but the server’s identity still rests on signatures a quantum adversary could eventually forge.
Join the discussion
Share a useful perspective or ask a question about this article.