Post-Quantum TLS Check
Does a site's TLS support post-quantum hybrid key exchange (X25519MLKEM768)? See whether its server or a CDN provides it, and how its certificates are signed.
Detected
What this check can and cannot see
It looks only at the public TLS endpoint on port 443: key exchange, protocol version and certificate signatures. Internal networks, databases, VPNs, application code and firmware are invisible from outside, so treat the result as an external indicator of migration progress, not as a full post-quantum audit.
Pro Watch the migration, not just today
Post-quantum support changes when a CDN, load balancer or server is upgraded. A DechoNet watch re-checks every day and records the day it changes.
Learn about monitoring →Related Guides
What is a post-quantum TLS check
Encrypted traffic captured today can be stored and decrypted later, once quantum computers can break today's key exchange ("harvest now, decrypt later"). Hybrid key exchange such as X25519MLKEM768 combines classical X25519 with the NIST ML-KEM standard so that recorded sessions stay safe. This check tells you whether a site already negotiates it, whether the protection comes from its own server or from a CDN in front of it, and what its certificates are signed with.
How it works
From a server running OpenSSL 3.5, we open a TLS 1.3 connection that offers only the hybrid group X25519MLKEM768. If the handshake completes, the server supports it; if it answers with a handshake_failure alert, it does not. If the server drops the connection instead, we retry with a browser-style offer (the hybrid group plus X25519, P-256 and P-384) and read which group it picks; only a result that is still unclear is reported as inconclusive. A second, normal handshake reads the certificate chain, and the response headers and edge IP show whether a CDN terminated TLS.
FAQ
If my CDN supports it, has my organisation migrated?
Partly. Visitors are protected up to the CDN edge, but the connection from the CDN to your origin server is invisible from outside and may still use classical key exchange. That is why the result separates "provided by a CDN" from "provided by your own server".
Can it detect Korean PQC algorithms (KpqC)?
Not from outside. NTRU+, SMAUG-T, HAETAE and AIMer do not have standard TLS codepoints yet, so a public scan cannot tell whether they are used internally. The result marks them as not observable instead of claiming they are absent.
Why is my certificate still RSA or ECDSA?
Because no public certificate authority issues post-quantum (ML-DSA) certificates yet. Key exchange is the urgent part — it protects recorded traffic — while signatures only need to be quantum-safe once quantum computers exist. The check tracks your signature algorithms without penalising them.