About CheckPQC

CheckPQC is a free, open-methodology post-quantum TLS scanner from Aegyrix LLC. It exists because "is my server PQC-ready?" should not require digging through OpenSSL release notes, IETF drafts, and vendor blog posts to get a straight answer.

Why this matters

Every TLS connection your server completes today is recorded somewhere — by network operators, by passive collectors at IXPs, by adversaries with the budget to tap submarine cables. Classical key agreement (X25519, P-256, P-384) is secure against today's computers but vulnerable to Shor's algorithm on a sufficiently large quantum computer. The attack is called "harvest now, decrypt later" (HNDL): capture ciphertext now, store it cheaply, decrypt it the day a cryptographically relevant quantum computer (CRQC) exists.

CRQC timelines are estimates, not promises — but the U.S. government, Google, Cloudflare, Apple, and Signal have all decided the risk is real enough to ship hybrid post-quantum key agreement now, while classical ECDH still works as a safety net. If your data has a confidentiality lifetime measured in years (health records, source code, legal contracts, intellectual property, journalist sources, secrets that protect critical infrastructure), the migration window has already closed: anything captured today must already be PQ-protected.

Industry consensus

The hybrid X25519MLKEM768 group (IANA codepoint 0x11EC) is now the default outbound TLS group in every major shipping browser and most modern TLS stacks:

• Google Chrome & Chromium — enabled by default since Chrome 124 (April 2024). See Advancing Our Amazing Bet on Asymmetric Cryptography.
• Cloudflare — serving hybrid PQ to a third of the internet at the edge. See The state of the post-quantum internet (2024).
• Google Cloud — internal RPC traffic ALTS now uses PQ KEMs. See Why Google now uses PQC for internal comms.
• Apple iMessage — PQ3 protocol shipped February 2024. See iMessage with PQ3.
• Signal — PQXDH protocol live since September 2023. See PQXDH key agreement.
• OpenSSL 3.5 LTS — ML-KEM hybrid groups built in, no oqsprovider needed. See OpenSSL 3.5 release notes.

The standards

The cryptography is no longer experimental. NIST finalized the core post-quantum suite as Federal Information Processing Standards in 2024:

• FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) — the KEM CheckPQC tests for.
• FIPS 204 — Module-Lattice-Based Digital Signature Algorithm (ML-DSA) — PQ replacement for ECDSA / RSA signatures.
• FIPS 205 — Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) — hash-based signature backup.
• NIST IR 8547 — Transition to Post-Quantum Cryptographic Standards — official deprecation timeline; classical key-establishment algorithms become "deprecated" in 2030 and "disallowed" by 2035.

The wire-format integration into TLS 1.3 is specified by the IETF:

• draft-ietf-tls-hybrid-design — combining classical ECDH with a PQ KEM in a single TLS 1.3 key share.
• draft-kwiatkowski-tls-ecdhe-mlkem — codepoints for X25519MLKEM768, SecP256r1MLKEM768, etc.
• RFC 8446 — TLS 1.3 — the underlying handshake CheckPQC exercises.

Government mandates & timelines

This isn't only an industry preference. National security agencies and civilian governments are actively setting deadlines:

• United States — White House NSM-10 / OMB M-23-02: federal agencies must inventory cryptographic systems and prioritize migration to NIST PQC. See OMB Memo M-23-02.
• U.S. CISA — Quantum-Readiness: roadmap and inventory guidance for critical infrastructure operators. See CISA Quantum-Readiness.
• U.S. NSA — CNSA 2.0: quantum-resistant algorithms mandatory for U.S. National Security Systems by 2035, with most software/firmware to begin transition immediately.
• UK NCSC: published a multi-year PQC migration roadmap for critical services. See Next steps in preparing for PQC.
• Germany BSI: recommends hybrid PQ key agreement immediately for any traffic with long confidentiality requirements. See BSI quantum-safe cryptography.

Why hybrid, not pure PQ

The rational migration path is hybrid: the TLS 1.3 key share combines a classical ECDH share (X25519 or P-256) with an ML-KEM-768 KEM share, and the session key is derived from both. Neither half alone determines the key. This means:

• If ML-KEM is later found to have a flaw — unlikely but not impossible for any newly-standardized primitive — the connection still has the full security of X25519 against classical attackers.
• If a CRQC arrives, X25519 falls but ML-KEM holds, so the recorded ciphertext cannot be retroactively decrypted.
• The performance cost is tiny: ~1 KB of additional ClientHello payload, sub-millisecond CPU on modern hardware. Cloudflare measured the real-world impact at zero perceptible latency.

Pure-PQ-only modes exist but are uncommon, because hybrid is strictly safer during the transition. CheckPQC reports both HYBRID_ENABLED (the recommended posture) and PQC_ENABLED (pure PQ, also good but uncommon) as positive verdicts.

Methodology

Every scan runs a twin probe: two TLS 1.3 handshakes back-to-back against the same endpoint.

1. Hybrid attempt. Our ClientHello advertises X25519MLKEM768:SecP256r1MLKEM768:X25519:secp384r1:prime256v1 as supported groups. If the server picks one of the first two we know PQ is live.
2. Classical-only attempt. Same handshake but with PQ groups stripped. This lets us answer "would the server have used PQ if it could?"

The pair lets us produce seven distinct verdicts, including AVAILABLE_NOT_ACTIVE (the server's stack supports PQ but isn't picking it) and NOT_READY (the server breaks when PQ groups appear in the ClientHello — a real bug that several older TLS stacks exhibit).

What we don't test (yet)

• SSH, SMTP, IMAP, QUIC — coming in Phase 2.
• Endpoints behind authentication or that require client certs.
• Client-only PQ support — your browser's outbound TLS is best tested by hitting a known PQ-enabled host (the banner at the top of this page does exactly that against api.checkpqc.app).
• Cipher-suite hardness — we don't grade like SSL Labs; better tools exist for that.
• PQ signatures in the certificate chain (ML-DSA / SLH-DSA). That's a separate migration with different deployment pressure; Phase 3.

Open methodology

The scanner methodology is documented end-to-end in our Knowledge base: the supported groups we offer, the named-group registry we match against, and the seven verdict codes we emit. If you spot a misclassification or want to suggest a new test, please reach out via the contact form.