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

Part of the security audit tool stack. See the pillar post for the full catalog of sibling audits and where this one fits in the lineup.

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.

Blockchain quantum risk, a different surface, same root threat

The TLS / SSH / code-signing migration story above covers the typical website's quantum exposure. There's a second surface that turns out to be much more concrete and much more time-pressured: on-chain crypto-asset signatures. Anyone whose visitors connect a Bitcoin or Ethereum wallet on their site, or who holds crypto themselves, has a different decision tree to walk.

The defining reference here is the Google Quantum AI cryptocurrency whitepaper. Babbush, Zalcman, Gidney, Broughton, Khattar, Neven, Bergamaschi, Drake, Boneh, "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations," March 2026 (PDF). New resource estimates put a fast-clock superconducting CRQC at ~1,200 logical qubits and ~70-90 million Toffoli gates to break secp256k1, roughly 9 minutes per private-key derivation, with fewer than half a million physical qubits. That figure changes the threat model in two important ways.

Two attack classes, two different timelines. On-spend attacks intercept a transaction in the public mempool, derive the private key in the ~9-minute window before the block is mined, and broadcast a forged transaction with a higher fee. At-rest attacks operate on public keys already on the chain and have hours-to-days. Fast-clock CRQCs (superconducting, photonic, silicon spin) enable both. Slow-clock CRQCs (neutral atoms, ion traps) realistically only enable at-rest first.

Bitcoin script types are not equally exposed. Per the whitepaper:

• P2PK (Satoshi-era, ~1.7M BTC), public key recorded directly. At-rest vulnerable forever. The single largest dormant-asset block.
• P2PKH (1...) and P2WPKH (bc1q...), pubkey hash on chain. Safe at-rest until any spend or any reuse reveals the public key. After that, all remaining UTXOs at that address are exposed.
• P2MS, pubkeys recorded directly; at-rest vulnerable.
• P2SH / P2WSH, script hash on chain. Same hash-protection rule, same reuse failure mode.
• P2TR (bc1p...). Taproot stores the tweaked public key directly in the locking script. A security regression vs P2WPKH: at-rest vulnerable from the moment of receive. Per the whitepaper, P2TR moved 16.8M BTC in 2025 and represents ~21.7% of 2025 transactions. As of writing, ~6.9M BTC across all script types is quantum-vulnerable.
• P2MR (BIP-360, draft), proposed Taproot variant with the quantum-vulnerable key path spend removed. The right migration target once finalized.

Ethereum is structurally worse. EOAs (externally-owned accounts) expose the public key the moment they sign their first outbound transaction, and there's no protective hash layer like Bitcoin's P2PKH. Per the whitepaper, the entire Ethereum account model is at-rest vulnerable to first-generation CRQCs once a key has signed. The fix is migrating to ERC-4337 account-abstraction wallets that support key rotation (Safe, Argent, Biconomy), they're the only Ethereum-side migration path that doesn't require sending funds to a brand-new address.

Beyond ownership: consensus, L2, and stablecoin admins. The whitepaper enumerates several classes of risk most blockchain coverage misses:

• BLS validator credentials on BLS12-381. Ethereum Proof-of-Stake consensus, at-rest vulnerable. Ethereum Foundation is researching hash-based replacements.
• KZG polynomial commitments in Data Availability Sampling (DAS), quantum-vulnerable; allows forged DAS proofs. Roughly 15M ETH at risk in the L2 data layer as of February 2026.
• Stablecoin admin multisigs (USDT, USDC), every smart contract upgrade exposes the multisig public keys on-chain. A CRQC that derives those keys takes complete control of the contract, mint, burn, pause, freeze, retarget. Existential risk for any holder of those tokens.
• Cross-chain key reuse, spending from a Bitcoin address on a fork (Bitcoin Cash) or sidechain (Rootstock) reveals the public key on that chain's blockchain, defeating BTC-side at-rest protection.

What to do about it. Three concrete next steps if any of this is in your operating surface:

1. Audit specific addresses with the Crypto Wallet Quantum Risk Audit. It classifies script type, checks reuse + spend history via public block explorers, and computes exposure class per the whitepaper.
2. Build a phased migration plan with the PQC Migration Plan Generator. Check the boxes for the surfaces you operate (TLS, SSH, code signing, validators, wallets, DKIM, DNSSEC, WebAuthn, KMS, DB TDE) and your jurisdiction; emit a phased plan aligned to NSM-10 / CNSA 2.0.
3. Enforce cert + key rotation hygiene with the TLS Cert Lifecycle Audit, long-lived certs amplify the harvest-now-decrypt-later window even on the web side, and CT-log analysis catches the often-missed "ACME client renewing with the same private key forever" failure mode.

Migration paths off ECDSA-only chains: Algorand (Falcon signatures already deployed for smart transactions and state proofs), QRL (XMSS native, ML-DSA in progress), XRP Ledger (ML-DSA on AlphaNet test instance), Mochimo (WOTS variant), Abelian (lattice-based privacy). For Bitcoin specifically, monitor BIP-360 P2MR adoption.

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
• Crypto Wallet Quantum Risk Audit, the on-chain side
• PQC Migration Plan Generator, the surface-by-surface phased plan
• TLS Cert Lifecycle Audit, cert + key rotation hygiene

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.
• Babbush, Zalcman, Gidney, Broughton, Khattar, Neven, Bergamaschi, Drake, Boneh, "Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations," Google Quantum AI, March 2026.
• BIP-360 (Pay-to-Merkle-Root, draft) for the proposed P2TR successor.
• Project 11 "Risq List" repository of Bitcoin public keys at risk of at-rest attacks.

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.