Cloudflare has replaced a static assumption in its origin TLS handshakes with a per-origin measurement, cutting HelloRetryRequests on scanned origins from roughly 52% to 3.7% and removing more than 150 ms from p90 handshake latency.
The assumption had been in place for years. TLS 1.3 requires a client to commit to a key agreement algorithm in its first packet, before the server has said anything about what it supports. Guess correctly, and the handshake completes in one round trip. Guess wrong and the origin returns a HelloRetryRequest, the client sends a second ClientHello, and the connection costs two.
TLS 1.3 handshake completing in one round trip, and the same handshake with a HelloRetryRequest (Source: Cloudflare)
Cloudflare guessed X25519 for every origin on the internet, on the reasonable grounds that over 95% of origins support it. Measurement showed that guess was suboptimal for roughly 30% of origin connections. More than 6% of origins prefer P-256 or P-384 over X25519, which means those connections were paying an extra round trip for entirely classical reasons.
Automatic Key Exchange, an extension of Automatic SSL/TLS, probes each origin to learn which algorithms it supports and prefers, then leads with that algorithm. Where an origin can handle the post-quantum hybrid X25519MLKEM768, Cloudflare prefers it. Probing runs outside the production traffic path, one key agreement group at a time, and origins are rescanned daily so preferences track changes to load balancers and TLS libraries. The feature is on for all existing zones and on by default for new ones, with a toggle in the dashboard under SSL/TLS, and Cloudflare applies one preference across a zone.
Measurement turned out to reveal more than observation had. Cloudflare reports that active probing uncovered thousands of origins whose post-quantum support never appeared in passive traffic, because many origins accept a classical keyshare without issuing a retry even when they support something stronger.
The post-quantum side of the change has a constraint worth understanding. An X25519MLKEM768 keyshare is 1,216 bytes against X25519's 32, which pushes the ClientHello past a single network packet. The TLS standard permits multi-packet segments, but some legacy middleboxes and origin servers fail when a ClientHello is split across TCP segments. In Cloudflare's earlier study, around 0.34% of scanned origins failed to complete the handshake when sent a post-quantum keyshare first.
That is why Cloudflare had been using HelloRetryRequest as a safety valve since September 2023, advertising post-quantum support but leading with classical X25519 and requiring capable origins to ask for the upgrade via retry. The result was that almost every post-quantum origin handshake paid a mandatory second round trip.
The adoption figures give the change its context. Origin support for post-quantum key exchange has grown from 0.5% in 2023 to 12.8% today, which means roughly seven in eight origins still cannot use it. Among the cohort Cloudflare has scanned so far, 64% stayed on classical X25519 with nothing about their connections changing, 33% moved to X25519MLKEM768, and 3% moved to a different classical curve such as P-384, P-256 or P-521.
For the origins that can use post-quantum key exchange, the round-trip penalty is now largely gone. The share of post-quantum origin TLS 1.3 traffic completing without a HelloRetryRequest rose from 0% to 99.2%. Post-quantum origin traffic across the scanned cohort grew from roughly 25 billion connections a day to 45 billion, which Cloudflare attributes in part to Automatic Key Exchange upgrading classical connections.
A new Compliance requirements setting carries a risk worth flagging. It filters which key agreements Cloudflare may negotiate, with options for post-quantum hybrid only and for FIPS-compliant algorithms only. These narrow what Cloudflare can use rather than granting the origin new capabilities, so enforcing post-quantum hybrid against an origin that does not support X25519MLKEM768 leaves no mutually supported algorithm and all TLS 1.3 connections to it fail. Selecting both options at once is rejected if no algorithm satisfies both. The settings apply only to TLS 1.3 connections.
Teams with existing automation should note a quieter change. The Origin Post-Quantum Encryption API remains available, but requests to it are now no-ops that do not change a zone's post-quantum key agreement behavior. Cloudflare says it plans to deprecate the API without giving a date. Origins can be checked directly with BoringSSL's bssl client tool against port 443, confirming that the negotiated curve reports X25519MLKEM768.
The rollout mechanism is conservative. A new preference goes to a small share of an origin's traffic first, with the system monitoring failure and retry rates against that origin's baseline. If retries climb, the change is rolled back, the same pattern Automatic SSL/TLS uses when an encryption mode upgrade misbehaves. Cloudflare notes that the worst case of a rollback is an additional round trip rather than a broken connection.
Two limits are worth noting for teams assessing the benefit. The latency improvement applies to new connections, so requests on existing keep-alive connections are unaffected, and the gain concentrates on dynamic requests and CDN cache misses that require a fresh origin handshake. And Automatic Key Exchange cannot prefer post-quantum key exchange where an origin does not support it, though Cloudflare says the feature still helps by learning which classical algorithm an origin prefers.
Key agreement is only half the problem. It protects today's traffic from future decryption but does not prevent an attacker with a quantum computer from forging a classical certificate and impersonating an origin. Cloudflare has supported ML-DSA post-quantum signatures since mid-2026 in Authenticated Origin Pulls and Custom Origin Trust Store, which together allow end-to-end post-quantum authentication to an origin today. The documentation warns that presenting an ML-DSA certificate achieves nothing unless the verifying side rejects classical certificates, since an attacker who compromises a classical key can otherwise impersonate the peer.
Three items sit on the roadmap. Preferences are decided per zone, so one lagging origin can hold back a whole zone, and Cloudflare plans per-origin granularity. On-demand scans through the dashboard and API would let operators trigger re-evaluation after upgrading a TLS stack rather than waiting for the next daily scan. And the company intends to extend scanning to detect ML-DSA support automatically and disable classical fallback for customers wanting strict protection.
Cloudflare frames the work against a 2029 target it calls Q-Day, the year some industry estimates suggest classical encryption could be breached, and against harvest-now decrypt-later attacks where recorded traffic is stored for future decryption. Recent versions of BoringSSL, OpenSSL and rustls include post-quantum support, while enterprise origin stacks, cloud load balancers and embedded TLS terminators upgrade on their own timelines.