Post-Quantum TLS: What Quantum-Safe HTTPS Means in 2026

Post-quantum TLS is HTTPS that stays secure even against an attacker with a large quantum computer. It replaces the math behind today’s key exchange — which a quantum computer could break — with algorithms designed to resist quantum attacks.

This isn’t a far-off research project. As of mid-2026, over 65% of human web traffic through Cloudflare is already post-quantum encrypted, and Chrome, Edge, and Firefox negotiate quantum-safe key exchange by default whenever the server supports it. If you’ve visited Google recently on a modern browser, you’ve almost certainly used post-quantum TLS without noticing.

Why classical TLS is at risk

Today’s TLS relies on two kinds of public-key math:

• Key exchange (ECDHE, using X25519 or P-256) — agrees on a shared secret over an open channel.
• Signatures (RSA, ECDSA) — proves the certificate is authentic.

Both depend on problems that are hard for classical computers — factoring large numbers (RSA) and the elliptic-curve discrete logarithm (ECC). Shor’s algorithm, running on a sufficiently large quantum computer, solves both efficiently. A “cryptographically relevant quantum computer” (CRQC) doesn’t exist yet, but the field is moving fast enough that planning has shifted from “if” to “when.”

Public-key cryptography → explains the underlying math that quantum computers threaten.

”Harvest now, decrypt later” — why this is urgent today

You might think there’s no rush: no quantum computer can break TLS today, so why switch now?

The threat is harvest now, decrypt later (HNDL). An adversary records your encrypted traffic today and stores it. When a quantum computer becomes available — possibly in the 2030s — they decrypt the stored traffic retroactively.

This makes the deadline for key exchange much earlier than the arrival of quantum computers. Any data with a long confidentiality lifetime — health records, financial data, government secrets, source code, credentials — needs quantum-safe encryption now, because the recording is already happening.

Key exchange is urgent. Signatures are less so. You can’t retroactively forge a signature on traffic that already happened — a signature only needs to be quantum-safe before quantum computers exist, not before. This is why the industry deployed post-quantum key exchange first.

The standards: ML-KEM and ML-DSA

In August 2024, NIST published the first finalized post-quantum standards:

ML-KEM (Module-Lattice Key Encapsulation Mechanism) is the one already deployed in TLS. It comes in three sizes: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. ML-KEM-768 is the sweet spot used on the web.

Hybrid key exchange: X25519MLKEM768

Browsers don’t drop classical crypto and switch to pure post-quantum overnight. That would be reckless — ML-KEM is new, and a flaw could break everything. Instead, TLS 1.3 uses a hybrid key exchange that combines a classical and a post-quantum algorithm.

The named group you’ll see in 2026 is X25519MLKEM768:

X25519MLKEM768 = X25519 (classical ECDHE)  +  ML-KEM-768 (post-quantum)

The two shared secrets are concatenated (32 bytes from X25519 + 32 bytes from ML-KEM = a 64-byte combined secret) and fed into the TLS key schedule.

The security guarantee is “secure if either holds.” An attacker has to break both X25519 and ML-KEM-768 to recover the session key. So:

• If ML-KEM-768 turns out to have a flaw → X25519 still protects you (against classical attackers).
• If a quantum computer breaks X25519 → ML-KEM-768 still protects you.

This belt-and-suspenders design is why hybrid is the default everywhere, not pure post-quantum.

Where it slots into the handshake

Hybrid key exchange uses the same TLS 1.3 handshake described in What is TLS 1.3 →. The only difference is the key_share: the ClientHello carries an X25519MLKEM768 key share instead of a plain X25519 one. ML-KEM keys are larger (~1.2 KB vs 32 bytes), so the ClientHello grows by about a kilobyte — usually negligible, though it can occasionally spill across packet boundaries on constrained networks.

It also still gives you forward secrecy →: a fresh key pair per connection, post-quantum edition.

What’s already deployed in 2026

The piece not yet done at scale is post-quantum certificates — signing certificates with ML-DSA instead of RSA/ECDSA. ML-DSA signatures and public keys are far larger (kilobytes vs. ~64 bytes), which bloats the handshake and stresses certificate-chain size limits. Cloudflare plans ML-DSA on origin connections by mid-2026 and is exploring Merkle Tree Certificates to keep the size manageable, targeting full post-quantum (including authentication) by 2029.

How to check if you’re using post-quantum TLS

In the browser

Open any major site in Chrome → DevTools → Security tab → look at the connection details. A post-quantum connection shows a key exchange like X25519MLKEM768 (or X25519Kyber768 on older builds).

With OpenSSL 3.5+

openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 2>/dev/null \
  | grep -i "Negotiated TLS1.3 group"
# Expected: Negotiated TLS1.3 group: X25519MLKEM768

If you get an error or a different group, either your OpenSSL is older than 3.5 or the server doesn’t yet offer post-quantum key exchange.

Check your OpenSSL version

openssl version
# Needs: OpenSSL 3.5+ for native X25519MLKEM768

How to enable it on your server

For most sites the answer is upgrade and don’t disable it — post-quantum hybrid key exchange is enabled automatically once your stack supports it.

Nginx / Apache

Post-quantum key exchange lives in your TLS library, not the web server config. Build or run against OpenSSL 3.5+ (or BoringSSL with ML-KEM). Once linked, X25519MLKEM768 is offered automatically alongside X25519 — no new directive needed. Don’t pin ssl_ecdh_curve to a single classical curve, or you’ll exclude the hybrid group.

Behind a CDN

The simplest path: put your site behind Cloudflare (or another PQC-enabled CDN). The browser-to-edge connection becomes post-quantum immediately, with no changes to your origin. This is how most of that 65% of traffic became quantum-safe — operators didn’t touch their origin servers at all.

Your certificate doesn’t change yet

You do not need a new certificate for post-quantum key exchange. Your existing RSA or ECC certificate works fine — hybrid key exchange protects the session, while the certificate still uses classical signatures for now. Post-quantum certificates (ML-DSA) are a separate, later migration.

Frequently asked questions

Do I need to buy a special “quantum-safe certificate”?

No. Post-quantum key exchange (the urgent part) doesn’t touch your certificate at all — your current RSA/ECC cert keeps working. Anyone selling a “quantum-safe SSL certificate” today is mostly marketing; production post-quantum signatures (ML-DSA) aren’t widely issued by public CAs yet.

Is post-quantum TLS slower?

Barely. ML-KEM-768 is computationally fast — often faster than ECDHE. The main cost is size: the larger key shares add ~1 KB to the handshake, which can cost one extra round trip only on networks with very small packet limits. For nearly all users the difference is unmeasurable.

When will quantum computers actually break RSA?

Nobody knows. Credible estimates range from the early 2030s to “maybe never at scale.” But because of harvest-now-decrypt-later, the deployment deadline for key exchange is already here — which is exactly why browsers and CDNs moved in 2024–2026 rather than waiting.

What about TLS 1.2?

Post-quantum hybrid key exchange is defined for TLS 1.3 only. This is one more reason to enable TLS 1.3 → — it’s the only path to quantum-safe HTTPS. TLS 1.2 will not get post-quantum key exchange.

Is ML-KEM the same as Kyber?

Yes — ML-KEM is the NIST-standardized version of the algorithm formerly called CRYSTALS-Kyber. Older browser builds and tools show Kyber768; standardized deployments use ML-KEM-768. They’re closely related but not bit-for-bit identical, so a final-standard client and a pre-standard server may fail to negotiate. By 2026 the ecosystem has largely moved to the final ML-KEM.

Should I do anything right now?

For a typical website: make sure you’re on TLS 1.3, keep your TLS library current (OpenSSL 3.5+), and consider a PQC-enabled CDN if you handle long-lived sensitive data. That’s enough to get quantum-safe key exchange today. Post-quantum certificates can wait for the standards and CA tooling to mature.