Every time Cloudflare opens a new TLS 1.3 connection to an origin server, it has to make a guess: the protocol requires the client to commit to a key agreement algorithm in the very first packet, before the origin has said anything about what it supports. Guess right and the handshake finishes in one round trip. Guess wrong and the origin answers with a HelloRetryRequest, the handshake restarts, and the connection costs two round trips.
For years, Cloudflare’s guess was identical for every origin on the Internet: X25519. Widely supported, but suboptimal for roughly 30% of origin connections once measured. On September 8, 2026, Cloudflare announced Automatic Key Exchange, an extension of Automatic SSL/TLS that 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 on the first try, preferring the post-quantum hybrid X25519MLKEM768 wherever the origin can speak it.
This article is adapted from the Cloudflare engineering post by Suleman Ahmad, Yawar Jamal, and Alex Krivit. Read the original announcement on the Cloudflare blog for the full measurement details.
For background on the broader migration, see The Definitive Post-Quantum Cryptography Migration Checklist and the companion piece on post-quantum authentication to origins.
What to Remember
- Measure, don’t guess. Automatic Key Exchange probes each origin per group and leads with its preferred algorithm, favoring post-quantum X25519MLKEM768 wherever supported.
- Retries nearly eliminated. HelloRetryRequests dropped from about 52% to 3.7%, saving 150 ms or more at p90, with 99.2% of post-quantum origin handshakes now completing in one round trip.
- Post-quantum at scale, automatically. Around 33% of scanned domains moved to X25519MLKEM768, and post-quantum origin traffic grew from 25 billion to 45 billion connections per day.
- Guardrails narrow, they don’t upgrade. The post-quantum-hybrid-only and FIPS-only compliance options restrict negotiation; enforcing them against an unready origin breaks its TLS connections.
- No origin support, still faster. Classical-only origins keep a retry-free classical preference, and go post-quantum via Cloudflare Tunnel or a TLS endpoint upgrade verified with Cloudflare Radar.
The TLS 1.3 Guessing Problem
Cloudflare operates as a reverse proxy, so what looks like one secure connection is actually two: visitor to Cloudflare, and Cloudflare to origin. Each has its own handshake, identity checks, and keys. Automatic Key Exchange affects the second connection, where Cloudflare acts as the TLS client and opens with a ClientHello containing the hostname and a list of supported key agreement algorithms.
In the happy path, TLS 1.3 establishes an encrypted connection in a single round trip: Cloudflare sends a ClientHello with its supported groups plus one or more client keyshares, the origin accepts, and the handshake completes. This predictive key exchange is a large part of why TLS 1.3 is faster than TLS 1.2. If the origin prefers a different group, it replies with a HelloRetryRequest asking Cloudflare to try again with the specified algorithm. The connection still succeeds, but the retry adds a full round trip before any content can be fetched.
Either way, the server uses the client keyshare to derive the shared secret, returns its own keyshare, and the rest of the connection is protected with symmetric cryptography such as AES.
Why the Safe Default Cost a Round Trip
For years, Cloudflare’s initial keyshare for origin connections was static: always X25519, while advertising support for other groups. The strategy was safe because over 95% of origins support X25519, and the rest could fall back to a HelloRetryRequest without breaking.
The problem is that X25519 is not quantum-safe. Since September 2023, Cloudflare has advertised post-quantum key agreement to origins, first as X25519Kyber768Draft00 and today as the standardized X25519MLKEM768. But advertising support is not the same as leading with a post-quantum keyshare. An X25519MLKEM768 keyshare is 1,216 bytes against X25519’s 32 bytes, pushing the ClientHello past a single network packet. Some legacy middleboxes and origin servers fail on multi-packet ClientHello messages: in Cloudflare’s earlier study, around 0.34% of scanned origins failed the handshake when receiving a post-quantum keyshare first.
So Cloudflare used the HelloRetryRequest as a safety valve. It advertised post-quantum support, sent a classical X25519 keyshare, and required capable origins to request the upgrade via retry. Customers that wanted to lead with post-quantum could opt in manually. Meanwhile, origin support for post-quantum key exchange grew from 0.5% to 12.8% between 2023 and today, and keeps climbing as hosting stacks upgrade.
Safe, but slow for two reasons. First, modern builds of OpenSSL, BoringSSL, and rustls all support X25519MLKEM768 yet handle a classical keyshare differently: depending on the build, some accept it by default while newer builds immediately issue a HelloRetryRequest to prioritize post-quantum. Second, over 6% of origins prefer P-256 or P-384 over X25519, so even purely classical connections paid a retry round trip because of the static initial choice.
How Automatic Key Exchange Works
Automatic Key Exchange extends the scanning pipeline that already powers Automatic SSL/TLS. Instead of inferring capability, it measures it directly:
- Probe each group independently. For every TLS 1.3-capable origin, Cloudflare runs a series of lightweight handshakes, each offering exactly one key agreement group: X25519, P-256, P-384, P-521, or X25519MLKEM768. Together the probes reveal the full set the origin supports. Scanning happens outside the production traffic path, so origin and network behavior with stronger key agreement is confirmed before real traffic depends on it.
- Weight by real traffic. A domain often fronts multiple subdomains resolving to different origins with different capabilities. Each subdomain is evaluated independently and weighted by actual traffic volume, so a dormant subdomain does not count equally with the busiest endpoint.
- Pick the strongest candidate. From the supported set, Cloudflare selects using a strict priority order: post-quantum hybrids (X25519MLKEM768) first, then the fastest classical algorithm the origin accepts.
- Roll out gradually with rollback. The new preference goes to a small share of the origin’s traffic first while failure and HelloRetryRequest rates are monitored. If retries climb above baseline, the change rolls back, the same way Automatic SSL/TLS reverts a misbehaving encryption-mode upgrade. At worst, a bad preference costs one extra round trip during rollout, not a broken connection.
- Rescan daily. Origins change: load balancers move, libraries gain post-quantum support in routine releases, operators disable old groups. Every origin is rescanned daily so preferences track reality.
For most customers there is nothing to configure. If the origin speaks TLS 1.3, Cloudflare negotiates the strongest key exchange it supports, including post-quantum agreement with no extra round trip.
Configuring It: One Toggle and Two Guardrails
Automatic Key Exchange is active by default for new and existing domains. It can be managed in the dashboard under SSL/TLS, then Overview, then Configure, under Origin connection and post-quantum encryption. With the toggle on, Cloudflare scans out of band and leads with a dynamically selected keyshare. With it off, scanning stops and Cloudflare reverts to a fixed default order.
A new Compliance requirements setting filters which key agreements Cloudflare may use and advertise toward origins:
- Post-quantum hybrid restricts negotiation exclusively to hybrid post-quantum agreements (X25519MLKEM768). Every successful origin TLS 1.3 connection is then guaranteed post-quantum secure.
- Federal Information Processing Standards (FIPS) restricts negotiation exclusively to FIPS-compliant agreements.
Selecting both requires an algorithm satisfying both criteria at once, and the configuration is rejected if none exists. The intent-based design means the setting stays current as standards evolve and new post-quantum algorithms emerge.
Treat these options carefully. They narrow what Cloudflare can negotiate; they do not grant the origin new capabilities. Enforcing post-quantum hybrid against an origin without X25519MLKEM768 support leaves no mutually supported algorithm, so all TLS 1.3 connections to that origin fail. Unless a strict policy obligation demands it, leave both unselected and let Automatic Key Exchange negotiate the optimum safely.
The Results So Far
The scanning pipeline has assigned key exchange preferences to well over a million domains, with enrollment continuing. From that cohort:
- Roughly 64% stayed on classical X25519, so nothing about their connections changed.
- Around 33% moved to X25519MLKEM768, gaining protection against harvest-now, decrypt-later attacks in a single round trip.
- The remaining 3% adopted a different classical curve their origin prefers, such as P-384, P-256, or P-521.
About 9,000 domains per day get a non-X25519 preference, nearly all moving straight to post-quantum. The share of post-quantum origin TLS 1.3 traffic completing without a HelloRetryRequest rose from 0% to 99.2%, and post-quantum origin traffic grew from roughly 25 billion to 45 billion connections per day, driven substantially by Automatic Key Exchange upgrading classical connections.
Active probing also uncovered thousands of origins whose post-quantum support never appeared in passive traffic. Many origins accept a classical keyshare without issuing a retry even when they support post-quantum, so observation alone cannot reveal full capability. Once the scanner updated their preference, post-quantum connections quickly became the vast majority of their traffic.
Across all scanned origins, the overall HelloRetryRequest rate fell from roughly 52% to 3.7%, removing a full round trip from connection setup and cutting p90 latency by more than 150 ms. The gain lands on dynamic requests and cache misses that need a fresh origin connection; existing keep-alive connections are unaffected.
What This Means for Security Teams
The feature is Cloudflare-specific, but the lessons generalize to any post-quantum migration:
- Check whether your origin is post-quantum capable. Cloudflare Radar can test a hostname or IP for post-quantum key exchange support and characterize implementation bugs, such as middleboxes dropping multi-packet ClientHello messages or origins mishandling the HelloRetryRequest flow. Automatic Key Exchange will not switch an origin that fails these checks, so clearing them is what unlocks the upgrade. Note that a hostname proxied by Cloudflare tests the edge connection, not the origin behind it.
- If the origin lacks support, you still benefit. Automatic Key Exchange finds what the origin does support and avoids unnecessary retries even with classical-only endpoints.
- To gain post-quantum origin connections, you have two paths. Use Cloudflare Tunnel, where the cloudflared connection is already post-quantum, which is simplest when the public endpoint’s TLS software cannot change. Or upgrade the TLS endpoint: current frameworks and libraries enable X25519MLKEM768 by default, but manually configured curve lists can override the new defaults. Audit everything terminating or inspecting TLS between Cloudflare and the origin, including load balancers, WAF appliances, and middleboxes, and confirm X25519MLKEM768 is enabled on each. Managed hosting customers should ask their provider directly.
- Leave compliance enforcement off unless policy requires it. Enforcing post-quantum-only or FIPS-only negotiation against an unready origin breaks connectivity rather than upgrading it.
- Separate key agreement from authentication. Post-quantum key exchange protects today’s traffic from future decryption. It does not stop an attacker with a quantum computer from forging a classical certificate and impersonating the origin. That half of the problem needs post-quantum authentication, covered in the companion piece on ML-DSA origin authentication.
What’s Next
Automatic Key Exchange is the second step in the Automatic SSL/TLS arc Cloudflare has been building in public since 2024. Three items are explicitly on the roadmap:
- Per-origin preference granularity. Decisions are currently made at domain level, so one lagging origin can hold a whole domain back. Key agreement and encryption modes will vary across the origins serving a single domain.
- On-demand scans. After upgrading an origin’s TLS stack, operators should not wait for the next scheduled scan. A dashboard and API trigger will re-evaluate immediately, and double as a diagnostic showing exactly which agreements negotiate and why failures occur.
- Automatic post-quantum origin authentication. Post-quantum key agreement must eventually be paired with post-quantum authentication (ML-DSA certificates, and later Merkle Tree Certificates). The hard part is downgrades: an active adversary could strip the post-quantum offer and force fallback to a forgeable classical certificate. Cloudflare plans to extend scanning to detect ML-DSA support and then automatically disable classical fallback for customers wanting strict protection.
Closing the Harvest-Now Window
Somewhere right now, an adversary is recording traffic it cannot read yet, betting it will be able to later. Cloudflare is sprinting to make the Internet quantum-secure by 2029, the year some industry experts expect classical encryption could break: Q-Day. That deadline cannot depend on millions of operators each becoming cryptographers. Universal SSL made edge encryption automatic; Automatic SSL/TLS is doing the same for origin connections, and now extends that work to post-quantum key agreement.
Check the SSL/TLS section of the dashboard to see the origin encryption level, verify post-quantum readiness with Cloudflare Radar, and if the origin already supports it, Automatic Key Exchange will use it: faster and more secure, with nothing to configure.
To further enhance your cloud security and PQC readiness, contact me on LinkedIn Profile or [email protected].
Frequently Asked Questions (FAQ)
What is Cloudflare Automatic Key Exchange?
Automatic Key Exchange is an extension of Automatic SSL/TLS that probes each origin to learn which TLS 1.3 key agreement algorithms it supports and prefers, then leads with that algorithm in the first ClientHello. It prefers the post-quantum hybrid X25519MLKEM768 wherever the origin supports it, eliminating the HelloRetryRequest round trip.
Why did Cloudflare previously always lead with X25519?
X25519 is supported by over 95% of origins, so it was a safe static guess, and any origin that disagreed could request a retry without breaking the connection. But a post-quantum keyshare is 1,216 bytes versus 32 bytes, which splits the ClientHello across packets and failed on about 0.34% of origins, so Cloudflare only upgraded to post-quantum via retry unless customers opted in manually.
What results has the rollout produced?
Across the scanned cohort of over a million domains, HelloRetryRequests fell from roughly 52% to 3.7%, cutting handshake latency by more than 150 ms at p90. About 33% of domains moved to X25519MLKEM768, 99.2% of post-quantum origin handshakes now complete in one round trip, and post-quantum origin traffic grew from 25 billion to 45 billion connections per day.
How does Automatic Key Exchange pick the key agreement?
Out-of-band probes offer each group (X25519, P-256, P-384, P-521, X25519MLKEM768) individually, subdomains are weighted by real traffic volume, and the strongest supported candidate wins under a strict order with post-quantum hybrids first. Preferences roll out to a small traffic share with automatic rollback on elevated retries, and every origin is rescanned daily.
Should I enforce the post-quantum hybrid compliance option?
Only with a strict policy obligation. The setting narrows what Cloudflare may negotiate without adding capability to the origin, so enforcing it against an origin without X25519MLKEM768 support breaks all TLS 1.3 connections to that origin. For most setups, leave compliance options unselected and let Automatic Key Exchange negotiate safely.
How do I get post-quantum origin connections if my origin lacks support?
Use Cloudflare Tunnel, whose cloudflared connection already uses post-quantum key agreement, or upgrade the TLS endpoint so X25519MLKEM768 is enabled on the server and every middlebox in path, including load balancers and WAF appliances. Manually configured curve lists can override new library defaults, so audit them, and verify with Cloudflare Radar.
Relevant Resources
- Cloudflare engineering blog: Automatic Key Exchange announcement by Suleman Ahmad, Yawar Jamal, and Alex Krivit (September 8, 2026)
- Post-quantum authentication: Post-quantum authentication to origins is now supported
- PQC planning: The Definitive Post-Quantum Cryptography Migration Checklist
- TLS migration: The Quantum-Proof Handshake: Your Blueprint for Migrating to Post-Quantum TLS
