🔒 PQC Readiness Scanner
Test if your website supports post-quantum cryptography
🛡️ Protect Your Data from Quantum Threats
Data encrypted today can be recorded today and decrypted once a large quantum computer exists. This scanner shows which post-quantum key exchanges a website actually accepts, not just the one it happens to pick, along with how it authenticates, whether HTTP/3 is protected too, and what an attacker could still downgrade it to.
- Every key-exchange group tested one at a time: the 9 standard ML-KEM groups (FIPS 203, RFC 10024), the 2 obsolete Kyber drafts, 35 experimental KEMs and 14 classical groups
- The server's own preference order, and whether it insists on post-quantum key exchange when a client lists a classical group first
- Every TLS 1.3 cipher suite it accepts
- ML-DSA (FIPS 204) certificates, post-quantum key exchange over HTTP/3 (QUIC), and Encrypted Client Hello
- NSA CNSA 2.0, exactly as its TLS 1.3 profile states it: pure ML-KEM-1024 chosen when listed first, TLS_AES_256_GCM_SHA384, ML-DSA-87 for the handshake and every certificate, TLS 1.3 (CNSA 2.0 FAQ v2.1)
- Every scan kept, so each domain builds a record over time instead of one verdict
Try these examples:
?url=pqcrypta.com
/pqcrypta.com
Enter URL above
📊 Scan Results
✅ A+ (0)
Standard ML-KEM for every browser, TLS 1.3 only, insists on post-quantum key exchange, no obsolete Kyber.
⚡ A (0)
ML-KEM for every browser, TLS 1.3 only; but classical for a client that lists it first, or Kyber drafts still accepted.
🟡 B (0)
Standard ML-KEM, but older TLS versions are still open: a downgrade can take the post-quantum key exchange away.
🟠 C (0)
Supports ML-KEM, but a browser's handshake does not get it: the server prefers a classical group.
❌ F (0)
No ML-KEM a browser can use, Kyber drafts alone included: traffic can be recorded today and decrypted later.
🌐 Across Every Domain Measured live
How common each post-quantum capability is among the domains this scanner has measured, here and as part of every scan on the Post-Quantum Web Analyzer, from the latest scan of each by the current scanner. Every rate is shown with the population it was asked of, because they differ: what a browser gets is asked of every domain, which groups a server accepts only of TLS 1.3 servers that answered every probe, post-quantum key exchange over QUIC only where a QUIC handshake completed. The band on each bar is its 95% interval.
Loading…
Where adoption stops
Each rung asks its question of the domains on the rung above, so the fall between rungs shows where a capability stops.
What a browser gets
The key exchange Chrome's offer negotiated, every domain.
The server's own first choice
Offered every group it accepts, what it picked first: TLS 1.3 servers that answered every probe.
These figures are free to reuse under CC BY 4.0, credited to PQ Crypta. Every figure, as JSON: api.pqcrypta.com/pqc-scanner/corpus.
What is Post-Quantum Cryptography?
Post-quantum cryptography (PQC) refers to cryptographic algorithms that are designed to be secure against attacks from quantum computers. As quantum computing advances, current encryption methods like RSA and ECC may become vulnerable.
🌐 Why PQC Matters
Quantum computers could break current encryption within years. Migrating to PQC now protects your data from future threats.
🔄 Hybrid Mode
Combines classical and post-quantum algorithms for security today while preparing for quantum threats tomorrow.
📊 NIST Standards
ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) since August 2024; FN-DSA (FIPS 206) is in draft, and HQC was chosen in March 2025 as a second key-encapsulation mechanism.
Frequently Asked Questions
What is post-quantum cryptography?
Cryptography that stays secure against a large quantum computer, which would break RSA and elliptic-curve cryptography. NIST published the first standards in August 2024: ML-KEM (FIPS 203) for key exchange, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures.
Why test a website now?
Traffic recorded today can be decrypted once a large quantum computer exists ("harvest now, decrypt later"), so key exchange has to be post-quantum first. Chrome, Edge, Firefox and Safari already offer X25519MLKEM768 by default: a server that does not accept it gives every visitor a classical key exchange.
What is a hybrid key exchange?
One that combines a classical and a post-quantum algorithm, so an attacker has to break both. X25519MLKEM768 (RFC 10024) pairs X25519 with ML-KEM-768, and it is what current browsers offer first.
How does the scanner work?
It makes the handshake a browser makes and records the key exchange it gets, four more times, since the servers behind one address can differ, and once at each other address the name resolves to, IPv4 and IPv6: where the addresses answer differently, a visitor gets whichever their resolver returns, so everything else is measured at the one a visitor fares worst at, and measured again at the best one for the grade every address would get configured as it. Then it offers each of 60 key-exchange groups on its own, without a key share, so a server that accepts the group answers with a HelloRetryRequest naming it. From those answers it ranks the server's own preference and checks whether it insists on post-quantum key exchange. It also tests TLS 1.2, 1.1 and 1.0, asks for an ML-DSA certificate and checks its chain for the name, and tests post-quantum key exchange over HTTP/3, Encrypted Client Hello and the NSA CNSA 2.0 profile. A server that does not answer at all gets a second attempt and is asked from our other locations, in the US Midwest and Pennsylvania; when only one of them gets an answer, the result is that location's handshake and TLS version checks, and the page says so.
What do the grades mean?
A+: standard ML-KEM for every browser, TLS 1.3 only, the server insists on post-quantum key exchange, and it refuses the obsolete Kyber drafts. A: ML-KEM for every browser and TLS 1.3 only, but classical key exchange for a client that lists a classical group first, or Kyber drafts still accepted. B: standard ML-KEM, but older TLS versions are still open, so a downgrade can take the post-quantum key exchange away. C: the server supports ML-KEM, but a browser's handshake does not get it. F: no standard post-quantum key exchange.
What is CNSA 2.0?
The NSA's Commercial National Security Algorithm Suite 2.0. Its TLS profile admits only TLS 1.3 with ML-KEM-1024, AES-256 and ML-DSA-87 certificates; web browsers, servers and cloud services are to support and prefer it by 2025 and use it exclusively by 2033. No public CA issues ML-DSA-87 certificates yet, so today a server meets it only with its own CA, for clients that trust that CA.
🔮 What's Beyond Current Post-Quantum Cryptography?
Practical Fully Homomorphic Encryption (FHE)
Production DeploymentsCompute on encrypted data without ever decrypting it. Already deployed by major tech companies:
- Private Cloud Computing – Run database queries and analytics on encrypted data. Microsoft SEAL, IBM HElib in production.
- Encrypted Analytics – Google's Private Join and Compute joins two parties' datasets and sums over the match without either side seeing the other's records (private set intersection with homomorphic aggregation).
- Hardware Acceleration – DARPA's DPRIVE program funds FHE accelerators aimed at orders-of-magnitude speedups over software.
- OpenFHE Standard – Open-source FHE library with contributions from DARPA, Intel, and academic institutions worldwide.
- ⚡ PQCrypta Implementation – Post-ZK Homomorphic algorithm with ML-enhanced neural compression at pqcrypta.com/encryption and compression testing
Source: Microsoft SEAL (production), Google Private Join and Compute, IBM HElib, OpenFHE, DARPA DPRIVE program, PQCrypta
Post-Quantum Zero-Knowledge Proofs
Production UseProve knowledge without revealing information. Critical for privacy and blockchain:
- zk-STARKs – Quantum-resistant by default, no trusted setup required. Deployed in StarkNet and scaling Ethereum.
- Lattice-Based zk-SNARKs – Research systems build succinct proofs on lattice assumptions; deployed SNARKs such as Zcash's Halo 2 still rest on elliptic curves, which a quantum computer breaks.
- Private Authentication – Anonymous credentials and Privacy Pass tokens (RFC 9576–9578) prove a client is authorized without revealing who it is.
- Verifiable Computation – Filecoin uses zk-SNARKs to verify storage proofs without revealing data contents.
- ⚡ PQCrypta Implementation – Max Secure PQC-ZK and FN-DSA ZK Stack algorithms available at pqcrypta.com/encryption
Source: StarkWare (mainnet), Zcash (Halo 2), Filecoin, IETF Privacy Pass (RFC 9576–9578), Polygon zkEVM, PQCrypta
Hardware-Accelerated Post-Quantum Crypto
Silicon ShippingNext-generation processors making PQC as fast as classical cryptography:
- ARM Helium – The M-profile vector extension (Cortex-M55, M85) vectorizes the number-theoretic transform at the heart of ML-KEM and ML-DSA on microcontrollers.
- Intel/AMD AVX-512 – Number Theoretic Transform (NTT) optimizations in latest server CPUs enable fast PQC at scale.
- RISC-V Crypto Extensions – Open-source ISA adding native PQC instructions for embedded and IoT applications.
- PQC Hardware IP – ML-KEM and ML-DSA cores for secure elements, HSMs and smart cards (PQShield and others).
- ⚡ PQCrypta Implementation – WebAssembly acceleration for cryptographic operations with Web Workers for parallel processing at pqcrypta.com/encryption
Source: ARM Helium (Cortex-M85), Intel Sapphire Rapids, RISC-V Crypto TG, PQShield, PQCrypta
Post-Quantum Protocol Evolution
Active DeploymentInternet protocols transitioning to quantum-resistant security:
- TLS 1.3 Hybrid Key Exchange – X25519MLKEM768 is the default in Chrome, Firefox, Safari, Go and OpenSSL 3.5; RFC 10024 (2026) standardizes it alongside SecP256r1MLKEM768 and SecP384r1MLKEM1024. More than two-thirds of human traffic to Cloudflare used it by April 2026.
- Post-Quantum VPNs – IKEv2 adds ML-KEM to its (EC)DH exchange through RFC 9370's additional key exchanges; Rosenpass adds post-quantum keys to WireGuard.
- SSH with PQC – OpenSSH 10.0 (April 2025) made mlkem768x25519-sha256 its default key exchange.
- DNSSEC Evolution – Compact PQC signatures being tested to secure DNS infrastructure against quantum threats.
- ⚡ PQCrypta Implementation – HTTP/3 WebTransport with bidirectional QUIC stream encryption supporting 35 encryption algorithms and ML compression at pqcrypta.com/streaming
Source: RFC 10024, RFC 9370, Cloudflare Radar (April 2026), OpenSSH 10.0 release notes, IETF TLS and IPsec working groups, PQCrypta
Quantum-Secure Blockchain Systems
Migration PlanningCryptocurrency networks preparing for quantum threats to trillions in digital assets:
- Ethereum Quantum Roadmap – Account abstraction and signature aggregation enabling smooth PQC migration without hard forks.
- Bitcoin Taproot Evolution – Soft fork proposals for quantum-resistant addresses and signature schemes maintaining backward compatibility.
- Post-Quantum Smart Contracts – New cryptographic primitives for zero-knowledge, multisig, and threshold signatures.
- Layer 2 PQC Adoption – Rollups and state channels implementing quantum-resistant cryptography ahead of base layers.
Source: Ethereum Research, Bitcoin Core development, Web3 Foundation, Algorand Foundation
Quantum Computing Threat Timeline
Active ResearchUnderstanding when quantum computers will actually threaten current cryptography:
- The Estimates Keep Falling – Breaking RSA-2048 took an estimated ~20 million noisy qubits in 2019; fewer than one million in under a week by May 2025 (Gidney, Google); fewer than 100,000 with QLDPC codes by February 2026 (Iceberg Quantum). In March 2026 Google Quantum AI put 256-bit elliptic curves within reach of fewer than 500,000 qubits, in minutes.
- Hardware in 2026 – 96 verified logical qubits (QuEra, January 2026); 48 on Quantinuum's 98-qubit Helios; Google's Willow showed logical errors falling as codes grow. IBM's Starling targets ~200 logical qubits by 2029.
- Deadlines – NSA CNSA 2.0: web servers and browsers support and prefer it by 2025, use it exclusively by 2033. NIST IR 8547: RSA and elliptic-curve cryptography deprecated after 2030, disallowed after 2035.
- Harvest Now, Decrypt Later – Traffic recorded today is decrypted when the machine exists. Key exchange is the part that has to be post-quantum first.
Source: Gidney (arXiv 2505.15917, 2025), Iceberg Quantum (2026), Google Quantum AI (2026), QuEra, Quantinuum, IBM roadmap, NSA CNSA 2.0, NIST IR 8547
🚀 The Quantum Transition is Happening Now
Post-quantum key exchange is already the default between current browsers and the largest networks, and NSA's CNSA 2.0 expects web servers to prefer it now and use it exclusively by 2033. PQCrypta brings cutting-edge features like WebAssembly acceleration to your browser right now, with experimental zero-knowledge proof and homomorphic encryption APIs still in development.
Try Advanced PQC Features Now🚀 Start Your PQC Migration Pilot
Planning a post-quantum migration for your organization? Tell us about your environment and we'll help you scope a discovery pilot — agent rollout, full cryptographic asset inventory, and a prioritized remediation report.