Post-Quantum Encryption Is Already in Your Browser. Here's What Actually Changed

If you opened a browser this morning and loaded a site behind a modern CDN, there is a good chance the session key was derived from a lattice-based KEM standardised by NIST in 2024. No banner, no interstitial, no setting. The key exchange changed underneath you and the padlock looked identical.

This is worth understanding precisely, because the gap between what shipped and what people assume shipped is wide. What shipped is a hybrid key agreement: X25519 combined with ML-KEM-768, standardised for TLS 1.3 as X25519MLKEM768 at code point 0x11EC. What did not ship is post-quantum authentication. Every certificate your browser validated this morning was signed with ECDSA or RSA, and every CA in that chain signs the same way.

So the honest summary is: confidentiality of new sessions got a meaningful upgrade against a future adversary, authentication did not move at all, and a category of infrastructure that quietly assumed small handshakes started falling over. All three of those matter for what you do next.

What ML-KEM actually is, and why it is a KEM and not a Diffie-Hellman

ML-KEM is FIPS 203, published August 2024, derived from CRYSTALS-Kyber. Its hardness assumption is Module Learning With Errors: recovering a secret from noisy linear equations over a polynomial ring. That is a different mathematical world from discrete log or factoring, which is the entire point, because Shor's algorithm eats both of those and has no known equivalent against structured lattices.

The mechanical difference from Diffie-Hellman matters more than people expect. ECDH is symmetric in shape: both parties send a public value, both compute the same secret. A KEM is not. One party publishes an encapsulation key, the other encapsulates a random shared secret against it and sends back a ciphertext. That asymmetry is why the TLS 1.3 integration is clean, but it also means the client and server shares are different sizes, and neither of them is small.

There are three parameter sets. ML-KEM-768 is the one everyone converged on for TLS: it sits at NIST security category 3, and it was chosen over the smaller ML-KEM-512 largely as a hedge against future cryptanalytic improvement rather than because category 1 was demonstrably insufficient. That conservatism is a running theme.

Why hybrid rather than pure post-quantum

Hybrid means the final shared secret is derived from both components concatenated, so an attacker must break both X25519 and ML-KEM to recover it. RFC 10024 specifies exactly this for TLS 1.3, defining X25519MLKEM768 along with SecP256r1MLKEM768 and SecP384r1MLKEM1024 for estates that need NIST curves.

The reasoning is not fence-sitting. ML-KEM is young. It has survived several years of concentrated public analysis, which is genuinely reassuring, but X25519 has survived far longer, and lattice cryptanalysis is an active research area where incremental improvements arrive regularly. Implementation risk compounds this: a fresh, complex algorithm with polynomial arithmetic, rejection sampling and encoding rules is exactly where side channels and decapsulation bugs live. Hybrid means a break in either primitive, mathematical or implementation-level, does not immediately cost you confidentiality.

The cost of hybrid is one X25519 scalar multiplication and 32 extra bytes each way. Against a 1,184-byte ML-KEM encapsulation key, that is rounding error. There was never a serious argument for going pure.

Hybrid means a break in either primitive, mathematical or implementation-level, does not immediately cost you confidentiality.

Harvest now, decrypt later is the only threat model that justifies the timing

No cryptographically relevant quantum computer exists. Deploying anyway is rational for exactly one reason: an adversary who records ciphertext today and stores it can decrypt it whenever the capability arrives. Every session you negotiate with classical-only key exchange is a bet that nothing in it will still matter by then.

This reframes the urgency question usefully. The right thing to ask is not when a quantum computer will exist. It is what your data's confidentiality horizon is. Session cookies expire in hours and nobody cares. Health records, source code, legal discovery material, intelligence traffic, embedded device keys burned into a twenty-year product line, anything covered by a long statutory retention period — those have horizons that plausibly outlast the classical era, and they were exposed the moment they crossed a network.

Note the asymmetry with authentication. Forging a signature requires a quantum computer at the moment of the attack, because you cannot retroactively impersonate a server in a connection that already closed. Breaking confidentiality does not. That is the whole reason key exchange went first and signatures did not.

The right question is not when a quantum computer will exist. It is how long your data needs to stay secret.

The cost is bytes, not cycles

Practitioners expect post-quantum crypto to be computationally expensive. It largely is not. ML-KEM operations are fast — polynomial arithmetic with NTTs, no big-integer modular exponentiation — and on many platforms a full encapsulation is competitive with or faster than an X25519 scalar multiplication. CPU is not your problem.

Bandwidth is. Under RFC 10024, an X25519MLKEM768 client share is 1,216 bytes and the server share is 1,120 bytes, against 32 bytes each for bare X25519. A typical ClientHello that used to sit comfortably in a few hundred bytes now runs past 1,500, which means it no longer fits in a single TCP segment on a standard Ethernet path and arrives as two.

Published telemetry from a large CDN operator, dating from early 2024 when adoption was still around two percent of its TLS 1.3 connections, reported roughly a 15 percent handshake slowdown from adding about 9 KB to a chain, with sharper degradation beyond 10 KB as extra round trips appear. Treat that as one operator's measurement on one network under one traffic mix, not an industry constant — but the shape of the curve is the durable lesson. Handshake size penalties are non-linear, because they are really about round trips and congestion window behaviour rather than raw bytes. This is also why nobody is in a hurry to add multi-kilobyte post-quantum signatures to the same handshake.

What it does not protect

Be exact about the boundary. Hybrid key exchange protects the confidentiality of the session key for that connection. That is the whole guarantee.

It does not cover:

• Certificates and signatures. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) exist, but the WebPKI has not moved, largely because chain sizes would blow past the handshake budget described above. Work on trust anchor negotiation and Merkle tree certificates is aimed squarely at that constraint.
• Data at rest. Symmetric encryption is fine — Grover's algorithm offers only a quadratic speedup and AES-256 remains comfortable. The exposure is the key wrapping around it: RSA or ECC-wrapped data encryption keys in a KMS, encrypted backups, archived S/MIME and PGP mail.
• Anything that is not browser TLS. Service mesh mTLS, IPsec and IKEv2 tunnels, SSH, database driver connections, message brokers, IoT device provisioning, egress proxies. These are where most long-lived sensitive data actually moves.
• Sessions resumed from a pre-upgrade handshake. A resumption ticket inherits the security of the handshake that produced it, so long ticket lifetimes extend classical exposure past the day you enabled the new group.
• Any connection where negotiation quietly fell back. If a hop in the path does not offer the group, you get classical crypto and, by default, no log line saying so.

Where it breaks in practice

The failure modes are all downstream of the same cause: something in the path assumed the ClientHello fits in one packet. That assumption held for two decades and is baked into more code than anyone would like.

TLS-terminating and TLS-inspecting middleboxes are the usual suspects — inspection proxies, some load balancer SNI parsers that read the first segment and give up, older WAF deployments. Symptoms are unhelpful: a connection that hangs rather than resets, or works from the office and not from a mobile network, or fails only for one client population. Because the browser may retry without the post-quantum group, the user often sees an inexplicable delay rather than an error.

QUIC has its own constraints. Initial packets must be padded to at least 1,200 bytes, and servers are held to a three-times amplification limit before address validation, so an oversized client hello spanning multiple Initials interacts with both rules. DTLS needs proper handshake fragmentation. And any path with a reduced MTU — tunnels, PPPoE, some mobile carriers — combined with blocked ICMP gives you a path MTU black hole that shows up as PQ-specific breakage and nothing else.

One more operational trap: if you terminate TLS at an edge that supports the hybrid group but your origin or internal hop does not, the pretty green result in an external scanner tells you nothing about the leg where your data actually travels.

What to check on Monday

This is an inventory problem before it is a cryptography problem, which is exactly what CISA's post-quantum guidance has been saying to federal agencies since before the standards landed. Concretely:

• Log the negotiated group, not the library version. Add the TLS group to your access logs at every termination point and count it for a week. Library support does not mean it is being selected.
• Enumerate every TLS termination hop end to end — CDN, edge LB, WAF, ingress, service mesh sidecar, origin. Test each leg separately with openssl s_client -groups X25519MLKEM768 rather than trusting a public scanner that only sees your front door.
• Verify your stack versions actually carry it. OpenSSL 3.5 and later ship ML-KEM natively; older branches do not, regardless of what the OS vendor backported. Check what your containers really link against, not what the base image claims.
• Test from a hostile network. Corporate inspection proxy, a mobile carrier, a low-MTU VPN. This is where two-segment ClientHellos die, and it will not reproduce from your laptop on the office LAN.
• Shorten session ticket lifetimes during the transition so resumed sessions stop inheriting pre-upgrade key exchange.
• Inventory by confidentiality horizon, not by system criticality. Find the data that must stay secret past 2040 and check what wraps its keys — that list is usually shorter and scarier than people expect.
• Extend the same audit to non-HTTP paths: SSH, IKEv2, replication links, backup agents. NIST IR 8547, the draft transition guidance, is a reasonable structure for staging that work.
• Plan for signatures separately and do not wait on them. Cryptographic agility in your certificate tooling — automated issuance, short lifetimes, no pinned algorithm assumptions — is the actual prerequisite, and you can build it now.

Sources and further reading

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3
• NIST IR 8547 (draft): Transition to Post-Quantum Cryptography Standards
• CISA Post-Quantum Cryptography Initiative
• Cloudflare: The state of the post-quantum Internet (handshake size and deployment telemetry)

How this article was produced

Written by Marta Kowalczyk and edited to the Techtrendery.com editorial policy. Figures described as illustrative are exactly that and are labelled in the text. If you find an error, tell us through the contact page — corrections are published in place with a dated note.