How the score is calculated — and what it can’t see
A risk score is only useful if you can see how it’s built. Here’s the exact method behind PostQ’s 0–100 post-quantum risk score, what raises and lowers it, and an honest statement of where an external scan stops.
Every finding gets a severity
The scanner emits discrete findings — one per detected issue. Each is assigned a severity, and each severity maps to a fixed weight.
Critical
weight 100Deprecated TLS (1.0/1.1) enabled, or an expired / RSA-1024-class certificate.
High
weight 80Classical RSA / ECDSA certificate keys and classical-only key exchange (X25519, ECDH).
Medium
weight 50Long-lived certificates, or classical mTLS where hybrid is available.
Low
weight 20Minor posture items that improve crypto-agility but aren't urgent.
The worst finding dominates
We don’t take a flat average — that would let a pile of minor items bury one serious problem. Instead the score is a top-heavy weighted aggregate: findings are sorted worst-first, and each successive finding counts for less.
So the single most severe finding carries the most weight, the second counts half as much, the third a third, and so on. Ten Low findings can’t add up to a Critical, and one Critical can’t be diluted away by noise. A clean scan with zero findings scores 0 (no detected exposure); a host with severe, broad exposure approaches 100.
Raises risk vs. lowers risk
Raises risk ↑
- Deprecated TLS 1.0 / 1.1 still enabled
- Classical-only key exchange (X25519, ECDH, DH) — harvest-now-decrypt-later exposure
- RSA / ECDSA certificate public keys
- Classical certificate signature algorithms (SHA-256 + RSA/ECDSA)
- Long-lived certificates (weaker crypto-agility)
Lowers risk ↓
- TLS 1.3 available and deprecated versions disabled
- Hybrid ML-KEM key exchange negotiated (e.g. X25519MLKEM768)
- Shorter certificate lifetimes (easier rotation)
- Hybrid / PQ signature support where detectable
What the score does not tell you
Security people respect honesty over a magic number. Here’s where the methodology stops.
An external scan sees public endpoints only
The free scan performs a real TLS handshake against a public host on port 443 and reads public certificate metadata. It cannot see internal services, databases, service-to-service mTLS, or anything not exposed to the internet. Internal coverage requires the Kubernetes agent or cloud KMS integrations.
We never see private keys
PostQ reads algorithm and usage metadata. Private key material is never collected — not on external scans, and not through authenticated integrations. The score reflects algorithm posture, not key custody.
Key exchange ≠ signatures
Confidentiality risk (harvest-now-decrypt-later) comes from key exchange and is fixed with hybrid ML-KEM. Certificate signatures are an authentication concern, mitigated by ML-DSA / SLH-DSA — and bounded by what your CA can issue. We score them separately and weight confidentiality higher.
Detection, not deployment claims
We report the algorithms we observe. We never claim a post-quantum algorithm is deployed in your stack unless the handshake or integration confirms it. A target algorithm being 'available' is not the same as it being negotiated.
A point-in-time snapshot
A single scan reflects one moment. Configurations drift. Scheduled scans, the in-cluster agent, and cloud integrations keep the picture current; a one-off external scan does not.
Who runs the scan
PostQ is not a single scanner — it’s hosted scanners, in-cluster agents, and an ingestion API that share one inventory and scoring model.
We run the public scan
External TLS and certificate analysis runs server-side on PostQ infrastructure. Paste a domain, get a result — no install. This is what powers the free scan.
You run the internal inventory
The Kubernetes Helm agent and cloud KMS connectors run in your environment and report findings metadata back. This is how you reach internal services, Secrets, and cloud keys.
Bring your own scanner
The REST API also accepts results from your own tooling and the postq CLI, then unifies them into one inventory and report. You can scan with us, with an agent, or push your own findings.
Not a certification
The PostQ readiness score and reports are supporting evidence for cryptographic-inventory and migration planning. They are not a certification, attestation, or compliance guarantee, and they do not by themselves satisfy any regulatory requirement. Use them as input to your own security program — alongside guidance such as NIST’s PQC standards (FIPS 203/204/205) and migration frameworks — not as a substitute for it.