Post-Quantum Cryptography for Small Sites. A Practical Migration Path

Classical public-key cryptography, the RSA and elliptic-curve primitives every TLS connection uses today, breaks against a sufficiently large quantum computer. That computer doesn't exist yet. The smallest publicly-known quantum machines as of early 2026 have a few hundred qubits. Factoring a 2048-bit RSA key takes something in the millions.

The gap matters less than it sounds because of the Harvest Now, Decrypt Later (HNDL) threat model. An attacker records encrypted traffic today, stores it, and decrypts it 10 or 15 years from now when a sufficiently capable quantum computer exists. Anything in that traffic that still matters later (medical records, financial records, attorney-client communications, trade secrets, source code) is exposed the moment that computer arrives.

The defense, already deployed in most browsers and at Cloudflare's edge, is TLS 1.3 with a post-quantum hybrid key exchange. "Hybrid" because the key-agreement combines a classical curve (X25519) with a post-quantum KEM (Module-Lattice-based Key Encapsulation Mechanism, a.k.a. ML-KEM or Kyber). If either half is broken, the combined shared secret survives.

The PQC Analyzer probes your server for hybrid-KEX support and emits a migration plan.

What the tool checks

• TLS protocol version. TLS 1.3 is required for hybrid-KEX. Anything older is a hard fail for PQC readiness.
• Cipher negotiated. AEAD ciphers (AES-GCM, ChaCha20-Poly1305) are the modern default.
• Hybrid post-quantum key exchange. Two candidate curve names are tried: X25519MLKEM768 (the final standardized name from NIST FIPS 203 / IETF drafts) and X25519Kyber768Draft00 (the older draft name some servers still honor).
• Certificate chain: subject, issuer, validity dates, key size, OCSP stapling.
• Days until expiry.

The probe runs server-side and opens a real TLS connection. Browsers can't inspect handshake internals; only a backend probe can.

What the findings mean

Hybrid PQC supported. Your server is forward-secret against HNDL on the key-exchange layer. This is the "green" state. Cloudflare-fronted sites, AWS CloudFront origins with recent config, and self-hosted servers running OpenSSL 3.4+ with hybrid-KEX enabled land here.

Hybrid PQC not supported, TLS 1.3 active. Your server is classical-only. Sessions terminating today are HNDL-exposed. The fix is a TLS-terminator config change (nginx ssl_conf_command Groups X25519MLKEM768:X25519:secp256r1, Apache SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:secp256r1, Caddy handles it automatically on recent builds, or move to a CDN that fronts the site).

TLS 1.3 not active. First fix TLS. Then worry about PQC. A site stuck on TLS 1.2 can't negotiate hybrid key exchange regardless of curve support.

The migration-timeline context

• NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024.
• NSA's CNSA 2.0 requires US national-security systems migrate to PQC signing by 2030 and PQC key-exchange by 2035.
• National Security Memorandum 10 (NSM-10) requires federal civilian agencies inventory cryptographic dependencies by 2023 and migrate on rolling deadlines through 2035.
• Private businesses serving federal contracts should assume the same windows, probably with 1-3 year delays for commercial transition.
• Private businesses not serving federal contracts should still care about HNDL for any data whose sensitivity lifespan exceeds 10-15 years.

The one fix that matters today

Front the site with a CDN that already ships PQC. Cloudflare turned on hybrid X25519MLKEM768 for all free-tier sites in 2024. AWS CloudFront rolled it to all distributions shortly after. Fastly, Akamai, and Bunny.net all have PQC pilots. Moving a site behind Cloudflare takes an afternoon. PQC migration for the terminator becomes the CDN's problem, not yours.

If you can't or won't use a CDN, update your reverse proxy. OpenSSL 3.4 ships with ML-KEM in the default build. Config change is one line in nginx or Apache.

What the tool won't tell you

It can only inspect the TLS handshake. It can't see:

• Whether your code-signing certificates are PQC-ready. Most aren't. The fix is CA-pilot-dependent and several years out.
• Whether your SSH host keys are PQC-ready. SSH PQC is a separate migration with a separate tooling story.
• Whether your VPN / IPSec tunnels are PQC-ready. IKEv2 with PQC hybrid is still in RFC-draft.
• Whether your stored-at-rest data is encrypted with PQC. AES-256 is quantum-resistant (Grover's only halves the effective bit strength); AES-128 marginal; anything weaker, migrate.

For each of those, the fix-prompt output calls out what's out of scope and names the right next-step tool.

Related reading

• Mega Security Analyzer, runs the PQC probe plus everything else in one pass
• Security Headers Audit, the HTTP-layer complement
• DNS / Email Auth Audit, the DNS-layer complement

Fact-check notes and sources

• NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) specifications, published August 2024.
• NSM-10 (National Security Memorandum on Promoting United States Leadership in Quantum Computing) dated May 2022.
• NSA CNSA 2.0 Suite announcement, September 2022.
• Cloudflare blog post on post-quantum cryptography rollout, 2024.
• IETF draft-kwiatkowski-tls-ecdhe-mlkem for the hybrid key-exchange specification.
• OpenSSL 3.4 release notes for ML-KEM integration.

This post is informational, not cryptography-consulting, legal, or compliance advice. PQC standards and deployment guidance continue to evolve. Validate any cryptographic change in staging with a proper test matrix before production. Mentions of Cloudflare, AWS, Fastly, Akamai, Bunny.net, OpenSSL, BoringSSL, and Open Quantum Safe are nominative fair use. No affiliation is implied.