Post-Quantum TLS Adoption: What 2 Billion Handshakes Show

A team from UNSW Sydney and Georgia Tech just published the first longitudinal, Internet-scale look at how post-quantum TLS is actually being deployed, as opposed to how governments say it should be. The paper, “Mind the Gap: Policy vs Reality in Post-Quantum TLS Deployment,” ran three measurement rounds between July 2025 and March 2026, probed 1 million domains from 11 vantage points around the world, and logged more than 2 billion TLS handshakes in the process. That’s a big enough sample to say something real about where PQ-TLS stands right now, and the answer is messier than the roadmaps suggest.

If you’ve been in a PQC planning meeting this year, you’ve probably seen a slide with a national timeline on it: NIST’s 2030/2035 deprecation dates, the UK NCSC’s phased plan running to 2035, Australia’s 2030 cutoff for classical crypto in government systems. Those slides imply an orderly, sector-by-sector migration. The data says something different.

One config to rule them all

Every country in the study’s policy survey (the US, UK, Australia, Canada, the EU, Germany, France, India) recommends a slightly different mix of algorithms and hybrid requirements. In practice, none of that variety shows up on the wire. The researchers found that real-world PQ-TLS deployment has converged almost entirely on a single hybrid group: X25519MLKEM768, pairing classical elliptic-curve Diffie-Hellman with ML-KEM-768. Whatever a given country’s policy document says about SLH-DSA or ML-KEM-1024 for high-assurance systems, that’s not what’s showing up in production handshakes. The market picked a default before most of the policy documents even had teeth.

It’s really a Cloudflare and Fastly story

Here’s the part that should reframe how you think about “adoption” numbers: close to 70% of all observed PQ-TLS deployment traces back to two providers, Cloudflare and Fastly. Most of the sites that light up green on a PQC readiness scan didn’t do anything. Their CDN flipped a default, and they inherited the protection.

That’s not a knock on Cloudflare or Fastly, whose defaults have genuinely moved the needle on harvest-now-decrypt-later exposure for a huge slice of the web. But it means aggregate adoption percentages are mostly measuring CDN market share, not organizational readiness. If your org runs its own TLS termination, whether on-prem, in a colo, or on infrastructure that isn’t proxied through one of a handful of major providers, the national “we’re at X% adoption” statistics tell you approximately nothing about your own exposure. You’re not part of the number that’s moving.

National timelines aren’t predicting deployment

The paper’s most useful contribution for anyone doing PQC planning is the direct comparison between sectoral policy priority and observed deployment. Governments have been explicit about which sectors should move first: finance, critical infrastructure, government services. The measurement data shows limited correspondence between those stated priorities and what’s actually deployed. Sectors that policy documents flag as urgent aren’t consistently ahead of sectors that aren’t. Deployment is being driven by which CDN a site happens to sit behind, not by a risk-based rollout plan.

If you’re building a business case around “our sector is a stated priority, so we’re already covered by industry momentum,” this study is a good reason to check that assumption against your actual infrastructure rather than a policy PDF.

The performance objection doesn’t hold up anymore

There’s some genuinely good news buried in the methodology section. Earlier lab studies raised real concerns about PQ-TLS handshake overhead, larger key sizes, more round trips, slower connection setup. At Internet scale, across 2 billion real handshakes, the researchers found no meaningful latency penalty from PQ-TLS negotiation. If your rollout has been stuck behind a performance objection from three years ago, that objection is no longer supported by the evidence. The tradeoff showing up in production is operational complexity, not speed. Plenty of PQ-enabled endpoints are still running hybrid negotiation alongside legacy, non-PQ TLS configurations instead of swapping one out for the other.

What this means for your migration plan

Two things worth taking away. First, don’t trust aggregate PQ-TLS adoption stats as a proxy for your own posture. If you’re not behind Cloudflare or Fastly, go measure your own endpoints directly instead of borrowing comfort from a headline percentage. Second, the performance excuse is dead. The remaining barriers to hybrid key exchange are operational, not computational, so if your team has been waiting for “the overhead problem to get solved,” it already has. What’s left is the unglamorous work of actually turning it on.