Check your TLS for post-quantum readiness
PostQ performs a real TLS handshake against your domain and reports the negotiated key exchange, cipher, and TLS versions — highlighting classical key exchange that's exposed to harvest-now-decrypt-later.
No signup required for the basic TLS scan. We only inspect public metadata.
- Detects TLS 1.0 / 1.1 / 1.2 / 1.3 support
- Identifies classical key exchange (X25519, ECDH, DH)
- Detects hybrid ML-KEM key exchange when negotiated
- Flags harvest-now-decrypt-later exposure
Why key exchange matters most
The TLS key exchange protects session confidentiality. Traffic protected by classical key exchange can be recorded today and decrypted later once a quantum computer exists. Hybrid key exchange (e.g. X25519MLKEM768) mitigates this.
What the TLS scan checks
- Supported TLS protocol versions
- Negotiated cipher suite and record encryption
- Negotiated key exchange group (classical vs hybrid)
- Whether deprecated TLS 1.0 / 1.1 are still enabled
Is TLS 1.3 post-quantum safe?
TLS 1.3 is required for hybrid key exchange, but TLS 1.3 alone is not post-quantum — it still defaults to classical groups unless hybrid ML-KEM is enabled on the server. PostQ tells you which case applies.
Algorithms that need a migration plan
| RSA | Integer factorisation — broken by Shor's algorithm. |
| ECDSA | Elliptic-curve discrete log — broken by Shor's algorithm. |
| DH | Finite-field Diffie-Hellman — quantum-vulnerable key exchange. |
| ECDH | Elliptic-curve Diffie-Hellman — quantum-vulnerable key exchange. |
| X25519 | Modern ECDH curve, still classical and quantum-vulnerable. |
| Ed25519 | Modern EdDSA signature, still classical and quantum-vulnerable. |
| RS256 | JWT RSA-SHA256 signature — quantum-vulnerable public-key signature. |
| ES256 | JWT ECDSA-P256 signature — quantum-vulnerable public-key signature. |
NIST-standardised replacements
| ML-KEM (FIPS 203) | Key encapsulation / key exchange (formerly Kyber). |
| ML-DSA (FIPS 204) | Digital signatures (formerly Dilithium). |
| SLH-DSA (FIPS 205) | Stateless hash-based signatures (formerly SPHINCS+). |
PostQ detects where quantum-vulnerable algorithms are used and reports them. We don’t claim a target algorithm is supported in your stack unless detection confirms it.
Frequently asked questions
Is TLS 1.3 quantum safe?
Not by itself. TLS 1.3 is a prerequisite for hybrid post-quantum key exchange, but unless the server enables a hybrid group like X25519MLKEM768, the key exchange is still classical and quantum-vulnerable. PostQ reports the actually negotiated group.
What is harvest-now-decrypt-later?
It's the threat model where an adversary records encrypted traffic today and decrypts it later once a cryptographically relevant quantum computer exists. Classical TLS key exchange is the main exposure, which is why hybrid key exchange matters.
Does the scanner detect post-quantum TLS?
Yes, when it's negotiated. If the handshake uses a hybrid ML-KEM group, PostQ labels the key exchange as hybrid-ready. Otherwise it flags the classical group as quantum-vulnerable.
Will the scan affect my server?
No. It performs a normal TLS handshake and a few short version-probe connections. It does not send application traffic or collect private keys.
Run a free PQC readiness scan
Scan any public domain for quantum-vulnerable TLS, certificate, and key-exchange cryptography. No signup required.
No signup required for the basic TLS scan. We only inspect public metadata.