Read this first
Cloudflare's State of the post-quantum Internet in 2025 reports that by mid-September 2025 roughly 43% of human-generated connections to its network already used hybrid post-quantum key agreement (X25519MLKEM768), which is now enabled by default in recent Chrome, Edge, and Firefox, and in OpenSSL, Go, and recent Apple operating systems. The gap: only about 4% of origin servers can negotiate post-quantum key agreement, though that is an 8x increase since 2023. The browser-to-edge leg is mostly done. The origin leg, and authentication, are not.
If you are reading this in a current browser, your connection to it is very likely already protected by post-quantum key agreement, and nobody asked you to do anything. That is the quiet headline of the last two years: the hardest-to-coordinate part of the transition, getting a new key-exchange algorithm running across billions of clients and the servers they hit, has largely happened on the client-to-edge hop. The numbers are no longer aspirational.
What is actually migrated
Two facts from Cloudflare's measurements make the state of play concrete. First, adoption on the client side is mainstream: around 43% of human connections arrive with X25519MLKEM768, the hybrid that runs classical X25519 and post-quantum ML-KEM-768 together so the exchange is safe if either survives. Second, the algorithm is now a default, not an experiment: it ships on by default across the major browsers and in widely used libraries. When something is the default in the software most traffic flows through, adoption stops being a campaign and becomes the baseline.
Where the line still is
The same report names the unfinished work plainly. Only about 4% of origin servers, the machines behind the CDN where your application actually lives, can negotiate post-quantum key agreement today. So the protected hop is often browser-to-edge, while edge-to-origin, and origin-to-database, and service-to-service inside your own network, are frequently still classical. Harvest-now-decrypt-later does not care which hop is weakest; it collects wherever the ciphertext is capturable. The default fixed the most visible leg and left the private ones to each operator.
And key exchange is only half of TLS. The other half is authentication, the signatures in certificates that prove the server is who it claims to be, and that migration has barely begun in production, because rotating certificate chains and roots is slower and riskier than swapping a key-exchange group. Post-quantum signatures are now landing in platforms (Go 1.27 put ML-DSA in its standard library this month), but the deployed web still authenticates with classical RSA and ECDSA almost everywhere.
The point
The point
Post-quantum key exchange winning the browser is real progress and a useful proof that internet-scale crypto migrations can happen fast when the default moves. It is not the finish line. The protected connection you see is the public hop; the exposure that remains is the private hops, the origins, and every certificate still signed with a classical algorithm.
The practical read: do not let a green padlock and a modern browser convince you the migration is done for you. It is done for one hop. Map the rest, your origins, your internal service mesh, your data-at-rest, and your authentication, and you will find most of your quantum-vulnerable cryptography sitting exactly where the default cannot reach it. That map is a cryptographic inventory, and it is where a serious plan starts.
References
- Cloudflare: State of the post-quantum Internet in 2025 (blog.cloudflare.com) - the 43% figure, browser defaults, and the ~4% of origins.
- Cloudflare: The state of the post-quantum Internet in 2024 (blog.cloudflare.com) - the prior year, for the trend line.
- quantakrypto: post-quantum key exchange in the browser - how X25519MLKEM768 became the default.
- quantakrypto: build a CBOM with qScan - inventorying the hops the default cannot reach.