Short answer: almost certainly not. As of April 2026, fewer than one in five public websites use post-quantum cryptography for any part of their TLS handshake. The other 80%+ rely entirely on RSA, ECDSA, ECDH, or ECDHE — all of which will be broken by quantum computers, with the timeline now estimated at 2030-2035.
The longer answer: "quantum safe" isn't a single binary. It depends on which algorithms your server negotiates, what kind of certificate it presents, what symmetric ciphers it uses, and whether you've enabled hybrid post-quantum key exchange. Here's how to find out exactly where your site stands — in about 10 seconds.
Paste your URL into QVS. It connects to your TLS endpoint, inspects the certificate chain and cipher suite, and returns a quantum readiness score (0-100) with specific findings. No signup, no install.
Scan your site now →A website is "quantum safe" if every cryptographic primitive it depends on remains secure against an attacker with a sufficiently powerful quantum computer. In practice, this comes down to four categories:
Symmetric ciphers and hash functions are mostly fine — Grover's algorithm only halves their effective security, and AES-256 with SHA-256 keeps a comfortable margin. The catastrophe is in the asymmetric layer. Shor's algorithm doesn't just weaken RSA and elliptic-curve cryptography; it completely breaks them.
If your TLS handshake includes any of these, you are not quantum safe:
| Algorithm | Used for | Quantum status |
|---|---|---|
| RSA | Certificate signatures, sometimes key exchange | Broken by Shor's algorithm |
| ECDSA | Certificate signatures (EC certs) | Broken by Shor's algorithm |
| ECDH / ECDHE | Key exchange (almost universal in TLS 1.3) | Broken by Shor's algorithm |
| X25519 | Key exchange (modern preference) | Broken by Shor's algorithm (it's still EC) |
Run openssl s_client -connect example.com:443 on any major site and you'll see at least two of these in the cipher suite line. That's not because operators are careless — it's because the post-quantum standards (NIST FIPS 203, 204, 205) only finalized in August 2024, and TLS libraries are still rolling out support.
The realistic standard for 2026 is hybrid mode: combine a classical algorithm (X25519 or P-256) with a post-quantum algorithm (ML-KEM-768, formerly known as CRYSTALS-Kyber-768) in the same key exchange. If either algorithm fails, the hybrid still holds. This gives you a smooth migration path without betting the farm on still-young PQC implementations.
The TLS cipher suite for hybrid mode looks like this in the wire format:
If your server negotiates one of these for the key exchange, your session is quantum safe (the data exchanged in this connection cannot be retroactively decrypted by a future quantum attacker). Your certificate is a separate question — RSA and ECDSA certs are still vulnerable to forgery once large quantum computers arrive, but that's a longer migration cycle since CAs and root stores all need to ship ML-DSA support first.
Paste your URL at qvs.app. The scanner connects via TLS, reads the certificate chain, inspects the negotiated cipher suite, classifies every algorithm it finds against NIST FIPS 203/204/205, and returns:
For a typical 2026 production site, expect a score in the 40-60 range. That's normal, not a failure — it just means your stack still uses RSA/ECDSA certs and ECDHE key exchange. The score is your starting point for migration planning.
If you prefer the terminal, you can inspect the negotiated handshake yourself:
openssl s_client -connect yoursite.com:443 \
-tls1_3 -groups X25519MLKEM768:X25519:P-256 \
-servername yoursite.com < /dev/null 2>&1 \
| grep -E 'Server Temp Key|Cipher|Peer signing'Look at the Server Temp Key line:
X25519MLKEM768 or SecP256r1MLKEM768, your key exchange is quantum-safe (hybrid).X25519, P-256, or P-384 alone, your key exchange is quantum-vulnerable.The Peer signing digest and certificate output tell you the signature scheme — typically RSA-PSS or ECDSA, both of which are quantum-vulnerable.
Open Chrome DevTools → Security tab → click the lock icon → "Connection". Chrome shows the negotiated TLS version, key exchange algorithm, and cipher. If you see Kyber or MLKEM mentioned anywhere, you've got hybrid PQC. If not, you don't.
The migration depends on what you control. Three common scenarios:
X25519MLKEM768 to your supported groups list, ahead of classical curves.Total effort: typically 1-2 hours per server. No certificate change required — you're only updating the key exchange, not the signature scheme.
You may already have it. Cloudflare has been deploying X25519+Kyber by default on its free and paid tiers since late 2024. Fastly and AWS CloudFront are following more cautiously. Check your CDN's PQC documentation, then re-scan QVS to verify.
Your job is to ask. Email your vendors with three questions:
Vendors who can't answer those questions in 2026 are vendors who will be scrambling in 2029. That's a procurement signal worth noting.
Before wrapping up, it's worth addressing three beliefs that come up consistently in customer conversations and incorrectly reassure teams that they don't need to act yet.
TLS 1.3 is the latest TLS version and is vastly more secure than TLS 1.2 against classical attackers. It supports only strong cipher suites, it forces forward secrecy, and it eliminates several legacy weak options. None of that protects you from quantum. TLS 1.3 still uses ECDHE for key exchange by default, and ECDHE is broken by Shor's algorithm. Quantum safety is orthogonal to TLS version — it requires specifically choosing post-quantum or hybrid key exchange groups, which TLS 1.3 supports but does not require.
This is a common confusion between classical attack costs and quantum attack costs. ECDSA with P-256 is currently secure against classical attackers because solving the elliptic curve discrete logarithm problem on a 256-bit curve requires ~2¹²⁸ operations — beyond reach. But Shor's algorithm solves the exact same problem in polynomial time on a quantum computer. The key size doesn't protect you; the mathematical hardness assumption is what Shor's algorithm eliminates entirely. A 256-bit elliptic curve key takes roughly the same number of quantum operations to break as a 2048-bit RSA key. Neither is quantum-safe.
Partially true. If you're behind a CDN that has deployed hybrid PQC (Cloudflare is the clearest example), your user-facing TLS is already quantum-safe for the portion of the connection they terminate. But three layers of TLS are usually in play: (1) the user's browser to the CDN, (2) the CDN to your origin, and (3) your origin's internal service-to-service TLS. Most CDN PQC deployments cover layer 1 only. Layers 2 and 3 are still your problem, and if you're in a regulated environment, your auditors will want to see PQC at all three layers, not just the publicly-visible one.
Most websites today are not quantum safe. That's not a crisis on its own — quantum computers powerful enough to break RSA-2048 don't yet exist. But the threat is already real because of harvest now, decrypt later: encrypted traffic captured today can be decrypted in 2030+ when quantum computers arrive. For anything with long-term confidentiality value (medical records, financial data, source code, government communications), that means quantum-vulnerable TLS protecting that data right now is already a problem.
The fix is straightforward and getting easier every quarter. Hybrid post-quantum key exchange is supported in mainstream TLS libraries, deployed in production by major operators, and increasingly the default for new installations. Migration is no longer experimental — it's a configuration change.
Start by knowing where you are. The 10-second scan is free, and the score gives you the artifact you need to start planning.
QVS scans your TLS endpoint against NIST FIPS 203/204/205 standards. Get a score, findings, and migration recommendations in under 30 seconds. No signup required.
Scan your site →Related reading: Why Your TLS Will Break by 2030 · NIST's 2030 Post-Quantum Deadline · When Will Quantum Computers Break RSA?