Post-quantum cryptography sounds like a 2030s problem, but one part of it is quietly live right now — on a large and growing share of TLS handshakes in 2026. If your traffic runs through a major CDN, the browser-to-edge leg is probably already using post-quantum key exchange without you doing anything. The leg you actually need to check is the one behind it: edge to origin, which is almost certainly still classical.
Browser-to-edge is done. Edge-to-origin is not.
Hybrid key exchange (X25519 combined with ML-KEM) is on by default in current Chrome and Firefox and across major CDN edges, protecting session keys against a future quantum computer. But the certificate that authenticates the handshake, and the edge-to-origin hop, are usually still classical. Knowing which of your legs is protected is the whole job for now.
The threat is “harvest now, decrypt later”
Nobody has a cryptographically relevant quantum computer today. The reason post-quantum key exchange is already shipping is a subtler threat: an adversary can record encrypted traffic now and decrypt it years later, once such a machine exists. Anything with a long confidentiality shelf-life — credentials, health and financial records, state secrets — is exposed to that patient attack today. That is why the industry is migrating the key-exchange step first, ahead of any actual quantum threat: the traffic being protected now is the traffic worth stealing later.
Symmetric encryption (the bulk cipher, AES-256) is already considered quantum-resistant. The vulnerable part is the public-key key exchange that establishes the session — classically ECDH — and the signatures on certificates. Key exchange is where the migration is happening first because it is where “harvest now, decrypt later” bites.
What is actually deployed in 2026
The most measurable post-quantum deployment lives in the TLS 1.3 key exchange, as a hybrid: a classical elliptic-curve exchange (X25519) combined with a post-quantum algorithm, ML-KEM-768, standardised by NIST. The combined group is called X25519MLKEM768. Current Chrome and Firefox negotiate it by default, and it now covers a large share of TLS 1.3 handshakes globally — measurement studies in early 2026 put roughly half of surveyed domains at partial post-quantum readiness. Major CDN edges have supported hybrid key exchange for years and default to it now.
The word hybrid is doing real work. Combining classical and post-quantum means that if future analysis weakens the new algorithm, the classical half still protects you — and vice versa. It is a deliberate hedge for a transition period, recommended precisely because the post-quantum primitives are new. On the tooling side, OpenSSL 3.5 (April 2025) added native ML-KEM support, so upgrading the library — or terminating TLS somewhere already upgraded — is often the entire job, with no certificate changes involved.
The asymmetry that defines this moment
Here is the subtlety that trips people up. When a browser loads a site over X25519MLKEM768, the session key is post-quantum-secure — but the server certificate that authenticated the handshake is still signed with classical ECDSA or RSA. That asymmetry is the defining feature of 2026 deployment. It is intentional: the trust ecosystem for post-quantum certificate signatures is not ready, so the industry is protecting confidentiality now (against harvest-now-decrypt-later) while leaving authentication classical for the moment. The shortening of certificate lifetimes, incidentally, is part of the same preparation — it builds the crypto-agility that a later signature migration will need.
The practical takeaway: do not buy “post-quantum certificates” for public sites yet. That part of the ecosystem is still forming, and 2027 is the year to watch it. Protecting the key exchange is the win available today.
Which of your legs is protected
If you sit behind a major CDN, your browser-to-edge leg is almost certainly already hybrid — but confirm it rather than assume, with a quick check of the negotiated group in browser dev tools or a TLS scanner. The leg that usually is not protected is edge-to-origin: the hop from the CDN back to your servers. If your origin terminates TLS on an older library, that connection is still purely classical, and it is exactly the hop carrying your data in the clear-of-quantum sense. Upgrading the origin's TLS library to a current release — or fronting it with something newer — closes that gap.
What to actually do now
Three moves, none of them heroic. Confirm your public edge negotiates hybrid key exchange — behind a major CDN it probably does, but verify. Check the edge-to-origin hop and upgrade the origin's TLS stack if it is lagging, since that is the leg most likely still classical. And inventory your public-key cryptography more broadly — not just TLS, but the key-wrapping, backup-encryption and artifact-signing layers — because the longer-horizon migration applies to every keypair, not only the ones in your web handshakes. The key exchange is the part you can lock down today; the rest is a 2027-and-beyond roadmap you want to start mapping now.