TL;DR: State-level adversaries are recording encrypted internet traffic today, betting that a future quantum computer will let them decrypt it 10-30 years from now. Post-quantum key exchange — the X25519MLKEM768 hybrid that Chrome and Cloudflare turned on in 2024 — defuses that bet. The classical half (X25519) protects you against today’s threats; the post-quantum half (ML-KEM-768) protects you against a quantum computer that doesn’t exist yet but probably will. Most servers don’t pass this in 2026; the ones that do are meaningfully ahead.

What is it?

Every TLS connection starts with a key exchange: the browser and server agree on a fresh, per-session encryption key that nobody listening on the wire can recover. Modern TLS uses an ephemeral key exchange so each session gets its own key — that’s forward secrecy, and it’s what stops a future leak of your server’s long-term private key from retroactively unlocking old recorded sessions.

The math behind today’s classical key exchanges (X25519, ECDHE) leans on a single hardness assumption: that solving the elliptic-curve discrete-logarithm problem is computationally infeasible. That assumption holds beautifully against classical computers — even with infinite budget, the best known attack would take longer than the age of the universe.

It does not hold against a sufficiently large quantum computer. Shor’s algorithm, published in 1994, solves the discrete-log problem in polynomial time on a quantum machine. No quantum computer big enough to run Shor against a real X25519 key exists today. Most researchers think one will exist somewhere between 2035 and 2050. The ones who think it’ll be sooner are not crackpots.

Post-quantum key exchange uses different math — specifically lattice-based cryptography, which leans on the hardness of the “learning with errors” problem. That problem is conjectured to be hard for both classical and quantum computers. ML-KEM (Module-Lattice Key Encapsulation Mechanism, originally proposed under the name Kyber) is the first PQ key-exchange algorithm to clear NIST’s multi-year vetting process. NIST published it as FIPS 203 in August 2024.

X25519MLKEM768 is the IETF name for the specific hybrid we measure: classical X25519 alongside the 768-bit security parameter of ML-KEM, combined into a single TLS 1.3 key share.

Why “hybrid”?

You might reasonably ask: if ML-KEM is the new hotness, why not just use ML-KEM by itself?

Two reasons.

ML-KEM is young. It cleared NIST’s competitive process in 2024 after roughly eight years of public scrutiny — which is impressive but not the multi-decade beating that classical curve algorithms have taken. If a researcher publishes a structural break against ML-KEM next year (it’s happened to other lattice schemes — NTRU Prime had parameter adjustments late in the process; SIKE was broken outright in 2022 after years as a finalist), pure ML-KEM deployments are toast. Hybrid deployments still have X25519 holding the line.

Quantum computers don’t exist yet. If you went pure-PQ today and ML-KEM turned out to be subtly weak, you’d have downgraded yourself versus the classical baseline that’s protected the web for 20+ years. With a hybrid, the worst case is that one half is broken and the other half holds — belt and suspenders. The session key is derived from both halves, so an attacker has to break both to recover it.

The trade-off is roughly 1.1 KB of extra handshake bytes (ML-KEM-768 key shares are large compared to a 32-byte X25519 key). On modern links that’s invisible. On flaky cellular it’s measurable but nowhere near a deal-breaker.

Why does it matter?

The threat model is harvest now, decrypt later (HNDL).

A passive adversary — typically assumed to be a state-level signals intelligence agency, but in principle any well-funded organisation with a fibre tap or a cooperative ISP — records gigabytes of encrypted TLS traffic today, stores it on cheap disk, and waits. They don’t need to decrypt it now. They need it to still be valuable when, in 10 to 30 years, a cryptographically-relevant quantum computer comes online and they can run Shor against the recorded key exchange to recover the session keys.

Plenty of traffic today is still going to matter in 2040. Health records. Trade secrets. Intelligence sources. Diplomatic cables. Source code for products with multi-decade lifecycles. Any of it captured pre-PQ is sitting in a freezer waiting for the decryption date.

Post-quantum key exchange shuts the freezer down. Even if the adversary has perfect recordings of every byte that crossed the wire, and even if they eventually build the quantum computer, they cannot recover the session key — because ML-KEM-768 is conjectured to resist quantum attack, and the X25519 half doesn’t matter to them once they have the quantum machine. The session stays sealed.

This is why Chrome enabled X25519MLKEM768 by default in 2024 and why Cloudflare deployed it across every free-tier zone in March 2024. The window to retrofit PQ before HNDL becomes a real loss is finite. The work has to happen before the quantum computer exists, not after.

Real-world analogy

Imagine the locks on your house today. They’re great against human burglars — picks, bumps, brute force. They are useless against a hypothetical robot burglar that hasn’t been built yet but probably will be in 15 years. The robot will read your lock instantly.

Post-quantum hybrid is bolting a second, unfamiliar lock onto your front door — a lock that the robot’s designers haven’t figured out how to defeat. You keep the original lock too, because the robot doesn’t exist yet and the human burglars do. Even if the robot never arrives, you didn’t lose anything except the cost of a second lock. If it does, you’re already fine.

The crucial detail of HNDL: the robot doesn’t have to break in today. The burglars are quietly photographing your door from across the street, every day, for years. When the robot ships in 2040, they’ll feed it those photos and the robot will tell them exactly how the lock worked back in 2026. By then the lock has been on the door for fifteen years and the photos are still useful.

That’s why the second lock has to go on now, not later.

A note on what PQ doesn’t fix yet

Key exchange is one piece of TLS. The other piece — and the one that isn’t post-quantum yet — is signatures.

Every TLS connection involves at least two signatures:

  • Your CA’s signature on your certificate (when Let’s Encrypt issues you a cert, they sign it with their RSA or ECDSA key).
  • Your server’s signature on the handshake transcript in TLS 1.3 (proves to the client that the entity holding the cert’s private key actually participated in this handshake, not a recorded one).

Both of those signatures are still classical. RSA falls to Shor. ECDSA falls to Shor. So a sufficiently-quantum adversary observing a live handshake (not a recorded one) could in principle forge the signatures and impersonate your server.

There’s an asymmetry, though, and it’s the reason key exchange went first: signatures don’t have a harvest-now problem. A signature only has to be unforgeable at the moment it’s verified. Once the TLS session ends, the signature has done its job — a future quantum computer that forges it next decade can’t retroactively MITM a handshake that already completed.

Key exchange does have a harvest-now problem. A session key that encrypts your traffic today still needs to be unrecoverable in 2040, because the ciphertext is sitting on a tape somewhere.

So the migration order is rational: PQ key exchange first (urgent), PQ signatures later (when there’s actually a quantum computer to defend against). NIST has standardised the PQ signature side too — ML-DSA, formerly Dilithium, in FIPS 204 — but cert-side deployment is still years away, because every CA, every OS root store, and every TLS implementation has to support the new signature algorithms before the ecosystem can switch over.

How WQI measures this

We grade post-quantum key exchange as factor WEBQ-94 in the Security category. The signal is the negotiated keyExchange string from the TLS handshake itself — we check whether it matches known PQ-hybrid names: X25519MLKEM768, X25519Kyber768Draft00, or anything else with MLKEM, Kyber, or Hybrid in the identifier.

ResultWhat it means
Pass (100)Post-quantum hybrid negotiated on the test handshake.
Warn (60)Classical-only key exchange on TLS 1.3 — the server doesn’t advertise PQ support yet.
n/aTLS < 1.3. PQ key shares live in TLS 1.3’s supported_groups extension; pre-1.3 protocols don’t carry them.

The n/a tier matters: if your server only supports TLS 1.2, this factor doesn’t apply and doesn’t drag your score down. The TLS minimum version factor catches that separately.

What good looks like

Pass on WEBQ-94 when the client supports PQ. That’s the bar.

In April 2026, most servers will not pass — and that’s expected. PQ key exchange is too new for stable distro packages, and it requires either Cloudflare-class infrastructure or a specifically-built OpenSSL/BoringSSL. The factor exists to flag the meaningfully-ahead sites, not to punish the long tail.

If you are passing this factor, you’re ahead of roughly 99% of the public web on the harvest-now-decrypt-later defence. That’s a real posture difference that very few audit tools surface today — SSL Labs does not grade PQ at all as of this writing.

How to fix it

Cloudflare-fronted (the easy path). Already done. Cloudflare’s edge has been negotiating X25519MLKEM768 with capable clients since March 2024 across every plan tier including free. If your origin sits behind Cloudflare’s orange cloud, you pass this factor automatically — no config required, no cert change, no origin work.

Self-hosted, modern stack. You need a TLS library with PQ support compiled in:

  • BoringSSL — has had X25519Kyber768Draft00 and now X25519MLKEM768 for a while. Used by Chromium, Envoy, gRPC. If you’re already on Envoy or a BoringSSL-linked nginx fork, you’re one config flag away.
  • OpenSSL 3.5+ — added experimental PQ key exchange support. Not yet in stable distro packages on Debian, Ubuntu LTS, RHEL, or Amazon Linux as of April 2026. If you build OpenSSL from source, you can opt in.
  • LibreSSL — no PQ support yet.
  • Stable distro OpenSSL (1.1.x or 3.0.x) — no PQ support. Won’t be backported.

Pragmatic 2026 path. Front your origin with Cloudflare (or any PQ-capable edge — Fastly is rolling it out, AWS CloudFront has preview support). Let the edge handle the client-facing TLS negotiation including PQ. Keep your existing back-end stack unchanged. This gets you to a passing WEBQ-94 score in an afternoon rather than a multi-quarter migration of your TLS termination layer.

Verify by checking the negotiated key exchange:

echo | openssl s_client -connect yourdomain.com:443 \
  -groups X25519MLKEM768 2>/dev/null \
  | grep -E "Server Temp Key|Negotiated"

A PQ-capable server will show X25519MLKEM768 (or the older X25519Kyber768Draft00 on slightly older Cloudflare configs); a classical-only server will fall back to X25519 or fail the handshake outright.

Going further: signature-side PQ and the broader migration

The next chapter of the post-quantum migration is the signature side. ML-DSA (Module-Lattice Digital Signature Algorithm, formerly Dilithium) is the standardised PQ signature in FIPS 204. NIST has also standardised SLH-DSA (a hash-based signature, FIPS 205) as a more conservative backup, and a “fast Falcon” (FN-DSA) is expected as FIPS 206.

Cert-side migration is years away because the ecosystem dependencies are deep:

  • Every CA has to issue PQ-signed certs.
  • Every OS root store has to ship PQ-capable trust anchors.
  • Every TLS library has to verify PQ signatures.
  • Cert sizes go up significantly (ML-DSA-65 signatures are roughly 3.3 KB vs ECDSA’s 64 bytes), which has handshake-size implications on flaky networks.

The IETF working group tracking this migration is pquip (Post- Quantum Use In Protocols). Their output is the best place to watch the timeline.

Further reading