TLS Studio
Post-quantum TLS test
Does your server negotiate quantum-safe key exchange? This pins real TLS 1.3 handshakes to each ML-KEM group — including X25519MLKEM768, the one browsers offer by default — and tells you whether recorded traffic would survive a quantum computer.
Why this matters now, not in ten years
A quantum computer big enough to break today's key exchange doesn't exist yet — but encrypted traffic can be recorded now and decrypted later, once one does. That attack has a name, "harvest now, decrypt later", and it is why the migration is already well under way: Chrome has offered hybrid post-quantum key exchange by default since April 2024, and OpenSSL 3.5 negotiates it out of the box. If your server supports it, every modern browser connection to you is already quantum-safe. If it doesn't, everything you serve is being encrypted with maths that has a countdown attached. Our plain-English guide covers the threat model.
What this test checks
Each probe pins the TLS 1.3 ClientHello to exactly one key-exchange group — the hybrid ML-KEM groups (X25519MLKEM768 and the P-256/P-384 variants) and the pure ML-KEM ones — so a successful handshake proves the server negotiates that group, not just that it speaks TLS. The one that counts is X25519MLKEM768: it is what Chrome, Firefox, Safari and Edge actually offer. We also read the certificate's signature algorithm for context, but a classical certificate is normal — no public CA issues post-quantum certificates yet — so it never affects the verdict.
Not quantum-safe? It's usually one upgrade away
If your site sits behind Cloudflare, Fastly, or a recent nginx/OpenSSL 3.5 stack, post-quantum key exchange is either already on or a configuration flag away — see how to enable post-quantum TLS. While you're here, check the rest of the protocol layer with the TLS version scanner, or run the full domain report.