How the score works
A 0–100 readiness score built from five checks of a server's TLS configuration. It is a heuristic indicator informed by NIST, IETF and NSA guidance – not a compliance assessment. The weights and points are this tool's own judgement; no standard defines a numeric PQC score.
1. Each check earns points
| PASS | 100% of the check's weight |
| WARN | 40% – usable today, but needs a migration plan |
| FAIL | 0% – exposed to a quantum attack |
| UNKNOWN | Not scored – the check couldn't be completed (see section 4) |
2. Checks and weights
| Check | Weight | Why it matters | Standards basis | Rating |
| Key exchange | 40 | Protects today's traffic against 'harvest now, decrypt later'. The most urgent PQC risk. | FIPS 203 (ML-KEM) via the IETF hybrid TLS groups (Internet-Draft). | PASS Server accepts a hybrid ML-KEM group (e.g. X25519MLKEM768). WARN Only the pre-standard X25519Kyber768Draft00 group (legacy). FAIL Classical key exchange only, or TLS older than 1.3. |
| TLS version | 10 | Hybrid PQC groups only exist in TLS 1.3. | Hybrid PQC groups are only defined for TLS 1.3. | PASS TLS 1.3 WARN TLS 1.2 FAIL TLS 1.1 or older |
| Certificate key | 25 | Proves the server's identity. RSA/ECDSA can be broken by Shor's algorithm. | NIST IR 8547 (draft): classical public-key deprecated after 2030, disallowed after 2035. Target: FIPS 204 / 205. | PASS Post-quantum key type (ML-DSA or SLH-DSA). WARN RSA, DSA, ECDSA, Ed25519 or Ed448 (all classical). FAIL - |
| Signature | 10 | How the certificate was signed. Same quantum weakness as the certificate key. | Same as certificate key (NIST IR 8547 draft). | PASS Post-quantum signature (ML-DSA or SLH-DSA). WARN Any classical signature. FAIL - |
| Cipher suite | 15 | Bulk encryption. Symmetric crypto is only weakened by Grover's algorithm (halves key strength). | NSA CNSA 2.0 requires AES-256. NIST accepts AES-128, so this rating is the stricter reading. | PASS 256-bit key (AES-256, ChaCha20). WARN 128-bit key (AES-128). FAIL Less than 128-bit effective key (e.g. 3DES, RC4). |
3. The formula
score = Σ (weight × points) ÷ Σ weights of scored checks × 100
Example: PQC key exchange, TLS 1.3, ECDSA certificate and signature, AES-256 gives 40×1 + 10×1 + 25×0.4 + 10×0.4 + 15×1 = 79.
Why the ceiling today is 79, not 100: public CAs don't yet issue post-quantum certificates, so the certificate key and signature can currently reach WARN at best. A score of 79 means "everything that can be post-quantum today, is".
Colours: green ≥ 75, amber 40–74, red < 40.
4. Incomplete results
If a check can't be completed (typically the key-exchange probe, when a firewall or rate limit stops the server
answering), it is marked UNKNOWN and no score is given. The card shows Incomplete with the score of the
remaining checks for reference, and the JSON export has score: null, partial_score and
complete: false. Probes that time out or error are retried automatically; a verdict of FAIL needs an
explicit rejection from the server, so silence or a bare connection close is reported as UNKNOWN rather than FAIL.
Re-scan, or test from another network.
5. How key exchange is tested
The scanner sends a minimal TLS 1.3 ClientHello offering a single hybrid group (X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 and the pre-standard X25519Kyber768Draft00, which only earns a WARN) with no key share. A server that supports the group must reply with a HelloRetryRequest naming it; others send an alert. No real key exchange happens and no data is sent. A classical control probe confirms the server speaks TLS 1.3 at all.
6. What the score does not cover
Only the endpoint you scan. A CDN or proxy answers on behalf of the origin, so the hop behind it may differ. It also doesn't show that every client negotiates PQC – only that the server supports it. Certificate trust is deliberately not assessed: the chain, hostname match and revocation are not checked, so this is not a certificate health check (the expiry date is shown for information only). Other protocols (SSH, VPN, email) and data at rest are out of scope.
7. Standards and references
| Standard | Status | How it is used | |
| NIST FIPS 203 – ML-KEM | Final (Aug 2024) | Algorithm behind the hybrid key-exchange groups the scanner looks for. | source |
| NIST FIPS 204 – ML-DSA | Final (Aug 2024) | Target for post-quantum certificate keys and signatures. | source |
| NIST FIPS 205 – SLH-DSA | Final (Aug 2024) | Alternative post-quantum signature scheme for migration planning. | source |
| IETF draft-ietf-tls-ecdhe-mlkem | Internet-Draft (rev. 05, May 2026) – not yet an RFC | Defines X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 for TLS 1.3. These are the groups probed. | source |
| X25519Kyber768Draft00 | Pre-standard, being retired | Early Kyber-based hybrid. Not ML-KEM; the IETF draft obsoletes its registry code points. Scored as legacy (WARN). | – |
| NIST IR 8547 | Initial public draft (Nov 2024); dates proposed | Proposes deprecating RSA, ECDSA and ECDH after 2030 and disallowing them after 2035. Basis for the WARN on classical certificates. | source |
| NSA CNSA 2.0 | Published guidance | Calls for AES-256 and ML-KEM-1024 / ML-DSA-87 in national security systems. Basis for treating AES-128 as WARN; NIST itself is more lenient. | – |
Statuses last reviewed October 2026; drafts change – verify at the source before citing. Not standardised: the weights, the 40% credit for WARN, and the score bands.
8. Service limits
Ports: 443, 8443. Up to 10 targets per request. Results are cached for 60s and requests are rate limited. Only scan hosts you are authorised to test; see the acceptable-use policy shipped with this service.