The post-quantum cryptography threat: how quantum computers break encryption, and how developers get ready

A large enough quantum computer would unravel the public-key cryptography that protects almost everything online. It does not exist yet — but the data you send today can be recorded today and decrypted later. Here is how the math breaks, what standards bodies have shipped, and what to do about it now.

Nearly every secure connection you make — the padlock in your browser, the signed update your phone installs, the encrypted message you send — leans on two mathematical problems believed to be too hard for any classical computer: factoring huge numbers, and computing discrete logarithms. A sufficiently powerful quantum computer would solve both efficiently, and with them the RSA and elliptic-curve cryptography that underpins the modern internet. No such machine exists today. The reason cryptographers, standards bodies, and governments are moving anyway is that the threat is not purely in the future — and the migration is measured in years.

01Why this is a today problem, not a someday problem

The instinct is to file "quantum breaks encryption" under distant science fiction and move on. The flaw in that reasoning has a name: harvest now, decrypt later (sometimes "store now, decrypt later"). An adversary does not need a working quantum computer today to benefit from one tomorrow. They can record your encrypted traffic now — bulk-capturing VPN sessions, TLS handshakes, encrypted backups, diplomatic cables — and simply store the ciphertext. When a cryptographically relevant quantum computer eventually arrives, they decrypt the archive retroactively.⁶

That reframes the deadline entirely. The relevant question is not "when will a quantum computer break RSA?" but "how long does my data need to stay confidential?" Anything that must remain secret for ten or twenty years — health records, state secrets, biometric templates, long-lived signing keys, financial and legal archives — is effectively exposed the moment it crosses a network in a quantum-vulnerable cipher, even if the machine that reads it is a decade away. The clock started when the data was first transmitted.

02The math the internet is built on

Public-key cryptography solved a problem symmetric ciphers could not: how two parties who have never met can agree on a secret over an open channel. The trick is a trapdoor — a computation that is easy one way and infeasible in reverse without a secret. RSA rests on the difficulty of factoring the product of two large primes: multiplying them is trivial, but recovering them from the product is believed to take classical computers longer than the age of the universe for a 2048-bit key. Elliptic-curve cryptography (ECC) — used in ECDH key exchange and ECDSA signatures — rests on the hardness of the elliptic-curve discrete logarithm problem.⁵

The security of both is not proven; it is assumed, based on decades of failed attempts to find a fast classical algorithm. That assumption is exactly what a quantum computer overturns. It does not out-muscle the problem with raw speed — it changes the algorithm available to attack it. Two quantum algorithms matter here, and they matter very differently: Shor's is a catastrophe for public-key crypto, and Grover's is a manageable dent in symmetric crypto.

03Shor's algorithm: the catastrophe for public-key crypto

In 1994, Peter Shor showed that a quantum computer could factor large integers and compute discrete logarithms in polynomial time — an exponential speed-up over the best known classical methods.⁵ Shor's algorithm exploits quantum superposition and the quantum Fourier transform to find the period of a function, and that period reveals the factors. The consequence is blunt: RSA, Diffie–Hellman, ECDH, and ECDSA are not weakened by Shor's algorithm — they are broken. A quantum computer of sufficient scale recovers the private key from the public key, and the trapdoor swings open in both directions.¹

There is no clever parameter tweak that saves them. Doubling an RSA key from 2048 to 4096 bits roughly doubles the quantum work but does not change the polynomial-time verdict; you cannot out-run an exponential advantage by making keys a bit longer. This is why the response is not "bigger RSA keys" but "different math entirely" — cryptography built on problems that stay hard even for a quantum adversary.

A bigger classical lock still opens to the same quantum key. Shor's algorithm does not pick the lock faster — it makes the whole category of lock obsolete.

04Grover's algorithm: why symmetric crypto bends but does not break

Symmetric ciphers and hash functions — AES, SHA-2, SHA-3 — are on much firmer ground. The relevant quantum tool is Grover's algorithm, which speeds up brute-force search of an unstructured space quadratically: it finds a needle among N possibilities in roughly √N steps instead of N.⁶ Against a symmetric key, that effectively halves the security level — a 128-bit key offers roughly 64 bits of resistance against a quantum brute-force, and a 256-bit key offers roughly 128 bits.

A quadratic speed-up is serious but survivable, because you can simply use a bigger key. Migrating from AES-128 to AES-256 restores a comfortable ~128-bit quantum security margin, and SHA-384/SHA-512 keep hashing safe. In practice, symmetric cryptography needs a parameter bump, not a redesign. The existential problem lives entirely on the public-key side, where Shor's algorithm — not Grover's — is doing the damage.

05How close is the machine?

Today's quantum computers are nowhere near breaking RSA-2048. Doing so requires millions of stable, error-corrected logical qubits' worth of computation, assembled from a much larger number of noisy physical qubits — and current devices field only hundreds to low thousands of physical qubits with error rates far too high. The gap is enormous. But the estimates of how enormous keep shrinking, and that trend is the real story.

In 2019, a widely cited analysis put the cost of factoring RSA-2048 at roughly 20 million noisy physical qubits running for about eight hours. In May 2025, Google researcher Craig Gidney revised his own estimate down by a factor of twenty: fewer than one million noisy qubits, running for under a week, thanks to algorithmic improvements and more efficient error-correction layouts.⁷ The hardware still does not exist — but a 20× reduction in the theoretical requirement, from one research group in six years, is exactly why no one treats the timeline as fixed.

Because the arrival date is genuinely uncertain, serious planning anchors on migration timelines instead. The U.S. National Security Agency's CNSA 2.0 suite sets staged deadlines for national-security systems: support for post-quantum algorithms in new equipment through the late 2020s, with a transition to exclusive use of quantum-resistant cryptography targeted for 2035.⁸ A decade sounds generous until you weigh it against how long large organisations actually take to replace cryptography everywhere it hides — and against harvest-now-decrypt-later, which is charging interest the whole time.

06The new toolkit: NIST's post-quantum standards

The good news is that the replacement cryptography is no longer speculative. After an eight-year public competition begun in 2016, the U.S. National Institute of Standards and Technology (NIST) published the first finalised post-quantum standards on 13 August 2024.¹ Three algorithms anchor the new toolkit, each built on math believed to resist both classical and quantum attack — primarily structured lattices and hash-based constructions:

1. FIPS 203 — ML-KEM (Module-Lattice Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber). The primary standard for key establishment — the job RSA and ECDH do in a TLS handshake. It is fast and its keys are compact (public keys on the order of 800–1,568 bytes).²
2. FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm, from CRYSTALS-Dilithium). The primary standard for digital signatures — authenticating software updates, certificates, and documents.³
3. FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, from SPHINCS+). A signature scheme whose security rests only on hash functions — a conservative backup that does not share lattice assumptions, at the cost of larger signatures.⁴

The trade-offs are real and worth internalising before you deploy: post-quantum keys and signatures are generally larger than their elliptic-curve equivalents, which inflates handshake sizes, certificate chains, and packet counts. That is why most early deployments use ML-KEM for key exchange (where lattice keys are manageable) and stage signature migration more carefully (where sizes bite harder). The algorithms are standardised; the engineering is in absorbing their size and performance profile without breaking existing protocols.

07It is already shipping

Post-quantum cryptography is not a whiteboard exercise — it is already carrying real traffic, almost always in a hybrid mode that runs a classical and a post-quantum algorithm side by side, so the connection stays secure even if one of the two later proves weak. Three deployments show the pattern:

1. The web. The hybrid key exchange X25519MLKEM768 — classical X25519 combined with ML-KEM — is now the default in Chrome and Firefox, and Cloudflare reports that by 2026 the majority of human-initiated TLS traffic to its network negotiates a post-quantum key exchange.⁹ The transition is being standardised through the IETF.
2. Messaging. Signal shipped PQXDH (Post-Quantum Extended Diffie–Hellman) in 2023, adding ML-KEM-based key establishment to its handshake.¹¹ Apple went further in 2024 with PQ3 for iMessage, combining post-quantum initial key establishment with an ongoing post-quantum ratchet for self-healing security — what Apple calls Level 3.¹⁰
3. Everything else follows the same hybrid logic in VPNs, SSH, and cloud KMS offerings — production traffic protected against a machine that does not exist yet.

The lesson for developers is that the ecosystem has already chosen its default answer: hybrid. You rarely rip out X25519 and replace it with ML-KEM; you run both, so you inherit the post-quantum guarantee without betting everything on a young algorithm.

08What developers should actually do now

You do not need to hand-roll lattice cryptography — and you should not. The practical work for most software teams is crypto-agility: the ability to swap cryptographic algorithms without re-architecting your systems. Joint guidance from CISA, the NSA, and NIST frames the near-term task as preparation and inventory rather than a wholesale rewrite.¹² A pragmatic order of operations:

1. Inventory your cryptography. You cannot migrate what you cannot see. Build a cryptographic bill of materials: where do you use RSA, ECDH, ECDSA? Which libraries, certificates, protocols, hardware modules, and third-party dependencies? This discovery step is consistently the longest and most underestimated.¹²
2. Root out hard-coded algorithms. Anywhere a cipher, key size, or curve is baked into code or config as a constant, replace it with a negotiable, swappable choice. Crypto-agility is an architecture property, not a library you install.
3. Prioritise by data lifetime. Apply Mosca's inequality. Long-lived secrets and long-lived signing keys — root CAs, firmware-signing keys, anything protecting data that must survive decades — move first, because harvest-now-decrypt-later is already working against them.
4. Adopt hybrid where it exists. Turn on hybrid post-quantum TLS at your load balancers, CDN, and gateways; pick up updated libraries (OpenSSL, BoringSSL, and cloud KMS/HSM offerings are adding ML-KEM and ML-DSA). Prefer AES-256 and SHA-384/512 for symmetric needs.
5. Bump symmetric parameters. The cheapest quantum-hardening you can do this quarter: default new symmetric keys to 256-bit and hashes to 384/512-bit. It is a one-line policy change with a real payoff.

09Where OcxlyDev lands

The quantum threat is easy to dismiss because the headline event — a machine that factors RSA-2048 — has not happened and may be a decade or more away. But that framing misses where the risk actually sits. Harvest-now-decrypt-later means the confidentiality of today's long-lived data is already on the clock; the standards are finalised; the algorithms are shipping in browsers and messengers you use every day; and the migration is a multi-year organisational slog, not a flag you flip. The teams that will be fine are the ones that started their cryptographic inventory before it was urgent.

Our take: treat post-quantum readiness as an agility problem first and a quantum problem second. If your systems can swap a cipher without a rewrite, you are prepared for ML-KEM today and for whatever supersedes it tomorrow — and you have fixed a fragility that was always latent in hard-coded crypto. Turn on hybrid TLS where you can, move AES to 256-bit, inventory relentlessly, and let the vetted libraries carry the hard math. The machine may be years out; the work is not.