What is post-quantum TLS?
Post-quantum TLS is HTTPS whose key exchange resists attacks by quantum computers. Today it means a hybrid key exchange, X25519MLKEM768, that combines classic X25519 with ML-KEM, the lattice-based algorithm NIST standardized in 2024 as FIPS 203. The connection stays secure as long as either of the two parts holds.
How this post-quantum test works
The checker sends your server a TLS 1.3 ClientHello that offers X25519MLKEM768 and classic X25519, as Chrome and Firefox do, and reads which key exchange the server picks. If it picks a classic group, a second hello offers only the hybrid group, to tell "supported but not preferred" apart from "not supported". The handshake stops after the server's first reply: nothing is downloaded and no request is made beyond reading the Server header.
| Result | What it means |
|---|---|
| Supported | The server chose X25519MLKEM768. Browsers that offer it get post-quantum protection. |
| Supported, not preferred | The server can do it but prefers X25519 when both are offered. Reorder its group list. |
| Not supported | The server only negotiates classic key exchange. Upgrade its TLS library. |
| Needs TLS 1.3 | The server only speaks TLS 1.2 or older; hybrid key exchange requires TLS 1.3. |
What "harvest now, decrypt later" means
An attacker who records encrypted traffic today can store it and decrypt it years from now, once a large enough quantum computer exists to break the elliptic-curve key exchange that protected it. Nobody knows when that will be, but data such as health records, legal files, credentials and trade secrets stays sensitive for a decade or more. Post-quantum key exchange protects that traffic now, which is why it is being deployed before quantum computers arrive.
How X25519MLKEM768 works
The client sends two public keys in one key share: an ML-KEM-768 encapsulation key (1,184 bytes) and an X25519 key (32 bytes). The server answers with an ML-KEM ciphertext and its own X25519 key. Both sides derive two shared secrets and combine them. An attacker has to break both — classic X25519, which a quantum computer could, and ML-KEM, which it is not known to — so the hybrid is never weaker than today's TLS.
- ML-KEM is the standardized form of CRYSTALS-Kyber (NIST FIPS 203, August 2024).
- TLS code point
0x11EC; the olderX25519Kyber768Draft00(0x6399) has been dropped by browsers. - Only the key exchange changes. Certificates and signatures are untouched.
Which browsers and CDNs support it
| Client or service | Status |
|---|---|
| Chrome, Edge and other Chromium browsers | On by default since Chrome 131 (late 2024) |
| Firefox | On by default since version 132 |
| Safari and Apple platforms | Supported from Apple's 2025 releases (iOS 26 / macOS 26) |
| Cloudflare | On by default for proxied sites; origin connections need your server to support it |
| OpenSSL | 3.5 and newer (April 2025), with X25519MLKEM768 among the default groups |
Go (crypto/tls) | Default since Go 1.24 — Caddy 2.10+ and Traefik built on it get it automatically |
| BoringSSL, AWS-LC | Supported (Google and AWS stacks) |
Most of the web's post-quantum traffic today runs through large CDNs. Self-hosted servers usually need an operating system or package with OpenSSL 3.5.
How to enable it on your server
If the result says "not supported", the checker shows setup for nginx, Apache, Caddy, HAProxy and Cloudflare. In short: run a TLS library that has ML-KEM, then put the hybrid group first.
# nginx with OpenSSL 3.5+
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;
# Check which OpenSSL nginx uses
$ nginx -V 2>&1 | grep -i opensslKeep classic groups after the hybrid one so older clients still connect. After reloading, run the check again; the result should read "Supported".
Does this replace my SSL certificate?
No. Post-quantum key exchange protects the confidentiality of the session and works with your current RSA or ECDSA certificate. Certificates protect authentication, and moving them to post-quantum signatures (ML-DSA, FIPS 204) is a separate, later step: it needs browsers and certificate authorities to agree on formats, which is still in progress. A quantum attacker would have to break a certificate live, during the handshake, so this is less urgent than key exchange. Meanwhile the more immediate certificate change is the move to 47-day certificate lifetimes.
Deadlines: NIST and CNSA 2.0
- NIST IR 8547 (draft, 2024) proposes deprecating quantum-vulnerable RSA and elliptic-curve algorithms by 2030 and disallowing them by 2035 for US federal systems.
- NSA CNSA 2.0 asks for web browsers, servers and cloud services in US national security systems to support and prefer post-quantum algorithms from 2025 and use them exclusively by 2033 (CNSA specifies ML-KEM-1024).
- EU member states agreed a coordinated roadmap in 2025 to begin the transition by 2026 and protect high-risk systems by 2030.
For most websites the practical step today is simply turning on the hybrid key exchange. Check your HTTP security posture next with the security headers checker.