Cloudflare reports that over 50% of human web traffic now uses post-quantum encryption. Behind Cloudflare’s edge, approximately 1% of origin server traffic is post-quantum protected. That gap — between what the edge reports and what the infrastructure actually does — is the most important number in post-quantum cryptography right now, and almost nobody is talking about it.
That was our opening line on February 24. Three days later, on February 27, Cloudflare launched origin-server PQC tracking on Radar.
The Timeline
The timing is worth noting because Cloudflare did not previously report origin PQC data on Radar. They tracked client-to-edge PQC adoption starting in April 2024. They mentioned origin numbers in passing at conferences. But the public dashboard only showed the headline number — the one measuring browser auto-updates.
Then, three days after we published a post arguing that edge adoption numbers create a false floor that obscures the actual state of infrastructure readiness, Cloudflare shipped a new section on Radar breaking out origin-side PQC support as a separate metric. They also launched a hostname-level PQC testing tool. And they reorganized all PQC data into its own dedicated section.
We are not claiming causation. We are noting the sequence.
The Numbers Now
Cloudflare’s new origin data shows approximately 10% of customer origins support X25519MLKEM768. That is a tenfold increase from less than 1% at the start of 2025, and a meaningful update to the figure we cited from Cloudflare’s Fraunhofer PQC Conference presentation.
But support is not the same as preference. Cloudflare’s own blog is explicit about this: their scanner tests whether an origin supports post-quantum key exchange, not whether it prefers it. An origin can advertise ML-KEM in its supported groups list while its TLS configuration selects a classical algorithm by default. The negotiated outcome depends on the server’s preference order, not just its capability list.
So the actual rate of post-quantum key agreement between Cloudflare’s edge and customer origins is something less than 10%. How much less, Cloudflare doesn’t say.
The gap we identified — over 60% client-to-edge, roughly 1% edge-to-origin — has narrowed to something like 60% versus some-fraction-of-10%. Still enormous. Still the most important number in PQC adoption. Still invisible in the headline metric that gets cited in policy documents and vendor marketing.
Passive Adoption Confirmed
Cloudflare attributes the origin-side improvement to a specific mechanism: server-side TLS libraries enabling hybrid post-quantum key exchange by default. They name OpenSSL 3.5.0+, GnuTLS 3.8.9+, and Go 1.24+. When these libraries ship with PQC groups in their default configuration, any application that upgrades its dependencies inherits PQC support without any deliberate action by the operator.
This is exactly the pattern we described in the original post as “PQC passivity” — adoption driven by software supply chain updates rather than security migration decisions. The same dynamic that explains browser-side adoption (Chrome auto-updates, Safari catching up with iOS 26) now explains the server-side improvement. Nobody decided to deploy PQC on their origin. They upgraded OpenSSL and it came along for the ride.
This is not a criticism of library maintainers. Shipping secure defaults is the right engineering decision. But it means the 10% figure measures the OpenSSL 3.5 upgrade rate, not the PQC migration rate. Organizations counted in that 10% may not know they support PQC. They haven’t inventoried which services negotiate it. They can’t tell their board whether they’re getting better or worse over time because they never started tracking.
One Port, One Protocol
Cloudflare’s new hostname checker is a useful tool. Enter a domain, get a result: post-quantum secure or not. It tests whether a TLS handshake on port 443 negotiates X25519MLKEM768.
That answers one question. It does not answer whether the same organization’s SSH servers negotiate post-quantum key exchange. Or their SMTP relays. Or their VPN gateways, database endpoints, LDAP services, RDP servers, or any of the other protocols carrying data that a harvest-now-decrypt-later adversary would find valuable.
An organization with a green checkmark on port 443 and classical cryptography on every other service has not migrated. It has a PQC-capable web front end.
What Changed, What Didn’t
What changed: Cloudflare now reports origin PQC data publicly, gives it its own section on Radar, and provides a hostname-level testing tool. This is a meaningful step toward transparency about the actual state of post-quantum deployment. The origin number is 10x better than a year ago.
What didn’t change: the structural gap between edge and origin remains massive. The adoption mechanism remains passive. The measurement remains single-protocol, single-port, point-in-time. And the headline number that appears in press coverage, policy briefs, and vendor pitch decks still measures browser market share, not infrastructure readiness.
The false floor is higher than it was. It is still a false floor.
pqprobe scans 20+ protocols across 60+ port variations, tracks migration trajectory over time, and distinguishes between support, preference, and actual negotiation. The question isn’t whether your web server passes a single-port check. The question is whether your infrastructure is getting better or worse.