A website is post-quantum ready, for the part that matters most today, when its server can agree on session keys using a hybrid post-quantum key exchange. The most widely deployed option is X25519MLKEM768, which combines classical X25519 with ML-KEM-768, the key encapsulation mechanism standardized by NIST in FIPS 203. It is registered by IANA as TLS group 0x11EC and is the only post-quantum group IANA marks as recommended.
Why the key exchange first? Because of harvest now, decrypt later: an attacker can record encrypted traffic today and decrypt it once a large quantum computer exists. Only the key exchange protects recorded traffic. Certificates and signatures matter too, but a forged signature has to be forged in real time, so they can migrate later.
Method 1: an online scan
The quickest way is to enter the domain in the PQC Status scanner. It offers each standardized post-quantum group to the server one by one and reports which ones are accepted, which group a modern browser actually gets, the TLS versions and cipher suites, and the certificate chain. It takes a few seconds and needs no access to the server.
Method 2: one OpenSSL command
With OpenSSL 3.5 or later (check with openssl version), offer only the hybrid group. If the server supports it, the handshake succeeds; if not, it fails:
openssl s_client -connect example.com:443 -servername example.com \
-groups X25519MLKEM768 -brief </dev/nullA post-quantum ready server answers with a line such as:
Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768A server that only supports classical groups ends the handshake with an alert, typically ssl/tls alert handshake failure (alert number 40). Note that s_client exits with status 0 in both cases: read the output, not the exit code.
To test the other hybrid groups, replace the group name with SecP256r1MLKEM768 or SecP384r1MLKEM1024. The latter is the level 5 option that ANSSI prefers where possible.
Method 3: the browser
Current versions of Chrome, Edge and Firefox offer X25519MLKEM768 by default. In Chromium-based browsers, open the developer tools, go to the Security panel and look at the connection details: the key exchange line names the group that was negotiated. This shows what your own browser got, which is useful for a quick check but depends on the browser version.
Reading the result correctly
A CDN can hide your origin
If your site is behind Cloudflare, Fastly, CloudFront or another CDN, every external test sees the edge, not your server. Many CDNs enable hybrid key exchange by default at the edge, so the site looks ready. The connection from the CDN to your origin server is a separate TLS link that may still use classical key exchange only. Test the origin directly, from a machine allowed to reach it, with the OpenSSL command above.
TLS 1.3 is a prerequisite
Hybrid key exchange exists only in TLS 1.3. A server limited to TLS 1.2 cannot be post-quantum ready, whatever its certificate. The US OMB memorandum M-26-15 also requires TLS 1.3 for federal systems by January 2030.
Classical certificates are normal today
Your certificate almost certainly uses RSA or ECDSA. That is expected: public certificate authorities do not issue post-quantum certificates for the web yet. Record the certificate algorithm in your inventory, but do not treat it as a blocker for the key exchange step.
Old Kyber drafts do not count
Some early deployments used X25519Kyber768Draft00, a pre-standard version of the algorithm. It is obsolete: servers should move to the standardized ML-KEM groups.
What to do if the answer is no
- Check the TLS library: OpenSSL 3.5 or later, or an equivalent library with ML-KEM support.
- Enable the hybrid group in your web server or load balancer, keeping X25519 as a fallback. Our guide to enable ML-KEM on nginx, Apache, HAProxy and Caddy has the exact directives.
- Re-run the test, then add the result to your cryptographic inventory with the date.