Cloudflare’s Post-Quantum Visibility Turns Quantum Readiness Into a Per-Hop Audit

Cloudflare has added the TLS key exchange group to its HTTP Traffic Analytics dashboard, Log Explorer and Logpush, so a domain owner can now see, request by request, whether visitors are connecting with post-quantum encryption. The September 29, 2026 announcement, written by Andrew Depke, Sophie Park and Sharon Goldberg, opens with two aggregate figures from Cloudflare Radar: about 70 percent of browser-generated traffic reaching Cloudflare is protected with hybrid ML-KEM, while, as Cloudflare puts it, just about 15 percent of the origins it connects to use hybrid ML-KEM.

The gap between those two numbers is the real story. A proxied request can involve two separate TLS connections, one from the visitor to Cloudflare and one from Cloudflare to the origin, and each can end up with a different answer. The new fields treat post-quantum readiness as a property of each hop instead of a label on a domain. This piece walks through what shipped, why the two headline numbers measure different things, and what a domain owner can and cannot conclude from the data. To test the mechanics rather than repeat them, I also ran live handshakes against eight public sites with a current OpenSSL client, and those results appear below.

What Cloudflare Shipped

A Dashboard Card and Two Log Fields

In the Cloudflare dashboard, HTTP Traffic under the Analytics tab now includes a TLS Key Exchange card for the visitor-to-Cloudflare connection, and the key exchange group can be used as a filter. The example card Cloudflare shows for one of its test domains sorts traffic into four kinds: post-quantum X25519MLKEM768; classical ECDHE over X25519 or P-256; a bucket labeled “None,” which Cloudflare defines as RSA key agreement in TLS 1.2 or below, or no TLS at all; and a small remainder still using X25519Kyber768Draft00, a pre-standard predecessor of the hybrid. Cloudflare is keeping support for that draft until observed connections are “diminishingly small,” so it does not regress clients that have no other way to negotiate post-quantum encryption.

For per-request detail there are two new fields in the HTTP requests dataset. ClientTLSKeyExchangeGroup records the group negotiated between the client and Cloudflare, and OriginTLSKeyExchangeGroup records the group negotiated between Cloudflare and the origin. In the dataset reference, NONE means RSA key exchange was used or TLS was not used, and UNK means the group could not be determined. The origin field is also UNK when Cloudflare did not connect to the origin at all, for example on a cache hit. Cloudflare’s example Logpush line shows the client field on a request that used the hybrid:

{
  "EdgeResponseStatus": 200,
  "EdgeStartTimestamp": "2026-09-20T00:08:24Z",
  "RayID": "...",
  "ClientTLSKeyExchangeGroup": "X25519MLKEM768"
}

There Is No Post-Quantum Switch

On the visitor side, the only setting that matters is TLS 1.3. In Cloudflare’s words, “There is no separate post-quantum setting: when TLS 1.3 is enabled and a visitor supports X25519MLKEM768, Cloudflare negotiates it automatically.” Cloudflare also states that “post-quantum encryption is not available in TLS 1.2 or any earlier version of TLS,” so a domain that shows no X25519MLKEM768 at all should first confirm that the TLS 1.3 switch under SSL/TLS, then Edge Certificates, is on.

The group works by running two key exchanges at once. Client and server execute both an ECDHE exchange over X25519 and the post-quantum ML-KEM exchange, and TLS combines the two secrets into one shared secret that protects the traffic. Cloudflare summarizes the design this way: “as long as one of the two key exchanges is secure, the resulting shared secret is also secure.” The combination is specified in RFC 10024, an Internet Standards Track document that defines X25519MLKEM768 alongside two other hybrids. For a code-level look at that combiner, see our tutorial on building a hybrid post-quantum key exchange in Python with X25519 and ML-KEM.

Why Key Exchange Is the Part Being Measured

Key exchange comes first because of harvest-now-decrypt-later attacks, in which an adversary records encrypted traffic today and decrypts it once powerful quantum computers exist. Cloudflare says organizations whose data would still be valuable if decrypted years from now should consider protecting their traffic with post-quantum encryption immediately, and it names the public sector, defense, finance, telecom and healthcare as examples. Until this release, Cloudflare notes, customers could not answer a question like “What fraction of traffic to my domain www.example.com is using post-quantum encryption?”

Why 70 Percent and 15 Percent Are Different Kinds of Numbers

Cloudflare is upfront that the two figures are not measured the same way: “These are aggregate numbers; the first number is aggregated across all the browser-generated traffic we see, and the second number is aggregated across all the origins we connect to.” One is a share of traffic and the other is a share of servers. They also move for different reasons. My reading, not Cloudflare’s, is that a handful of browser vendors can change what a very large client population offers in a single release, while each origin is a separate decision by whoever runs that stack.

The Origin Figure Comes From a Scanner and Counts Support

The origin half of Radar is built differently from the traffic half. When Cloudflare added an origin graph to Radar in a February 27 post, it explained that the data “is derived from our automated TLS scanner, which probes TLS 1.3-compatible origins and aggregates the results daily,” and it added a caution: “our scanner tests for support rather than the origin server’s specific preference.” An origin may support the hybrid while its local preference decides otherwise, and that preference “can ultimately dictate the encryption outcome.” The visibility post says just about 15 percent of origins “use hybrid ML-KEM,” but if that figure is the scanner-based Radar series, which Cloudflare’s wording does not say outright, it is a capability count for the fleet and not a count of connections that negotiated the hybrid.

Cloudflare put the scanner’s origin figure at approximately 10 percent in February, up from less than 1 percent at the start of 2025, and said the rise “likely accelerated in 2025 as many server-side TLS libraries, such as OpenSSL 3.5.0+, GnuTLS 3.8.9+, and Go 1.24+, enabled hybrid post-quantum key exchange by default.” Cloudflare’s explanation points at software defaults more than at operators making choices, which is also why the upgrade path for a classical origin discussed below is mostly a version question.

Cloudflare’s Own Offer Moves the Live Number

Support is only half of the origin story, because a connection negotiates the hybrid only if Cloudflare offers it and the origin accepts. Cloudflare’s September 8 post on Automatic Key Exchange explains how its old behavior left post-quantum on the table. For years, Cloudflare’s opening guess on every origin connection was classical X25519, which it now calls “suboptimal for roughly 30% of the origin connections we’ve since measured.” Automatic Key Exchange “replaces the guess with a measurement”: Cloudflare probes each origin to learn which key agreement algorithms it supports and prefers, then leads with that algorithm, choosing the post-quantum hybrid wherever the origin can speak it. Cloudflare reports that HelloRetryRequests fell “from roughly 52% to 3.7%” and that “hundreds of thousands of domains now have post-quantum origin connections that nobody had to configure.”

That raises the live negotiated share without changing what origins support: origins that already supported the hybrid can start negotiating it with no change on their side. It is good news for harvest-now-decrypt-later exposure, but it also means the origin field in your logs can change without anything changing on your side. Log it and watch it rather than treating one reading as a property of your stack.

How to Count the Origin Leg Correctly

Cloudflare says the origin group is the same for all visitor connections to a domain, which is why it does not appear on the traffic dashboard. The dataset reference adds a caveat that matters for any percentage: the field reads UNK when Cloudflare never opened an origin connection, as with a cache hit. Count only rows where an origin connection actually happened, or cached responses will dilute the share and make the origin leg look worse than it is.

The Client Field Measures Your Visitors’ Software, Not Your Configuration

Cloudflare’s own advice for a domain with low post-quantum numbers points at the visitors. If most traffic is classical X25519, P-256, P-384 or “None,” it says, “it might be because most visitors to that domain are non-browser clients that lack support for X25519MLKEM768 and/or TLS 1.3.” The negotiated group is decided in each handshake by two parties, the client’s offer and the server’s preference, so the same server gives different answers to different clients.

A Spot Check With OpenSSL 3.5

How the test was run

At about 19:29 UTC on September 29, 2026, I ran four handshakes against each of eight public HTTPS sites from a Windows 11 machine using the OpenSSL 3.5.7 command-line client: the OpenSSL 3.5 defaults, classical X25519 only, X25519MLKEM768 only, and TLS 1.2 only. The defaults matter because OpenSSL 3.5 changed them. Its release notes say “The default TLS supported groups list has been changed to include and prefer hybrid PQC KEM groups,” and its default key shares now offer X25519MLKEM768 and X25519. The sites are a convenience sample, not a survey, and each handshake ran once from one location.

What came back

Negotiated key exchange group per handshake, OpenSSL 3.5.7, September 29, 2026, about 19:29 UTC. “Hybrid” means X25519MLKEM768. In the TLS 1.2 column, the value is the curve used for ECDHE.

Reading the table

Six of the eight sites negotiated X25519MLKEM768 with the default client: sxz.io, which is served through Cloudflare, plus cloudflare.com, google.com, www.wikipedia.org, www.python.org and example.com. The other two, github.com and kernel.org, negotiated classical X25519 even though the client offered the hybrid, and both answered a hybrid-only client with a TLS handshake failure alert. A client that insisted on the hybrid would simply fail against servers like those, which is the practical reason deployments offer the hybrid alongside classical groups instead of in place of them. It is also why any domain’s logs will always contain classical rows: the hybrid is an offer, and both sides have to accept it.

Two other results line up with Cloudflare’s claims. Forcing TLS 1.2 produced classical X25519 at all eight sites, matching the statement that post-quantum encryption is not available before TLS 1.3. And for sxz.io, the same server returned either the hybrid or plain X25519 depending only on what the client offered, which is exactly the variation that ends up in ClientTLSKeyExchangeGroup.

Your own scripts are part of the population

The Python 3.13 interpreter on the same machine is linked against OpenSSL 3.0.21, which predates the ML-KEM support that arrived in OpenSSL 3.5, and asking it for the hybrid group fails outright (the traceback is trimmed here to its last line):

$ python -c "import ssl; print(ssl.OPENSSL_VERSION)"
OpenSSL 3.0.21 9 Jun 2026
$ python -c "import ssl; ssl.create_default_context().set_ecdh_curve('X25519MLKEM768')"
ValueError: unknown elliptic curve name 'X25519MLKEM768'

A client like that can only offer classical groups, so it shows up as X25519 or P-256 in ClientTLSKeyExchangeGroup no matter what you configure at the edge. Scripts, monitoring agents and API partners are a plausible long tail. Cloudflare’s data cannot make them upgrade; it can only show you they exist.

To repeat the handshake test on your own domain, use OpenSSL 3.5 or newer in a POSIX shell such as Git Bash and set H to your host name. On sxz.io the four commands returned the four lines shown after them, in order:

H=sxz.io
openssl s_client -connect $H:443 -servername $H </dev/null 2>&1 | grep -E "Negotiated TLS1.3 group|Peer Temp Key"
openssl s_client -connect $H:443 -servername $H -groups X25519 </dev/null 2>&1 | grep -E "Negotiated TLS1.3 group|Peer Temp Key"
openssl s_client -connect $H:443 -servername $H -groups X25519MLKEM768 </dev/null 2>&1 | grep -E "Negotiated TLS1.3 group|Peer Temp Key"
openssl s_client -connect $H:443 -servername $H -tls1_2 </dev/null 2>&1 | grep -E "Negotiated TLS1.3 group|Peer Temp Key"

Negotiated TLS1.3 group: X25519MLKEM768
Peer Temp Key: X25519, 253 bits
Negotiated TLS1.3 group: X25519MLKEM768
Peer Temp Key: X25519, 253 bits

Separate the Browsers From Everything Else

The same dataset also carries ClientSSLProtocol, ClientRequestUserAgent and VerifiedBotCategory, which lets you split the classical rows by cause. TLS 1.2 traffic cannot be post-quantum by definition. Verified bots follow their own operators’ upgrade schedules. What remains among ordinary browsers is the only slice that says anything about browser rollout.

The Origin Leg and the Legacy Problem

On the origin side, Cloudflare’s documentation says it applies one key agreement preference across the zone: “When the selected preference is X25519MLKEM768, Cloudflare sends that key share in the initial ClientHello to allow for faster connection establishment.” An origin that cannot speak the hybrid falls back to a classical group, and OriginTLSKeyExchangeGroup records what actually happened.

Two fixes exist for a classical origin. The first is to upgrade the TLS stack, which is now largely a version question. Cloudflare’s PQC support page lists OpenSSL as defaulting to the hybrid from 3.5.0, NGINX as defaulting to it when compiled with OpenSSL 3.5 or newer, and Caddy as defaulting to it from 2.10.0. The second is Cloudflare Tunnel, which Cloudflare says can carry traffic between a legacy origin and its network over TLS 1.3 with the hybrid, “without need to upgrade the legacy origin server itself.” A tunnel changes which link is exposed rather than modernizing the service behind it, so it is a pragmatic answer for ossified systems and not a substitute for replacing them.

Key Agreement Is Only Half the Migration

Everything above measures confidentiality: whether a recorded session could be decrypted by a future quantum computer. Cloudflare says plainly that “for now it remains true that post-quantum encryption with hybrid MLKEM is more broadly deployed than post-quantum authentication.” An independent March 2026 survey of nine protocols by Tushin Mallick, Ashish Kundu and Ramana Kompella reaches the same conclusion, finding that key exchange “proves consistently easier to migrate than authentication” across all of them.

The risk profile differs for authentication. Cloudflare’s April 7 roadmap post, which set 2029 as the target for full post-quantum security, insists on including signatures because adversaries with working quantum computers could “impersonate servers or forge access credentials.” It adds a blunt comparison: “An imminent Q-Day flips the script: data leaks are severe, but broken authentication is catastrophic.” Cloudflare has started on that front. A July 29 post added ML-DSA support to Authenticated Origin Pulls and the Custom Origin Trust Store, and the visibility post says Cloudflare is launching a certificate authority that will support post-quantum Merkle Tree Certificates. The new fields do not cover any of that yet. Cloudflare says it will surface authentication algorithms “once we start to see a broader-based deployment of that technology.”

The Government Deadlines Split the Same Way

Executive Order 14412, signed June 22, 2026 and published in the Federal Register on June 25, draws the same line. It directs OMB to issue guidance requiring agencies to “transition all HVAs and high impact systems to use PQC for key establishment by December 31, 2030,” and to do so “for digital signatures by December 31, 2031.” The order defines an HVA as federal information or a federal information system designated as a high value asset under OMB Memorandum M-19-03 or its successor. It also tells the FAR Council to propose a rule requiring covered contractors to comply by December 31, 2030 with NIST’s FIPS, “including all applicable FIPS incorporating PQC compliant algorithms.”

NIST’s November 2024 draft transition report, IR 8547, sits further out. Its tables list 112-bit-strength RSA, elliptic-curve and finite-field Diffie-Hellman schemes as deprecated after 2030 and mark the quantum-vulnerable algorithms as disallowed after 2035. A high share of X25519MLKEM768 on the TLS Key Exchange card is evidence about the first of the executive order’s two clocks. It says nothing about the second, and because the order binds federal agencies and, through the FAR rule it calls for, their contractors, a vendor dashboard is at most one piece of evidence in that story. Red Hat made the deadline argument from the operating-system side for financial services in July, which we covered in Red Hat’s RHEL 10 Turns Post-Quantum Migration Into a Financial Services Deadline.

A Five-Step Audit for a Domain Owner

1. Confirm TLS 1.3 is on. It is the only prerequisite Cloudflare names, and it is a dashboard switch under SSL/TLS, then Edge Certificates.
2. Read the card. Open HTTP Traffic under Analytics, note the share using X25519MLKEM768, then filter to the traffic that is not.
3. Enable both log fields. Add ClientTLSKeyExchangeGroup and OriginTLSKeyExchangeGroup to your Logpush job or query them in Log Explorer, and group the client values by ClientSSLProtocol and user agent.
4. Fix the origin leg deliberately. Count only rows with a real origin connection. If they are classical, decide between relying on Automatic Key Exchange, upgrading the origin’s TLS stack and fronting it with Cloudflare Tunnel.
5. Track authentication separately. Nothing in these fields describes certificates or signatures, so keep a separate inventory of the certificate and signature algorithms you depend on.

What This Data Cannot Tell You

Four limits are worth keeping in view. The fields cover only traffic proxied by Cloudflare. The headline figures come from Cloudflare’s own telemetry, with the origin figure apparently coming from a scanner that tests support rather than preference, and I could not reproduce either independently. The fixes Cloudflare recommends, such as Tunnel, route traffic through its own network. My handshake test covered eight sites from one location, one handshake each, so it demonstrates mechanics rather than measuring adoption, and edge behavior can vary by location and over time. Finally, the fields live in the HTTP requests dataset, so each row is a request: a percentage from these logs is weighted by requests, not connections, and one long-lived connection can carry many requests.

What to Watch Next

The number worth watching is not the 70 percent. It is the day authentication algorithms appear in the same dashboards, because Cloudflare’s 2029 target and the executive order’s 2031 signature deadline both put the weight there. Until then, the per-hop fields are a cheap way to find the requests, clients and origins that are still classical, and to notice when Cloudflare’s own automation changes the answer underneath you. For the library-side risks of moving Python services onto these algorithms, see our post-quantum adoption checklist.