Post-quantum encryption check: what your domain uses
Cloudflare now exposes the TLS key exchange per request, so a post-quantum encryption check is possible per domain. 70% of browsers are ready; 15% of origins.
About 70% of browser-generated traffic reaching Cloudflare is already protected by post-quantum encryption, and about 15% of the origins Cloudflare connects to support it. Until this week a post-quantum encryption check at the level of your own domain was not possible; Cloudflare now exposes the negotiated TLS key exchange group per request, so you can answer the question for your traffic rather than for the internet's average.
The two numbers are the finding. Browsers did the hard part without asking anyone. The gap is behind the proxy, on servers your team owns.
Where the post-quantum encryption check now lives
Cloudflare's announcement of 29 September 2026 adds the key exchange group in three places:
| Surface | What you get | Which leg of the connection |
|---|---|---|
| HTTP Traffic Analytics dashboard | A dedicated TLS Key Exchange card, and the group as a filtering term | Visitor to Cloudflare |
| Log Explorer | Per-request filtering on the key exchange group | Visitor to Cloudflare |
| Logpush | ClientTLSKeyExchangeGroup and OriginTLSKeyExchangeGroup | Both |
The dashboard card sits under Analytics, on the HTTP Traffic page, and Cloudflare notes you have to scroll for it. The Logpush field ClientTLSKeyExchangeGroup is enabled under the TLS category of the HTTP Requests dataset, and shows up in log lines alongside RayID and EdgeResponseStatus.
OriginTLSKeyExchangeGroup is deliberately absent from the dashboard. Cloudflare explains that the origin-side group is the same for every visitor connection to a domain, so there is nothing to graph — it is one value, and it is either post-quantum or it is not. That makes it the single most informative field in this release, and it is only in the logs.
What the group names mean
You will see five values, and only one of them is post-quantum.
- X25519MLKEM768 — hybrid post-quantum. In TLS 1.3 it is the only recommended algorithm for post-quantum encryption, and it is what most major browsers now prefer. It runs an ordinary X25519 elliptic-curve exchange and ML-KEM-768 side by side and combines both shared secrets, so the result is secure as long as either one is.
- X25519, P-256, P-384 — classical ECDHE over different curves. Still ubiquitous, still fine against a classical adversary.
- X25519Kyber768Draft00 — the pre-standardisation draft Cloudflare shipped before the IETF finished X25519MLKEM768. Now deprecated. Cloudflare is keeping support until observed connections are negligible rather than cutting off clients for which it is the only post-quantum path.
- None — RSA key agreement in TLS 1.2 or earlier, or no TLS at all.
The constraint worth internalising: post-quantum encryption is not available in TLS 1.2 or any earlier version. There is no back-port. If a connection is not TLS 1.3, the key exchange cannot be post-quantum, and no setting will change that.
Is post-quantum encryption enabled on my domain? Three readings and what each means
Run the check, then match what you see against one of these.
Mostly X25519MLKEM768 on the client leg. Nothing to do on the visitor side. Go straight to OriginTLSKeyExchangeGroup, which is where the 15% figure will bite.
No X25519MLKEM768 at all. Confirm TLS 1.3 is switched on, under SSL/TLS then Edge Certificates in the dashboard. Cloudflare is explicit that there is no separate post-quantum toggle: with TLS 1.3 enabled and a visitor that supports the group, it is negotiated automatically.
Mostly classical X25519, P-256, P-384 or None, with TLS 1.3 already on. This is the reading people misdiagnose. Cloudflare's own explanation is that most visitors to that domain are probably non-browser clients that lack X25519MLKEM768 or TLS 1.3 support. For an API hostname consumed by SDKs, embedded devices or an old HTTP client in someone else's stack, that is the expected result and not a misconfiguration on your side. Fixing it means moving clients you may not control, which is a different project with a different budget.
The origin gap, and the three ways to close it
If the origin leg comes back classical, you have three options and they cost very differently.
- Upgrade the origin's TLS stack so it negotiates TLS 1.3 with X25519MLKEM768. Correct, permanent, and the slowest where the origin is a vendor appliance or an application server nobody wants to touch.
- Check for a misconfiguration first. Cloudflare notes that outdated configuration can cause an origin to connect using classical cryptography even when it does support post-quantum encryption. Confirm the origin actually lacks support before scheduling an upgrade for it.
- Put the origin behind Cloudflare Tunnel, which carries traffic from the origin to Cloudflare over TLS 1.3 with X25519MLKEM768 without upgrading the origin itself. Cloudflare recommends this specifically for legacy origins.
The tunnel route is the pragmatic one for the estates we usually meet — a modernised edge in front of application servers that have not moved in years. It is the same reasoning we apply in legacy application modernization work: change the boundary, then change what sits behind it, rather than blocking one on the other.
Harvest now, decrypt later — stated honestly
The reason to care before quantum computers exist is that an adversary can record encrypted traffic today and decrypt it later once the hardware arrives. Cloudflare's framing is the right one: this matters for data that is still valuable if decrypted in three to ten years. Public sector, defence, finance, telecom and healthcare are the examples given.
Be honest about the rest. If your traffic is session tokens that expire in an hour and product pages that are public anyway, recorded ciphertext decrypted in 2034 is worth very little. The calculation is about the shelf life of what crosses the wire, not about how frightening the phrase sounds.
The deadlines are real even where the threat is not immediate. NIST stated in 2024 that RSA and elliptic-curve cryptography should be deprecated by 2030, and Cloudflare notes that many governments and regulators have since adopted that date; Cloudflare itself is targeting 2029 for full post-quantum security. If you sell into a regulated sector, the question arriving in security questionnaires over the next two years is not whether you feel exposed. It is whether you can produce a number.
That is the quiet value of this release: post-quantum readiness becomes a measurable property of your estate rather than a paragraph in a policy document. A ClientTLSKeyExchangeGroup breakdown by hostname, exported on a schedule, is a defensible answer. Teams already doing infrastructure management and monitoring properly can add it to the same pipeline that carries their other log fields, and the SSL/TLS documentation confirms that post-quantum key agreement applies only to TLS 1.3-based protocols, including HTTP/3.
Start with the origin leg. Client-side adoption is being handed to you by browser vendors at roughly 70%; the half you are accountable for is the one sitting at 15%, and unlike the first number, nobody is going to fix it on your behalf. If that points at servers your team would rather not touch, the tunnel buys time — and the decision about what to do with that time belongs in the same conversation as the rest of your DevOps and cloud engineering roadmap.
Frequently asked questions
X25519MLKEM768 is the hybrid post-quantum key exchange group used in TLS 1.3. It runs a classical X25519 elliptic-curve exchange and the post-quantum ML-KEM-768 mechanism together, then combines both shared secrets, so the connection stays secure as long as either component remains unbroken.
Open the Cloudflare dashboard, go to HTTP Traffic under the Analytics tab, and scroll to the TLS Key Exchange card. For per-request detail, enable the ClientTLSKeyExchangeGroup field under the TLS category of the HTTP Requests dataset and read it in Log Explorer or Logpush.
The most common cause is that TLS 1.3 is switched off, since post-quantum key agreement is unavailable in TLS 1.2 and earlier. Enable TLS 1.3 under SSL/TLS then Edge Certificates. There is no separate post-quantum setting; Cloudflare negotiates X25519MLKEM768 automatically when the visitor supports it.
You have three options: upgrade the origin's TLS stack, check first whether outdated configuration is causing a classical negotiation on an origin that does support post-quantum encryption, or place the origin behind a Cloudflare Tunnel so the origin-to-Cloudflare leg runs TLS 1.3 with X25519MLKEM768.
A harvest now, decrypt later attack is one where an adversary records encrypted traffic today and decrypts it years later once sufficiently powerful quantum computers exist. It matters most for data that retains value if decrypted in three to ten years, and much less for short-lived session data.
X25519Kyber768Draft00 is the pre-standardisation draft Cloudflare implemented before the IETF finalised X25519MLKEM768. It is now deprecated, but Cloudflare has kept support until observed connections become negligible so that clients relying on it as their only post-quantum path are not regressed.
