How do I check if a website supports post-quantum TLS?

Open a TLS 1.3 connection that offers only the hybrid group X25519MLKEM768 and see whether the handshake completes. If it does, the server supports post-quantum key exchange; if it answers with a handshake_failure alert, it doesn't. You can do it with OpenSSL 3.5 or newer (openssl s_client -groups X25519MLKEM768), with curl built against OpenSSL 3.5 (--curves X25519MLKEM768), or by opening the site in a current Chrome and reading the key exchange in DevTools → Security. The catch with the browser method is that it shows what your browser negotiated with whatever answered — which is often a CDN, not the site's own server.

My site is behind Cloudflare and shows X25519MLKEM768. Am I done?

Your visitors are protected up to the CDN edge, and that's the half most traffic sees. The other half is the connection from the CDN to your origin server, and you can't see it from outside. Cloudflare reported in September 2026 that about 70% of browser traffic reaching its network used hybrid ML-KEM, but only about 15% of origin servers did on the Cloudflare-to-origin leg. If your origin still runs an OpenSSL older than 3.5 or a Go runtime older than 1.24, that leg is classical key exchange.

Do I need a post-quantum certificate too?

Not yet, and you can't get one from a public CA anyway. Key exchange is the urgent part: it protects traffic that someone records today and tries to decrypt years from now. Signatures only need to resist a quantum computer at the moment of the handshake, so they can follow later. Keep your RSA or ECDSA certificate and switch the key exchange first.

Post-Quantum TLS Check: Is Your Site Using X25519MLKEM768?

Problem

Someone — a security review, a customer questionnaire, a line in a government roadmap — asked whether your site is “post-quantum ready,” and you don’t know how to answer.

The question has a precise answer for a public website: does your server negotiate a hybrid post-quantum key exchange in TLS 1.3? Today that means the group X25519MLKEM768, which combines classical X25519 with ML-KEM (NIST FIPS 203). The IETF standardized it as the recommended hybrid group in RFC 10024 (August 2026), and current Chrome, Firefox and Safari all offer it by default. If your server accepts it, the session key of every connection from a modern browser is protected even against a future quantum computer.

What “post-quantum” changes, and what it doesn’t

It changes the key exchange. The threat is “harvest now, decrypt later”: recorded TLS sessions sitting on a disk until a quantum computer can break X25519 or ECDHE. Hybrid key exchange closes that door, because breaking the session now requires breaking ML-KEM as well.
It doesn’t change your certificate yet. Public CAs don’t issue ML-DSA certificates. Your RSA or ECDSA certificate stays; that’s normal and not a gap you can fix today.
It requires TLS 1.3. Hybrid groups only exist in TLS 1.3. A server stuck on TLS 1.2 can’t get there without upgrading first.
“Hybrid” is the point, not a compromise. If ML-KEM turned out to have a flaw, X25519 still protects the session. That’s why every major deployment uses the hybrid group rather than ML-KEM alone.

Three ways to check

DechoNet Post-Quantum TLS check. It offers only X25519MLKEM768 in a TLS 1.3 handshake from a server running OpenSSL 3.5. A completed handshake means “supported”; a handshake_failure alert means “not supported”; a timeout is reported as inconclusive rather than “no.” It also tells you who answered — your own server, or a CDN edge in front of it — and lists the signature algorithm of each certificate in the chain.
OpenSSL 3.5 or newer from your own machine:
```
openssl s_client -connect example.com:443 -servername example.com -groups X25519MLKEM768 </dev/null
```
If the handshake completes, the server supports it. If you see sslv3 alert handshake failure, it doesn’t. Older OpenSSL builds reject the group name outright — that’s your client, not the server.
A browser. In current Chrome, open DevTools → Security and look at the connection’s key exchange. It’s quick, but it tells you about the edge your browser reached, which may be a CDN.

Reading the result

What you see	What it means	What to do
Ready — the origin server accepts X25519MLKEM768	Recorded traffic is protected end to end on this endpoint	Watch it, so you learn if a config change ever turns it off
Partial (CDN) — the CDN edge accepts it	Visitors → edge is protected; edge → origin is invisible from outside	Check your origin’s TLS stack (below)
Not ready — the hybrid-only handshake was refused	Every session today uses classical key exchange only	Enable it at the CDN and/or origin
Inconclusive	Timeout or reset, no clear answer	Re-run; don’t treat it as “no”

Turning it on

Behind a CDN: most CDNs now offer hybrid key exchange at the edge by default or as a setting. That covers the visitor side. Then look at the origin, because the CDN can only use ML-KEM toward your server if your server supports it.
nginx / Apache with OpenSSL: you need OpenSSL 3.5 or newer linked into the server. Check with nginx -V or openssl version on the box. Then list the hybrid group first:
- nginx: ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
- Apache httpd: SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1
Go services and Caddy: Go 1.24 and later offer X25519MLKEM768 by default, so rebuilding on a current toolchain is usually all it takes.
Managed load balancers: look for a TLS policy that names ML-KEM or “post-quantum” and switch to it.

Keep X25519 in the list after the hybrid group. Clients that don’t speak ML-KEM yet will fall back to it, which is exactly what you want.

Diagnose with DechoNet

Post-Quantum TLS check answers the whole question in one run: hybrid key exchange yes/no, origin vs CDN, TLS version, and the certificate chain’s signature algorithms, scored 0–100. Put the domain under a daily watch from the result to record the day support appears — or disappears after a migration.
SSL Check covers the classical side of the same endpoint: certificate validity, chain, expiry and TLS versions. Fix anything red there first; post-quantum key exchange doesn’t help a site with a broken chain.
HTTP Check confirms the HTTPS endpoint actually serves your site after the change, and that HSTS and the redirects still look right.

Resolution Checklist

Confirm the endpoint negotiates TLS 1.3 — hybrid key exchange doesn’t exist below it.
Test with X25519MLKEM768 as the only offered group (DechoNet, openssl s_client -groups, or curl --curves).
If a CDN answers, enable hybrid key exchange there, then check the origin separately.
On the origin, upgrade to OpenSSL 3.5+ (or Go 1.24+) and put X25519MLKEM768 first in the group list, followed by X25519.
Re-test after the deploy, and set up a watch so a later config change can’t silently remove it.
Leave the certificate alone — no public post-quantum certificates exist yet.

When to Escalate

If enabling the hybrid group makes some clients fail to connect, suspect a middlebox. The hybrid key share makes the ClientHello about a kilobyte larger, and old firewalls or TLS-inspecting proxies that assume a single-packet ClientHello can drop it. That needs a fix in the middlebox, not a rollback of ML-KEM.
If your origin sits behind a managed service you can’t configure (a hosting panel, an appliance), the upgrade path is the vendor’s — ask for their OpenSSL 3.5 or post-quantum TLS policy timeline.
If you need the internal side too — VPNs, databases, service-to-service TLS, code signing — that’s a cryptographic inventory, not an external check. External tests can’t see it. For the schedule driving all of this, see Post-Quantum Migration Timeline.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.