Post-Quantum TLS Is Real Traffic Now — Here Is What the Measurements Actually Show

What Changed in the Handshake

In August 2024 the US National Institute of Standards and Technology finalized its first three post-quantum cryptography standards: FIPS 203, FIPS 204 and FIPS 205, covering key encapsulation and two digital-signature schemes built on lattice and hash-based mathematics rather than the factoring and discrete-logarithm problems RSA and elliptic-curve cryptography rely on. NIST's announcement was explicit about urgency: the agency itself warned that a sufficiently capable quantum computer "would be able to sift through a vast number of potential solutions to these problems very quickly, thereby defeating current encryption," and quoted its mathematician Dustin Moody telling system administrators to "start integrating them into their systems immediately," adding there was "no need to wait for future standards."

Two years on, the question worth asking is not whether the standards exist but whether anyone is using them, and for what. The answer, from the organizations and researchers who actually measure internet traffic, is: partially, unevenly, and only for half of the problem.

The part of TLS that post-quantum cryptography has reached first is key exchange — the handshake step where a browser and a server agree on a shared secret before any data moves. Standard TLS 1.3 handshakes use classical algorithms such as X25519 for this. The migration path, formalized by the IETF as RFC 10024, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3," published as a Proposed Standard in 2026, does not replace X25519 outright. It defines three hybrid mechanisms — X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 — that run a classical exchange and NIST's ML-KEM (FIPS 203) exchange side by side and combine both shared secrets. The design is deliberate: if ML-KEM's underlying lattice assumption turns out to have an unforeseen weakness, the connection still has the protection of the classical algorithm, and vice versa against a quantum adversary.

That hybrid design answers a specific threat that has nothing to do with quantum computers existing today. It is called "harvest now, decrypt later": an adversary records encrypted traffic now, stores it, and waits for a quantum computer capable of breaking classical key exchange to arrive later. A 2026 analysis on arXiv by Javier Blanco-Romero, Florina Almenares Mendoza, Carlos García Rubio, Celeste Campo and Daniel Díaz Sánchez, "On the Practical Feasibility of Harvest-Now, Decrypt-Later Attacks," set out to test whether this scenario is a genuine operational risk rather than a marketing line for cryptography vendors. The authors worked through the storage economics and the technical means an adversary would need to intercept, retain and eventually decrypt traffic at scale, and their analysis treats the attack as a substantive concern worth defending against now, not a purely hypothetical one — which is the premise every hybrid-key-exchange deployment in this piece rests on.

How Fast Browsers and Networks Actually Moved

Chrome was an early mover, and the record of why is unusually detailed because it played out in public. In Chromium's blink-dev mailing list, the team's intent-to-ship proposal for Kyber768 — ML-KEM's pre-standardization name — stated the goal plainly: "Protect current Chrome TLS traffic against future quantum cryptanalysis by deploying the Kyber768 quantum-resistant key agreement algorithm." The same thread disclosed the cost: Kyber key shares run roughly 35 times larger than an X25519 exchange, producing a measured 4-6% increase in TLS handshake latency, which the team judged tolerable on desktop, where connection pooling absorbs the hit, but worth treating more cautiously on mobile, where it affects page-load metrics such as Largest Contentful Paint. Chrome shipped the hybrid exchange by default on desktop starting in version 124, in March 2024, with Android and WebView following in version 128.

Once browsers and the networks they talk to both support a hybrid exchange, traffic volumes shift fast, because the mechanism activates automatically whenever both ends offer it — no certificate reissue, no site configuration change required. Cloudflare, which terminates TLS for a large share of global web traffic, tracks this through its Radar service and reported in its 2025 Year in Review that the global share of post-quantum-encrypted TLS 1.3 traffic on its network went from 29% at the start of 2025 to 52% in early December 2025, with 28 countries or regions more than doubling their share individually. Cloudflare singled out Kuwait, where the figure rose from 13% to 37%, and Puerto Rico, from 20% to 49%. It also pointed to a single operating-system update as a visible accelerant: after Apple's iOS 26 release in September 2025, the share of iOS-device requests carrying post-quantum support jumped from just under 2% to 11% within four days, and passed 25% by early December 2025.

By April 2026, Cloudflare's figure for all human traffic on its own network had risen further. In a post titled "Cloudflare targets 2029 for full post-quantum security," published April 7, 2026, the company wrote that "over 65% of human traffic to Cloudflare is post-quantum encrypted." A separate Cloudflare Radar post on origin connectivity, published February 27, 2026 — covering the leg between Cloudflare's edge and a customer's own servers, which the company does not control the way it controls its own edge software — reported that post-quantum support on that leg grew from under 1% at the start of 2025 to approximately 10% about a year later, which Cloudflare described as a tenfold increase. Browser-side support, measured separately in the same post, grew from under 3% at the start of 2024 to over 60% by February 2026. These are three different vantage points on the same connection and should not be collapsed into one figure: a visitor's browser offering post-quantum key exchange, Cloudflare's edge accepting it, and a customer's own origin server supporting it are three separate upgrades, and Cloudflare's own numbers show the first is well ahead of the third.

What an Independent Scan of 32,011 Domains Found

Cloudflare's figures describe Cloudflare's own network, which is large but not the internet. The most direct outside check comes from a 2026 measurement paper on arXiv by Vanishka Mohan Dubey, an independent researcher, and Gaurav Varshney of the Indian Institute of Technology Jammu, titled "Measurement Study of Post-Quantum Readiness of Internet: 2026." The authors scanned 32,011 domains — 31,884 drawn from the Tranco ranking and 127 banking domains from the Reserve Bank of India's own list — using Selenium WebDriver, OpenSSL and packet-level analysis to classify each site's negotiated protocol and key exchange. They found 52.41% of domains supported TLS 1.3 at all, and among the connections they could classify, 49.3% offered the hybrid X25519+ML-KEM-768 exchange while 50.7% remained classical-only. Broken down by CDN and hosting provider, the study found Cloudflare's own domains using the ML-KEM hybrid by default at a 37.97% rate in their sample, against 7.71% for AWS CloudFront, 3.17% for Fastly, 2.39% for Akamai and 1.76% for Google Cloud CDN — figures specific to the domains the authors sampled in their scan window, not a census of each provider's full customer base.

The same study's starkest finding concerns the other half of TLS: authentication. A handshake does two separate jobs — agreeing a shared secret (key exchange) and proving the server is who it claims to be (the certificate chain, signed with RSA or ECDSA today). Dubey and Varshney report that across their full sample, certificate signing remained 54.05% RSA-based and 42.32% ECDSA-based, with "0% adoption of hybrid post-quantum certificates observed," and the paper states this "leaves the authentication layer vulnerable" to future attacks such as certificate forgery once a quantum computer capable of breaking classical signatures exists. Harvest-now-decrypt-later does not apply to signatures the way it does to key exchange — there is no benefit to recording a signature today to forge one tomorrow — but a quantum-capable adversary able to forge classical signatures could still impersonate a server in real time once that capability arrives, which is why Cloudflare's own April 2026 roadmap draws the same line: "our work is not done until authentication is also upgraded."

Closing the Authentication Gap

Cloudflare's published timeline for closing that gap is specific about sequencing. Its April 2026 post lists PQ authentication — using ML-DSA, the signature standard NIST finalized as FIPS 204 — for Cloudflare's own connections to customer origin servers as a mid-2026 target, PQ authentication for visitor-to-Cloudflare connections using Merkle Tree Certificates as a mid-2027 target, PQ authentication across the company's Cloudflare One SASE product suite by early 2028, and full post-quantum security, encryption and authentication together, as a 2029 target. Each stage depends on the one before it: browsers, servers and certificate authorities all have to support a new signature scheme before it can be turned on by default, which is the same sequencing problem that stretched the ML-KEM key-exchange rollout across more than two years between Chrome's first shipment and Cloudflare's 65% figure.

Dubey and Varshney's sector breakdown adds a further qualification that the aggregate percentages hide: adoption is markedly uneven by industry. The paper flags banking, government, defence and telecom domains as disproportionately still relying on TLS 1.2, which does not support the hybrid exchange at all, against faster adoption among cloud, CDN, social-media and search-engine platforms. The authors attribute the gap to legacy infrastructure, compatibility requirements and regulatory dependencies rather than any technical barrier to upgrading — a reminder that a browser or edge network defaulting to post-quantum key exchange only protects a connection if the server on the other end, and everything in between, actually accepts it.

What This Means for Anyone Running TLS Today

The practical reading of these numbers is narrower than the headline percentages suggest. A browser offering hybrid key exchange, an edge network accepting it, and an origin server supporting it are three independent conditions, and Cloudflare's own data shows origin support lagging browser support by tens of percentage points. Independent domain scanning puts overall internet-wide hybrid adoption near half, not the roughly two-thirds Cloudflare reports for its own network, because the two measurements sample different populations through different methods. And no measurement reviewed here reports post-quantum certificates in production use anywhere, which means the harvest-now-decrypt-later defence that has driven most of this adoption curve still leaves server authentication running on classical algorithms — a gap NIST's standards, Cloudflare's roadmap and the independent scan all point to as the next problem, not a solved one.