PQC readiness
Post-Quantum Cryptography (PQC) readiness classifies every discovered certificate by how well its key material will age when quantum computers can break classical public-key crypto. Four buckets: vulnerable, transition, ready, unknown. The score feeds into risk, dashboards, and the finding system.
Classification buckets
| Bucket | What qualifies | Interpretation |
|---|---|---|
| Vulnerable | RSA < 2048, DSA < 2048 | Already too weak against pre-quantum attacks, let alone quantum. Fix now regardless of PQC. |
| Transition | All other classical: RSA 2048+, ECDSA P-256/P-384/P-521, Ed25519 | Safe today. Will be broken by a cryptographically-relevant quantum computer (CRQC). Rotate to a PQC or hybrid scheme once browsers / CAs support it. |
| Ready | Pure PQC (ML-KEM, ML-DSA) or hybrid (ECDSA + ML-KEM) certs | Will survive a CRQC. This is the target state. As of 2026, almost nothing in the wild qualifies. |
| Unknown | Algorithm we can't classify — custom OIDs, obscure EC curves, malformed keys | Look at it. Often indicates a mis-extracted cert or an experimental algorithm. |
Why RSA 2048 is Transition, not Vulnerable
RSA 2048 is still considered pre-quantum strong in 2026 — NIST recommends it through the end of this decade. The moment a CRQC appears, every RSA-2048 (and every classical ECC) becomes trivially breakable. The vulnerable bucket is reserved for keys that were already sub-standard before quantum entered the picture — RSA-1024 is a concrete example.
How classification runs
- Discovery scan extracts the public key.
pkg/discovery/pqc.golooks at the algorithm OID + key size.- ECDSA curves are identified via
Params().BitSize— P-256 / P-384 / P-521 each produce a distinct label. - Hybrid schemes (experimental) are detected via the composite OIDs proposed in IETF drafts.
- If nothing matches the lookup table, the cert is tagged
unknown.
Key-exchange PQC (harvest-now-decrypt-later)
Certificate classification above is about the signature (authenticity — broken after a CRQC exists). The key exchange is a separate axis and the one that bites today: an attacker can record TLS sessions now and decrypt them once a CRQC arrives ("harvest-now-decrypt-later"), unless the handshake used a hybrid post-quantum key exchange.
For every reachable endpoint the scanner captures the negotiated TLS 1.3 key-exchange group and classifies it:
| KEX class | Example groups | Meaning |
|---|---|---|
| Quantum-safe | X25519MLKEM768 and other hybrid ML-KEM groups | Session keys resist harvest-now-decrypt-later. |
| Classical | X25519, P-256, P-384 | Standard ECDHE — forward secret, but not quantum-safe. |
| RSA (no PFS) | legacy RSA key exchange | No forward secrecy and not quantum-safe. |
This is per-endpoint (a property of the server's TLS config), not per-cert — the same cert can be quantum-safe on one endpoint and classical on another depending on what each server negotiates. Discovery → Inventory shows a Quantum-Safe Key Exchange widget and a per-endpoint Key Exchange column.
Risk score integration
Vulnerable keys add 10 to the certificate's risk score. Transition adds nothing (it is the expected state for classical certs). Ready and Unknown also contribute zero. See risk scoring for where in the risk flow this slots in.
Findings
Every cert classified vulnerable emits a pqc_vulnerable finding at severity Medium, with remediation text suggesting a bridge-to-ECDSA or RSA-3072+ rotation. See findings.
Stats surfaces
- Discovery → Inventory — stats widget shows PQC breakdown as a donut chart; click a slice to filter.
- Dashboard → 47-Day Readiness — PQC readiness is one of the scoring inputs.
- Individual cert detail — status badge + short explanation.
Roadmap
As IETF finalises hybrid composite schemes (e.g. id-MLDSA44-ECDSA-P256) and major CAs start issuing them, CertAutoPilot will add recognition for each new algorithm. Classification is a versioned lookup table — a backend upgrade picks up newly- classifiable algorithms without any operator action.
Troubleshooting
Too many unknown
Usually a scanner capture problem — the cert bytes are incomplete. Re-scan the endpoint; if still unknown, export the PEM from the inventory detail view and inspect with openssl x509 -text to see the algorithm.
"My org does not care about PQC yet, how do I mute these findings?"
Bulk-suppress pqc_vulnerable findings with a 180-day expiry. The suppression records are a breadcrumb for the next auditor — so you can point at the policy decision rather than looking like you missed the issue.