You can test whether any website's TLS connection is protected against future quantum computers in about ten seconds, for free, without signing up for anything. Enter a domain into the QNSQY PQC checker, and it performs one real TLS handshake against that server and tells you whether the key exchange used post-quantum cryptography. This post explains what the checker actually measures, how the grade is assigned, and what to do with the result.
Why "quantum-ready" is a question about today, not 2035
The attack that makes this urgent is called harvest now, decrypt later: an adversary records your encrypted traffic today and stores it until a cryptographically relevant quantum computer can break the key exchange that protected it. Anything sensitive with a long shelf life, patient records, financial data, legal files, state secrets, is already exposed if it crosses the wire under classical key exchange. That is why the question "is this site quantum-ready" matters now, while the quantum computer itself is still in the future.
The defense is post-quantum key exchange in TLS. In practice that means a hybrid handshake: the classical X25519 curve combined with ML-KEM, the lattice-based key encapsulation mechanism NIST standardized as FIPS 203. The deployed form is called X25519MLKEM768. Google, Cloudflare, and Wikipedia already negotiate it with modern browsers.
What the checker does
The PQC checker performs a single, real TLS handshake against the domain you enter, exactly the way a browser would connect. It then reports:
- whether the server negotiated hybrid post-quantum key exchange (X25519MLKEM768),
- which TLS version the server offered,
- a letter grade with the reasoning spelled out.
No signup, no email gate, no scan queue. One handshake, an answer in seconds, results cached for one hour.
The grades, exactly as assigned
- Grade A, Quantum-Ready: the server negotiates hybrid post-quantum key exchange. Traffic recorded today cannot be retroactively decrypted by a future quantum computer.
- Grade C, Modern but classical: TLS 1.3, but classical key exchange only. Fine against today's attackers; recorded traffic is exposed to future quantum decryption. The fix is usually one server or CDN configuration change.
- Grade F, Legacy: no TLS 1.3 at all. Post-quantum key exchange requires TLS 1.3, so this needs attention regardless of the quantum timeline.
What the grade deliberately does not cover
Honest tools state their limits. The checker measures the key exchange of the one endpoint it probes, because key exchange is what harvest-now-decrypt-later attacks. It does not measure:
- Certificate signatures. These are still classical across essentially the whole web today; post-quantum certificates are years behind post-quantum key exchange, and that is an ecosystem problem, not a per-site failure.
- Other subdomains or mail servers. Each endpoint negotiates its own TLS.
- Your data at rest. Files, backups, and archives encrypted with classical cryptography have the same harvest-now-decrypt-later exposure as your traffic, and no TLS upgrade fixes that.
If you got a C: the one-change fix
Most C grades are a configuration flag away from an A. If your site sits behind a major CDN or load balancer, enabling post-quantum key exchange is typically a checkbox or a TLS-policy update; modern browsers already support it, so there is nothing to roll out client-side. If you terminate TLS yourself, upgrade to a TLS library version that supports X25519MLKEM768 and enable the group. Then re-run the checker to confirm the A.
If you got an A: your traffic is covered, your storage is not
An A grade means your TLS traffic in transit is protected. The same quantum threat applies to data at rest: everything encrypted with RSA or classical-only tooling and then archived is harvestable today. That migration is the harder half of quantum readiness, and it is the half QNSQY exists for: scanning storage for classical cryptography and re-encrypting it with NIST-standardized post-quantum algorithms (ML-KEM key encapsulation, ML-DSA signatures), hybrid by default. Diagnosis is the checker; the sample report shows what the full picture looks like.
Frequently Asked Questions
How do I check if a website is quantum-ready?
Enter the domain into a post-quantum TLS checker such as the free QNSQY PQC checker at quantumsequrity.com/pqc-check. It performs one real TLS handshake and reports whether the server negotiated hybrid post-quantum key exchange (X25519MLKEM768), with an A, C, or F grade and the reasoning shown.
What does X25519MLKEM768 mean?
It is the hybrid TLS key-exchange group that combines the classical X25519 elliptic curve with ML-KEM-768, the lattice-based mechanism standardized in NIST FIPS 203. Both must be broken to recover the session key, so the connection stays secure even if one assumption falls to a future quantum computer.
Is a quantum-ready website fully protected against quantum computers?
No. A quantum-ready TLS handshake protects traffic in transit against harvest-now-decrypt-later attacks. Certificate signatures across the web remain classical for now, and data at rest, meaning files, backups, and archives, needs its own post-quantum encryption migration separately from anything TLS does.
Does checking a website for post-quantum TLS cost anything?
No. The QNSQY PQC checker is free, requires no account or email, and runs a single TLS handshake against the domain you enter. Results return in seconds and are cached for one hour. Disagree with a grade? The rubric is published, and corrections are invited at [email protected].