Is Your TLS Quantum-Safe? How to Test Your Website's Encryption

Your website's TLS is quantum-safe if its key exchange negotiates a post-quantum (hybrid) group such as X25519MLKEM768. If your handshake still settles on a classical group like X25519 or secp256r1 alone, the session is vulnerable to "harvest now, decrypt later" attacks. Here is exactly how to check, what the result means, and how to fix a poor grade.

How TLS 1.3 Key Exchange Actually Works

Every HTTPS connection starts with a handshake. In TLS 1.3, the client and server agree on a shared secret using an ephemeral key exchange — most commonly Elliptic Curve Diffie-Hellman (ECDHE). The client offers a list of supported named groups (sometimes called "supported groups" or curves), and the server picks one. That chosen group is what protects the secret both sides derive.

Once the shared secret exists, it is fed into a key-derivation function and used to key a symmetric cipher — typically AES-256-GCM or ChaCha20-Poly1305. From that point on, your actual page data is encrypted symmetrically.

This two-part structure matters because quantum computers do not threaten both halves equally.

Which Part Is Quantum-Vulnerable

The vulnerable part is the asymmetric key exchange — the named group. Classical groups like X25519, secp256r1 (P-256), and secp384r1 rely on the hardness of the elliptic-curve discrete logarithm problem. A sufficiently large quantum computer running Shor's algorithm can solve that problem efficiently, recovering the private key and therefore the shared secret.

The symmetric cipher is a different story. The best known quantum attack on AES is Grover's algorithm, which only provides a quadratic speedup. In practice that halves the effective key strength: AES-256 drops to roughly 128 bits of quantum security, which is still comfortably out of reach. So AES-256 stays safe, and the symmetric layer is only mildly affected.

The takeaway: when people ask "is my TLS quantum-safe," they are really asking about the key exchange group, not the cipher.

Why "Harvest Now, Decrypt Later" Makes This Urgent

An attacker does not need a quantum computer today. They can record your encrypted traffic now and store it. If the key exchange used a classical group, a future quantum computer can crack the recorded handshake and decrypt the entire captured session retroactively. Any data with a long confidentiality lifetime — health records, legal documents, credentials, financial data — is already at risk the moment it crosses a classically protected connection.

What a Quantum-Safe Handshake Looks Like

A quantum-safe TLS 1.3 handshake negotiates a hybrid named group. The most widely deployed today is:

X25519MLKEM768

Reading the name left to right tells you exactly what it does:

• X25519 — the classical Elliptic Curve Diffie-Hellman exchange we already trust.
• MLKEM768 — ML-KEM (Module-Lattice Key Encapsulation Mechanism, standardized as NIST FIPS 203, formerly "Kyber") at the 768 parameter set.

The handshake runs both and combines their outputs into the final shared secret. An attacker has to break both X25519 and ML-KEM-768 to recover the secret. That hybrid design is deliberate: you keep the battle-tested classical security in case a flaw is found in the newer lattice scheme, while gaining quantum resistance from ML-KEM. This is why the security community recommends hybrids over pure post-quantum groups during the transition.

If your server negotiates X25519MLKEM768, your key exchange is quantum-safe.

How to Test It Yourself with OpenSSL

You can check any public site directly from your terminal. The catch: your local OpenSSL build must be version 3.5 or newer to support X25519MLKEM768. Check first:

openssl version

If that prints OpenSSL 3.5.0 or higher, you are ready. Many systems still ship 3.0–3.4, which cannot negotiate the hybrid group at all — so a "failure" there may just be your client, not the server.

Now run a handshake that requests only the hybrid group:

openssl s_client -connect example.com:443 -groups X25519MLKEM768

By restricting -groups to X25519MLKEM768, you force the question: will the server accept it? Scroll through the output for the line that reports the negotiated group:

Negotiated TLS1.3 group: X25519MLKEM768

If you see Negotiated TLS1.3 group: X25519MLKEM768, the server supports post-quantum key exchange — you are quantum-safe. If the connection fails with a handshake error such as no shared group (alert number 40 / handshake failure), the server does not yet support the hybrid group and is falling back to classical-only key exchange.

To confirm what the server normally negotiates with a typical browser, run it once without forcing the group:

openssl s_client -connect example.com:443

and read the same Negotiated TLS1.3 group line. A modern browser like Chrome already offers X25519MLKEM768 by default, so this reflects what real visitors get.

Reading the Results at a Glance

A couple of common gotchas worth knowing. First, if openssl version is below 3.5, the test is inconclusive — fix your client before judging the server. Second, a load balancer, CDN, or reverse proxy usually terminates TLS for you, so the result reflects that edge, not your origin server. If you front your site with a CDN, test the public hostname your visitors actually hit.

The Easier Path: An Automated Grade

Driving OpenSSL by hand is great for one host, but it is slow, version-dependent, and easy to misread. If you just want a clear answer, run an automated check instead.

Secuur's free Readiness Scan performs a real TLS handshake against your domain — not a database lookup or a guess — and returns a plain A–F grade in about 20 seconds, with no signup required. It tells you which named group your server negotiated, whether a post-quantum hybrid is available, and where your configuration falls short.

You can run a free quantum-risk scan on your domain right now, or open the full Readiness Scan to see the detailed breakdown. It is the fastest way to get a defensible answer without wrangling OpenSSL versions.

What to Do If Your Grade Is Poor

A low grade is not a crisis — it is a to-do list. Work through these in order:

1. Confirm where TLS terminates. Identify whether your origin server, a reverse proxy (nginx, Caddy, HAProxy), or a CDN handles the handshake. That is the component you need to upgrade.
2. Upgrade the TLS stack. Post-quantum hybrids require recent libraries — OpenSSL 3.5+, BoringSSL, or a current nginx/Caddy build linked against them. Caddy and Cloudflare-fronted sites often get X25519MLKEM768 support simply by updating.
3. Enable the hybrid group in your config. Add X25519MLKEM768 to your server's accepted curves/groups list, ideally as the preferred option, while keeping classical groups for older clients.
4. Re-test. Re-run the OpenSSL command or the Readiness Scan to confirm the server now negotiates the hybrid group.
5. Plan for the rest of your stack. Web TLS is the most visible surface, but VPNs, internal service mesh, email transport, and stored data all need the same treatment. Start with public HTTPS, then expand.

If you want the full strategic picture — algorithms, timelines, and a migration roadmap — read our post-quantum cryptography guide.

Frequently Asked Questions

How do I know if my website uses post-quantum encryption?

Check which TLS 1.3 named group your server negotiates. Run openssl s_client -connect yourdomain.com:443 (with OpenSSL 3.5 or newer) and look at the Negotiated TLS1.3 group line. If it reads X25519MLKEM768, you are using post-quantum hybrid key exchange. If it shows a classical group like X25519 or secp256r1 on its own, you are not. The fastest no-tools option is to run a free Readiness Scan, which returns an A–F grade in about 20 seconds.

What is X25519MLKEM768?

It is a hybrid TLS key exchange group that combines two algorithms: X25519, the classical elliptic-curve Diffie-Hellman exchange, and ML-KEM-768, the NIST-standardized lattice-based key encapsulation mechanism (FIPS 203, formerly Kyber). Both run during the handshake and their outputs are merged into the shared secret, so an attacker must break both — including the quantum-resistant ML-KEM — to compromise the connection. It is currently the most widely deployed quantum-safe TLS group.

Does TLS 1.3 mean I'm quantum-safe?

No, not automatically. TLS 1.3 is the modern, secure protocol version, but on its own it typically uses classical key exchange groups like X25519 or secp256r1, which a quantum computer running Shor's algorithm can break. You are only quantum-safe when TLS 1.3 negotiates a post-quantum hybrid group such as X25519MLKEM768. The protocol version and the key exchange group are two separate things — check the group, not just the version.

Is AES-256 broken by quantum computers?

No. The only relevant quantum attack on AES is Grover's algorithm, which provides a quadratic speedup. That effectively halves the security level, so AES-256 retains roughly 128 bits of quantum strength — still far beyond any feasible attack. The quantum threat to TLS lives in the asymmetric key exchange, not the symmetric cipher, which is why fixing the named group matters far more than changing your cipher.

Why can't my OpenSSL command negotiate X25519MLKEM768?

Almost always because your local OpenSSL is older than 3.5. Support for the X25519MLKEM768 group landed in OpenSSL 3.5, so versions 3.0 through 3.4 cannot offer it and the test will appear to fail even against a server that supports it. Run openssl version to confirm, and upgrade if needed before judging the server's result. If you would rather skip the version juggling, use the Readiness Scan, which performs the handshake server-side.

---

The Readiness Scan and the quantum-safe migration tooling described here are products of Triple Seven Solutions LLC.