Open a terminal, type openssl s_client -connect example.com:443, and look at the cipher suite that gets negotiated. You'll see something like ECDHE-RSA-AES256-GCM-SHA384. Two of those four algorithms — ECDHE and RSA — will be cryptographically broken by sufficiently powerful quantum computers. The same is true for almost every TLS handshake happening on the internet right now.
This isn't a prediction or a hypothetical. It's a mathematical consequence of Shor's algorithm, published in 1994, and the only open question is when sufficiently large quantum computers will exist. Conservative estimates put the window at 2030 to 2035. Some recent breakthroughs in error correction suggest the early end of that range is more realistic than the late end.
The standards bodies aren't waiting. NIST has finalized post-quantum cryptography standards. NSA has published a binding migration timeline (CNSA 2.0). Cloudflare, Apple, Google, and OpenSSH have already deployed post-quantum key exchange in production. If you operate a website, an API, or a mobile app, you have a deadline you may not yet know about.
Two quantum algorithms matter for cryptography. The first is far more dangerous than the second.
Shor's algorithm efficiently solves the integer factorization problem and the discrete logarithm problem on a quantum computer. Both are the mathematical foundations of public-key cryptography:
The estimate for breaking RSA-2048 with a fault-tolerant quantum computer is roughly 4,000 logical qubits running for several hours. Today's machines have between 1,000 and 5,000 physical qubits but very high error rates, so the effective logical qubit count is much smaller. Bridging that gap is an engineering problem, not a theoretical one.
Grover's algorithm provides a quadratic speedup for unstructured search. Practically, this halves the security level of symmetric ciphers and hash functions:
This is why CNSA 2.0 mandates AES-256 as the symmetric minimum. Doubling key sizes is enough — replacing the algorithm isn't necessary.
Even if quantum computers don't arrive until 2032, an attacker capturing your encrypted traffic today can decrypt it then. This is called HNDL (Harvest Now, Decrypt Later), and it has been publicly attributed to multiple state-level intelligence agencies for at least five years.
If you're transmitting anything with a long confidentiality requirement — medical records, financial data, government communications, intellectual property, biometric data, source code — that data is effectively being archived right now for future decryption. The 2030 deadline isn't when the threat begins. It's when the threat is realized for data you sent in 2025.
The only way to defend against HNDL is to stop using quantum-vulnerable algorithms before the data has long-term value, not after the quantum computer arrives.
These are real, in-force standards — not predictions:
| Date | Standard | Effect |
|---|---|---|
| 2024 Q3 | NIST FIPS 203 / 204 / 205 | ML-KEM, ML-DSA, SLH-DSA finalized as US federal standards |
| 2025 | CNSA 2.0 (NSA) | National security systems must support PQC for new procurement |
| 2027 | PCI DSS 4.0 | Cryptographic inventory and quantum risk assessment required for payment processors |
| 2028 | NIS2 / DORA (EU) | Critical infrastructure and EU financial services must complete crypto resilience assessment |
| 2030 | CNSA 2.0 | RSA and ECC fully deprecated for national security systems |
| 2031 | NIST IR 8547 | RSA and ECDSA disallowed for new digital signatures |
| 2035 | NIST IR 8547 | All classical asymmetric cryptography disallowed |
If you operate in healthcare, finance, government, defense, or critical infrastructure, the regulatory deadlines arrive before the cryptographically relevant quantum computer does. The migration window isn't 2030-2035. It's now to 2027 if you want to be compliant, not just secure.
The major operators are not waiting:
sntrup761x25519-sha512 the default key exchange algorithm in 2025.The early movers chose hybrid mode — combining a classical algorithm (X25519 or P-256) with a post-quantum algorithm (ML-KEM-768). This is the recommended migration pattern: if either algorithm fails, the hybrid still holds. It's the bridge between today's PKI and the post-quantum future.
Migration to post-quantum cryptography isn't a single switch. It's a multi-year program that touches every certificate, every TLS endpoint, every cryptographic library, and every protocol you use. Here's a realistic starting sequence:
X25519MLKEM768 as the preferred key exchange in your TLS configuration. Hybrid mode means zero downside if PQC has issues, full upside when quantum arrives.QVS scans your TLS endpoint, code, or certificate against NIST FIPS 203/204/205 and CNSA 2.0. Free, no signup, 30 seconds. Your starting point for migration planning.
Run a free scan →Every public-key algorithm in widespread use today (RSA, ECDSA, ECDH, ECDHE, DH, Ed25519) will be broken by quantum computers. NIST has set 2031 as the deprecation deadline for digital signatures and 2035 for all classical asymmetric cryptography. The major internet operators are already migrating. The threat is realized today via harvest-now-decrypt-later, not in some future quantum apocalypse.
The question isn't whether to migrate. It's whether you start now while the deadline is comfortable, or in 2029 when you're scrambling to retrofit hybrid TLS into a stack that's been quantum-vulnerable for decades.
Start with an inventory. Then start with hybrid TLS. The path from there is well-marked.