Post-Quantum Encryption Is Already in Your Browser: What ML-KEM Support in TLS Actually Protects

Most “post-quantum” coverage still talks about it as a future migration — something that will happen once quantum computers get big enough to matter. For browser TLS connections specifically, that framing is already out of date. Chrome turned on a post-quantum-resistant key exchange by default in version 131, in November 2024. Firefox followed with its own default-on hybrid support in version 135, in February 2025. Neither vendor made much noise about it, because for the overwhelming majority of users nothing visibly changed — which is exactly the point, and exactly why it’s worth explaining what actually happens on every HTTPS connection those browsers now make.

What Actually Ships: A Hybrid, Not a Replacement

Browsers didn’t replace their existing key exchange with a post-quantum one; they added a post-quantum algorithm alongside it. Every TLS 1.3 connection already used X25519, a classical elliptic-curve Diffie-Hellman key exchange, to establish the shared secret that encrypts the rest of the session. The new default combines that with ML-KEM — Module-Lattice-Based Key Encapsulation Mechanism, the algorithm NIST standardized as FIPS 203 — run in parallel, so the resulting session key depends on both. If ML-KEM turns out to have an undiscovered weakness, the connection still has X25519’s classical security; if a future quantum computer breaks X25519, the connection still has ML-KEM’s. That hybrid construction, not a wholesale swap, is what “post-quantum TLS” means in practice today, and it’s a deliberate hedge against betting everything on a five-year-old standard.

The Naming Actually Changed Recently, Which Matters for Anyone Debugging TLS

If you’ve looked at a browser’s connection-security panel or a TLS handshake capture any time in the last two years, you may have seen a group name like X25519Kyber768Draft00. That was the pre-standardization codepoint browsers shipped experimentally, built on Kyber, ML-KEM’s pre-NIST-standardization name. The IETF’s finalized specification — the hybrid ECDHE-MLKEM construction, formalized this year — defines the production codepoint as X25519MLKEM768, and IANA has explicitly marked the old draft codepoints as obsoleted by the new standard. The rename isn’t cosmetic: it reflects the difference between an experimental, subject-to-change construction and a specified, standards-track one that server operators and TLS libraries can now target without expecting another breaking rename later. Anyone who hardcoded the old Kyber-named group into TLS configuration, monitoring, or interop tooling needs to account for the new name showing up in negotiated connections.

What This Protects: Confidentiality, Recorded Today

The threat model here has a specific name — harvest now, decrypt later — and a specific limitation worth being precise about. An adversary who is recording encrypted traffic today, betting on a future large-scale quantum computer to break the classical key exchange and decrypt it retroactively, is the exact threat hybrid key exchange defeats: even if X25519 is broken later, the ML-KEM half of the hybrid was never vulnerable to that attack, so the recorded traffic stays unreadable. That protection is retroactive by design — it protects data in transit right now, for however long that data needs to stay confidential, against a decryption capability that doesn’t exist yet.

What This Doesn’t Protect: Authentication Is a Separate, Later Problem

What the hybrid key exchange does not touch is the certificate and signature side of TLS. The certificate your browser validates to confirm it’s actually talking to your bank and not an impersonator still relies on classical signature algorithms — RSA or ECDSA — which are not quantum-resistant. A sufficiently capable quantum computer that can eventually forge those signatures would undermine authentication regardless of how strong the session’s key exchange is; a harvested, hybrid-protected session doesn’t help if the connection was authenticated to the wrong server in the first place. NIST has a separate post-quantum signature standard, ML-DSA, but browser and certificate-authority adoption of post-quantum signatures is meaningfully behind the key-exchange rollout — that migration is still ahead, not behind, and conflating “TLS is post-quantum now” with “the whole handshake is quantum-safe” overstates where the ecosystem actually is.

The Actual Adoption Number, and Why It’s Already Ahead of the Headlines

By late October 2025, Cloudflare reported that a majority of the human-initiated HTTPS traffic crossing its network was already using post-quantum key exchange — a figure driven almost entirely by Chrome, Edge, and Firefox shipping the hybrid default rather than by any site operator having to opt in. That’s the quiet mechanism doing the actual work here: because the protection lives in the browser’s TLS stack rather than in a setting a user or even most site operators have to configure, adoption tracks browser-update cycles instead of the much slower pace of individual server migrations — the same silent-default pattern our Trusted Types coverage noted with Chrome’s earlier rollout of a browser-enforced security primitive that most sites never had to opt into.

Why “Later” Is Still Worth Defending Against Now

The harvest-now-decrypt-later threat model only makes sense for data with a confidentiality window that outlasts the time it takes to build a cryptographically relevant quantum computer — nobody serious is claiming that computer exists yet, and estimates for when one might range widely. But plenty of ordinary browser traffic qualifies anyway: medical records, financial account details, government correspondence, privileged legal communication, and long-lived authentication tokens are all routinely worth protecting for a decade or more, which is well within the range analysts consider plausible for large-scale quantum decryption capability to arrive. An adversary with the resources to record and store bulk encrypted traffic today — the kind of adversary intelligence agencies and nation-state actors are assumed to be — doesn’t need the quantum computer now; they only need the recording now and the computer eventually. Hybrid key exchange closes exactly that window, for exactly the traffic that needs a decade-plus of confidentiality, at effectively zero cost to everyone else’s ordinary browsing.

What to Actually Do With This

For most readers, nothing — the protection is already active and there’s no setting to change. For anyone building or auditing infrastructure, the practical items are narrower than “migrate to post-quantum”: confirm your TLS termination and any strict cipher-suite or key-exchange-group allowlists recognize the current X25519MLKEM768 codepoint rather than only the obsoleted draft name, and treat certificate/signature post-quantum migration as a separate, still-pending project rather than something the key-exchange rollout already solved.

Sources

• Cloudflare — Post-quantum cryptography support
• IETF Datatracker — draft-ietf-tls-ecdhe-mlkem