Etoolio

Post-Quantum Readiness Checker

Free post-quantum readiness checker. Runs a live TLS handshake against any domain to see if it negotiates post-quantum key exchange (X25519MLKEM768), protecting against harvest-now, decrypt-later attacks.

Try:

Is your site ready for the quantum threat?

Large quantum computers will eventually break the classical key exchange (X25519, RSA, ECDH) that protects almost all HTTPS traffic today. The danger isn't only in the future: attackers can record your encrypted traffic now and simply wait to decrypt it once the hardware exists. This is called "harvest now, decrypt later". The defence is post-quantum key exchange, and this free tool runs a live TLS handshake against any domain to tell you whether it's protected.

How the check works

  • It's a real probe, not a guess. Our server opens a genuine TLS 1.3 connection to the domain and offers only the post-quantum hybrid group X25519MLKEM768.
  • Success proves it. Because that group is the only one offered, a completed handshake means the server actually chose post-quantum key exchange, so the site is ready.
  • Failure means not yet. If the server can't do post-quantum, the handshake fails and we report "not yet", along with the TLS version, cipher, classical key exchange and certificate details we did see.

What the results mean

  • Post-quantum ready: the site negotiated X25519MLKEM768, a hybrid of classical X25519 and ML-KEM-768 (NIST's FIPS 203 standard). Recorded traffic is safe from future quantum decryption. This is what Chrome, Cloudflare, Apple iMessage and Signal have deployed.
  • Not yet post-quantum: the site uses modern TLS 1.3 but a classical-only key exchange. It's secure against today's computers, but recorded sessions could in theory be decrypted by a future quantum computer. Most of the web is still here.
  • No TLS 1.3: post-quantum key exchange requires TLS 1.3, so the site can't support it until TLS 1.3 is enabled.

How to become post-quantum ready

  • Use a CDN that supports it. Cloudflare enables post-quantum key exchange by default for most zones, so putting your site behind it is the fastest route. Other providers are following.
  • Upgrade your origin's TLS library. OpenSSL 3.5+ and BoringSSL support ML-KEM; pair them with a recent nginx, Caddy or similar.
  • Enable TLS 1.3 first, since post-quantum key exchange only works over TLS 1.3.

Good to know

  • Post-quantum support can vary by CDN edge and region and is rolling out quickly, so a domain may be ready from one location and not another. This tool reports what our server negotiated at the moment you checked.
  • This is an informational readiness check, not a full TLS or security audit, and not security advice. For a complete assessment, use a dedicated TLS scanner and consult a professional.
  • Post-quantum here refers to key exchange (protecting confidentiality). Post-quantum signatures, which protect against forged certificates, are a separate, later rollout.

Good to know

Post-Quantum Readiness Checker, frequently asked questions

What does the post-quantum readiness checker do?

It runs a live TLS handshake against the domain you enter and offers a post-quantum key exchange (the ML-KEM hybrid group X25519MLKEM768). If the server completes the handshake with that group, it's post-quantum ready; if it refuses, it isn't yet. You also get the site's TLS version, cipher, classical key exchange, certificate issuer and CDN.

What is 'harvest now, decrypt later'?

It's the threat that drives post-quantum urgency. An attacker records your encrypted traffic today and stores it, waiting for a future quantum computer powerful enough to break the classical key exchange (like X25519 or RSA) that protected it. Post-quantum key exchange with ML-KEM makes those recordings useless, because a quantum computer can't derive the session key even later.

What is ML-KEM and X25519MLKEM768?

ML-KEM (Module-Lattice Key Encapsulation Mechanism) is the post-quantum key exchange algorithm standardised by NIST as FIPS 203, based on CRYSTALS-Kyber. X25519MLKEM768 is a 'hybrid' TLS group that combines classical X25519 with ML-KEM-768, so you're protected even if one of the two is later broken. It's the group Chrome, Cloudflare and Google use.

How does the check actually work?

Our server opens a real TLS 1.3 connection to the domain, offering only the ML-KEM hybrid group in the handshake. Because it's the only group offered, a successful handshake proves the server chose it, so the site is post-quantum ready. If the server can't do post-quantum, the handshake fails and we report 'not yet'. It's a genuine probe, not a guess from headers.

My site isn't post-quantum ready. How do I fix it?

Post-quantum needs support wherever your TLS terminates. The easiest path is a CDN that supports it, Cloudflare enables post-quantum by default for most zones. On your own origin, use OpenSSL 3.5+ or BoringSSL with a recent nginx, Caddy or similar. It also requires TLS 1.3, so enable that first.

Why might the result differ from another tool?

Post-quantum support can vary by CDN edge, region and configuration, and it's rolling out fast, so a domain can be ready from one location and not another. This tool reports what our server negotiated at the moment you checked. For your own domain, confirm the setting in your CDN or server config.

Is this a security audit?

No. It's an informational readiness check focused on post-quantum key exchange and a few related TLS facts. It's not a full TLS or security audit, and it's not security advice. For a complete assessment, use a dedicated TLS scanner and consult a security professional.

Is it free?

Yes, free with no signup. It performs a live TLS handshake from our server against the public domain you enter.