Cloudflare's Automatic Key Exchange probes each origin's TLS 1.3 key-agreement capabilities and leads with the algorithm the origin prefers, preferring post-quantum X25519MLKEM768. HelloRetryRequests on origin connections fell from roughly 52% to 3.7%, and p90 handshake latency dropped more than 150 ms. It is enabled by default with an opt-out toggle in the dashboard.

Post-quantum protection now applies to your origin leg by default, but verify your server with the Cloudflare Radar post-quantum check — a failed check blocks the upgrade. Do not enable the new Compliance requirements (post-quantum or FIPS-only) unless policy requires it: enforcing them on an origin without X25519MLKEM768 support breaks all TLS 1.3 connections to it.

Cloudflare Automatic Key Exchange Cuts Origin Handshake Latency 150ms, On by Default

Cloudflare shipped Automatic Key Exchange today as part of Automatic SSL/TLS: it probes your origin's TLS 1.3 key-agreement capabilities out-of-band, then leads the first ClientHello with the algorithm your server actually prefers — X25519MLKEM768 wherever it can speak it. No config for most zones. It's live for new and existing domains by default, with an opt-out toggle under SSL/TLS → Overview → Configure → Origin.

What changed

The numbers from Cloudflare's scanned cohort: HelloRetryRequests fell from ~52% to 3.7% of origin connections, cutting more than 150 ms off p90 handshake latency (an HRR costs a full extra round trip). 99.2% of post-quantum origin connections now complete in one round trip, and post-quantum origin traffic has grown from ~25 billion to 45 billion connections/day. Roughly 9,000 domains per day get their key-exchange preference moved off plain X25519 — of the scanned cohort, ~33% now prefer post-quantum, ~64% stay classical.

Why a builder cares

Two things hide in the fine print. First, an MLKEM keyshare is 1,216 bytes vs X25519's 32 — that's why leading with PQ used to split the ClientHello across packets and break ~0.34% of origins behind legacy middleboxes. Cloudflare's scanner avoids exactly those origins, but if you terminate TLS yourself, run your host through the Cloudflare Radar PQ check: a failed check blocks your domain from the upgrade, and clearing it is on you. Second, the new Compliance requirements setting is a trap: enforce post-quantum or FIPS-only on an origin without X25519MLKEM768 and every TLS 1.3 connection fails — Cloudflare explicitly says to leave both boxes unchecked unless policy forces your hand.

The default-on framing is the usual trade: you get harvest-now-decrypt-later protection with zero effort, and Cloudflare gains a per-origin scan of your TLS stack in exchange. If that scanning bothers you more than a passive adversary recording today's ciphertext, the opt-out reverts to the static X25519-first order.

What changed

Why a builder cares

Related