This is part 1 of a two-part article. Part 2 covers origin-side visibility and the wider post-quantum roadmap.
Cloudflare has added post-quantum (PQ) cryptography visibility to several of its Application Security and Logs products. Customers can now inspect and graph post-quantum TLS 1.3 adoption for live traffic from Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard. The key exchange algorithm negotiated on each incoming request is surfaced as per-connection telemetry, so operators can audit their post-quantum posture, assess compliance, and find cryptographic gaps across their domains.
Why per-domain telemetry now
Cloudflare's stated target is full post-quantum security by 2029. Reaching it at scale requires detailed telemetry, and the company has already deployed post-quantum encryption across products including its cloud-proxy platform and every on-ramp and off-ramp of its SASE platform. Many customers face quantum-readiness deadlines around 2030, and Cloudflare says post-quantum encryption is already the default in many of its products.
Until now, algorithm-level visibility stopped at the aggregate. Cloudflare Radar reports Internet-wide post-quantum adoption for both the visitor-to-Cloudflare connection and the Cloudflare-to-origin connection.
On Radar, roughly 70% of browser-generated traffic reaching Cloudflare's network uses hybrid ML-KEM (FIPS 203) on the visitor-to-Cloudflare connection. About 15% of origins Cloudflare connects to use hybrid ML-KEM. Both figures are aggregates — the first across all browser-generated traffic Cloudflare sees, the second across all origins it connects to.
Automatic Key Exchange, launched recently for the Cloudflare-to-origin connection, shows which cryptographic algorithms a given origin supports. Outdated configurations can leave an origin on classical cryptography even when it supports post-quantum encryption.
TLS version has long been visible per domain (TLS 1.3, TLS 1.2, and so on), but the algorithms used alongside that version were not. Questions such as "What fraction of traffic to www.example.com uses post-quantum encryption?" had no answer. They do now — relevant for regulatory compliance, for troubleshooting a migration, and for sizing the share of traffic exposed to future quantum adversaries.
The algorithm behind the numbers
In 2024, NIST stated that RSA and Elliptic Curve Cryptography should be deprecated by 2030, and many governments and regulators have since backed that deadline. Post-quantum encryption is needed today to counter harvest-now-decrypt-later attacks, in which an adversary records traffic now and decrypts it once quantum computers are capable. Organizations holding data still valuable if decrypted in 3–10 years — public sector, defense, finance, telecom, healthcare, among others — should consider protecting traffic with post-quantum encryption immediately.
Within TLS 1.3, the key exchange group X25519MLKEM768 is the only recommended algorithm for post-quantum encryption and is now the one most major browsers prefer. Post-quantum encryption is not available in TLS 1.2 or any earlier version. In Chrome, the negotiated group for any page can be inspected via right-click "Inspect", then the "Security" tab, where the connection's key exchange is listed.
With X25519MLKEM768 under TLS 1.3, client and server perform both of the following:
- the Elliptic Curve Diffie-Hellman Key Exchange (ECDHE) over curve X25519 and
- the post-quantum Module Lattice Key Encapsulation Mechanism (ML-KEM)
Each produces a shared secret; TLS combines the two and encrypts traffic with the result. The hybrid construction is deliberately redundant — the combined secret stays secure as long as either exchange is secure. TLS 1.3 also supports X25519, P-256 and P-384, all classical ECDHE over different curves, and these remain widespread. Earlier TLS versions may still use RSA key agreement, which is quantum-vulnerable and now much less common given its known classical security problems.
Encryption is only half the transition; the other half is authentication. Once powerful quantum computers exist, certificates and signatures in TLS 1.3 must move off RSA and ECC toward post-quantum algorithms such as ML-DSA. Cloudflare recently enabled origins to use ML-DSA-44 certificates over TLS 1.3 when connecting to Cloudflare, and has announced a certificate authority that will support post-quantum Merkle Tree Certificates. For the moment, post-quantum encryption with hybrid ML-KEM is more broadly deployed than post-quantum authentication.
Reading the visitor-to-Cloudflare data
The new telemetry covers the visitor-to-Cloudflare connection through three entry points: the HTTP Traffic Analytics dashboard, Logpush, and Log Explorer.
The dashboard card and filtering
In the Cloudflare Dashboard, open HTTP Traffic under the Analytics tab to see statistics about traffic to your domains. It now includes a dedicated card for TLS Key Exchange groups on the visitor-to-Cloudflare connection, further down the page.
A typical test domain shows most traffic on post-quantum X25519MLKEM768 in TLS 1.3, some on classical ECDHE over X25519 or P-256 in TLS 1.3 or below, and a "None" bucket covering RSA key agreement (TLS 1.2 or below) or no TLS at all. A small share of visitors still uses the deprecated X25519Kyber768Draft00 with TLS 1.3 — implemented before X25519MLKEM768 was fully standardized by the IETF, and retained until observed connections become vanishingly small so as not to regress clients whose only PQ option it is.
Two practical checks follow from the card. If a domain shows no X25519MLKEM768 at all, confirm TLS 1.3 is enabled under SSL/TLS > Edge Certificates in the dashboard and switch it On. There is no separate post-quantum setting: with TLS 1.3 on and a visitor that supports X25519MLKEM768, Cloudflare negotiates it automatically. And if nearly all traffic sits on classical X25519, P-256, P-384, or None, the audience for that domain is likely dominated by non-browser clients lacking X25519MLKEM768 and/or TLS 1.3 support.
The key exchange group also works as a filter term in the HTTP Traffic dashboard. Filtering on it isolates the traffic not using post-quantum encryption with X25519MLKEM768.
Per-connection detail in logs
Aggregate views are useful for broad investigations; individual log lines reach further. Enabling the ClientTLSKeyExchangeGroup field — found under the TLS category of the HTTP Requests dataset — brings post-quantum key exchange visibility into Log Explorer and Logpush connection logs.
Once the field is enabled, it appears in your Logpush HTTP Request logs, as shown below.
{
"EdgeResponseStatus":200,
"EdgeStartTimestamp":"2026-09-20T00:08:24Z",
"RayID":"...",
"ClientTLSKeyExchangeGroup":"X25519MLKEM768"
}Origin-side visibility
The key exchange group stats mark the first major milestone in a wider cryptographic visibility effort. The telemetry pipeline behind them is designed for scalability and can ingest additional cryptographic parameters from TLS handshakes.
That capacity is already in use: the key exchange group from the Cloudflare-to-origin connection is now exposed in Logpush as OriginTLSKeyExchangeGroup, giving end-to-end visibility from eyeball to origin. Because that group is identical for every visitor connection to a given domain, it is not shown in the HTTP Traffic Analytics dashboard.
Legacy origins and Cloudflare Tunnel
Origins that are unlikely to support modern post-quantum cryptography are not left out. Placing the origin server behind a Cloudflare Tunnel carries traffic from origin to Cloudflare over TLS 1.3 with X25519MLKEM768, with no upgrade required on the legacy origin itself.
Post-quantum authentication — the algorithm used for certificates and signatures in TLS, including Merkle Tree Certificates — will be surfaced once deployment of that technology broadens.
Checking your own deployment
Domains behind Cloudflare are already on this path. The HTTP Traffic Analytics dashboard and your logs show the share of visitor connections using TLS 1.3 with post-quantum encryption (X25519MLKEM768), and logs also reveal whether the Cloudflare-to-origin connection uses post-quantum encryption. Where the origin is too ossified to support it, Cloudflare Tunnel closes the gap. With the right settings and visibility, more traffic can be protected from harvest-now-decrypt-later attacks today.
Thanks to Luke Valenta, Ollie Hsieh and Alex Krivit for contributions to this work.
