What Is the Quantum Computing Threat?

An attacker does not need a working quantum computer today to act on the quantum computing threat today. They need a packet capture, a place to store it, and patience. A nation-state intercepts your TLS sessions, your VPN tunnels, and your encrypted file transfers right now, writes them to disk, and waits. The data is unreadable for the moment. The bet is that in ten or fifteen years a quantum computer large enough to run Shor's algorithm will turn that archive into plaintext. The cipher you trust today is the cipher that exposes you later. That is the part of the threat that is already live, and it is the reason the clock started years ago.

The quantum computing threat is the risk that a sufficiently powerful quantum computer breaks the public-key cryptography that secures almost all internet traffic, stored secrets, and digital signatures. It is fundamentally a threat to data encryption, specifically the asymmetric kind that protects keys in transit. It does not threaten everything equally, and it is not science fiction with no deadline. This guide covers what the threat actually is, why public-key algorithms are the ones that break while symmetric ones mostly survive, what "harvest now, decrypt later" means for data you encrypt today, the NIST post-quantum cryptography standards finalized in 2024 (FIPS 203, 204, and 205), and what a defender should do before a cryptographically relevant quantum computer exists.

What is the quantum computing threat?

The quantum computing threat is the prospect that a cryptographically relevant quantum computer (CRQC) will be able to solve the mathematical problems that today's public-key cryptography relies on for its security. Those problems, integer factorization and the discrete logarithm, are hard for classical computers. A large enough quantum computer running Shor's algorithm solves them efficiently, and the entire security guarantee of RSA, Diffie-Hellman, and elliptic-curve cryptography collapses with them.

A quantum computer is not a faster classical computer. It does not brute-force keys at higher clock speed. It computes on qubits, which can hold superpositions of states, and certain algorithms exploit that property to solve specific structured problems exponentially faster than any classical method. Shor's algorithm, published in 1994, is the one that matters here: it factors large integers and computes discrete logarithms in polynomial time. That is the exact capability RSA and ECC are built to deny an attacker.

No such machine exists yet. Today's quantum computers have on the order of hundreds to low thousands of noisy physical qubits, and breaking RSA-2048 is estimated to require millions of physical qubits once error correction is accounted for. The gap is real and large. The threat is not that the machine exists; it is that data encrypted today can be stored until it does, and that migrating the world's cryptography takes longer than most organizations think.

Why public-key cryptography breaks and symmetric mostly survives

Not all encryption is equally exposed. The split runs along the line between asymmetric (public-key) and symmetric cryptography, and understanding it tells a defender exactly where to spend effort.

Public-key algorithms are the ones in danger. RSA, Diffie-Hellman, and elliptic-curve cryptography (ECDSA, ECDH) all derive their security from factorization or the discrete-logarithm problem. Shor's algorithm breaks both. A CRQC running Shor's recovers the private key from the public key, which defeats key exchange, defeats digital signatures, and defeats the certificate trust that underpins TLS, code signing, and most authentication. This is the category that has to be replaced.

Symmetric algorithms hold up far better. AES and other symmetric ciphers are not built on factorization or discrete logarithms, so Shor's algorithm does not apply. The relevant quantum attack is Grover's algorithm, which provides only a quadratic speedup on brute-force search. A quadratic speedup effectively halves the security level: AES-128 drops to roughly 64 bits of quantum-resistant strength, while AES-256 retains about 128 bits, which is still infeasible to brute-force. The practical guidance is straightforward. Move symmetric encryption to 256-bit keys and it stays safe. Hash functions face the same Grover-style halving and are handled the same way, by using longer outputs.

This is why the response is not "throw out all encryption." It is a targeted replacement of public-key algorithms with quantum-resistant ones, plus a key-length bump on the symmetric side.

Harvest now, decrypt later

The most important thing to understand about this threat is that the attack timeline and the decryption timeline are not the same. An adversary can attack today and decrypt years later. This is "harvest now, decrypt later," sometimes written HNDL or called store-now-decrypt-later, and it is the reason the threat is not safely in the future.

The mechanism is simple. An attacker with the ability to intercept traffic, a nation-state on a backbone, a well-resourced advanced persistent threat positioned at an internet exchange, or anyone who can capture and store encrypted data, collects ciphertext now and archives it. They cannot read it yet. They do not need to. They hold it until a CRQC arrives, then run Shor's algorithm against the captured key exchanges and recover the session keys, and the entire archive becomes plaintext retroactively.

The defender's exposure depends on one variable: how long the data must stay confidential. This is sometimes framed as Mosca's inequality, the rule that you have a problem if the time your data must remain secret, plus the time it takes you to migrate to quantum-safe cryptography, exceeds the time until a CRQC exists. Health records, classified material, intellectual property, biometric data, and long-lived credentials all have confidentiality lifetimes measured in decades. Anything in that category that is encrypted today with RSA or ECC and transmitted over a network an adversary can tap is already at risk, even though no quantum computer can read it yet.

That reframes the deadline. The question is not "when will a quantum computer break RSA." It is "is any data I am protecting today still sensitive on the day that happens." For a large class of data, the honest answer is yes, which is why migration cannot wait for the machine to appear.

NIST post-quantum cryptography standards (FIPS 203, 204, 205)

The replacement algorithms exist and are standardized. After an eight-year public competition that began in 2016, NIST published the first three post-quantum cryptography (PQC) standards on August 13, 2024. These are not drafts or candidates. They are finalized Federal Information Processing Standards, and they are the algorithms a migration targets.

FIPS 203, ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), is the primary standard for key establishment. It is derived from the algorithm submitted as CRYSTALS-Kyber and is the quantum-resistant replacement for the key exchange that RSA and ECDH perform today. ML-KEM is the one most TLS and VPN traffic will adopt first, because key exchange is exactly what harvest-now-decrypt-later targets.

FIPS 204, ML-DSA (Module-Lattice-Based Digital Signature Algorithm), is the primary standard for digital signatures, derived from CRYSTALS-Dilithium. It replaces ECDSA and RSA signatures for authentication, code signing, and certificate chains.

FIPS 205, SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), is a second signature standard derived from SPHINCS+. Its security rests only on the strength of its hash functions, a different and very conservative mathematical foundation, so it serves as a backup to ML-DSA in case a weakness is ever found in the lattice-based approach that the other two standards share.

The first two standards, ML-KEM and ML-DSA, are lattice-based. SLH-DSA is hash-based on purpose, so that the entire PQC suite does not depend on a single class of math problem holding up. NIST has continued to evaluate additional algorithms beyond these three to widen that diversity further.

What a defender should do now

The threat is a migration problem, not an alert to triage. The work is long, and the cluster of activity it belongs to is exposure management, the discipline behind continuous threat exposure management (CTEM): knowing what you have, knowing where it is weak, and driving the riskiest gaps to closure before they are exploited. The same discipline applies here, with cryptography as the asset.

Start with a cryptographic inventory. You cannot migrate what you cannot see. Find where public-key cryptography is used across the estate: TLS endpoints, VPN concentrators, code-signing pipelines, certificate authorities, hardcoded keys in applications, and embedded devices with firmware that may never be updated. Most organizations have no map of this, and the inventory is the slowest and most valuable step. It is the discovery phase of an exposure-management program, applied to crypto.

Prioritize by data lifetime. Apply the harvest-now-decrypt-later test: which systems carry data that must stay confidential for a decade or more, and which of those traverse networks an adversary could tap. Those are the first migration targets, because they are the ones HNDL is already harvesting. Short-lived secrets, by contrast, can wait their turn.

Build for crypto-agility. The specific lesson of this migration is that swapping a cryptographic algorithm should not require rewriting an application. Systems that abstract their cryptography behind a clean interface can adopt ML-KEM and ML-DSA, or whatever follows them, without a ground-up rebuild. Systems with algorithms hardcoded throughout cannot. Crypto-agility is the property that makes the next transition cheaper than this one.

Adopt the standards deliberately. Begin testing ML-KEM in TLS, often in a hybrid mode that runs a classical and a post-quantum key exchange together so a flaw in either still leaves the connection protected by the other. Move symmetric encryption to AES-256. Pressure vendors for PQC roadmaps, because much of the estate is software you buy rather than build, and you cannot migrate a black box yourself. None of this is a single project with an end date. It is a multi-year program, and the organizations that start the inventory now are the ones that will not be improvising when a CRQC stops being hypothetical.

Frequently Asked Questions

What is the quantum computing threat in simple terms?

The quantum computing threat is the risk that a powerful future quantum computer will break the public-key cryptography, RSA, Diffie-Hellman, and elliptic-curve, that secures internet traffic, stored data, and digital signatures. Running Shor's algorithm, such a machine could recover private keys from public ones, defeating the encryption and authentication almost everything online depends on.

When will quantum computers break encryption?

No one knows the exact date, and no current quantum computer can break RSA. Breaking RSA-2048 is estimated to need millions of error-corrected physical qubits, while today's machines have hundreds to low thousands of noisy ones. The danger is not the date itself but harvest-now-decrypt-later: data encrypted today can be stored and decrypted whenever that machine arrives, so long-lived secrets are at risk now.

What is harvest now, decrypt later?

Harvest now, decrypt later (HNDL) is an attack where an adversary intercepts and stores encrypted data today that they cannot yet read, then decrypts it years later once a cryptographically relevant quantum computer exists. It makes the threat present-tense for any data that must stay confidential for a decade or more, because the ciphertext being archived now uses algorithms a quantum computer will eventually break.

Does quantum computing break all encryption?

No. It primarily breaks public-key (asymmetric) cryptography like RSA, Diffie-Hellman, and elliptic-curve, because Shor's algorithm efficiently solves the factorization and discrete-logarithm problems they rely on. Symmetric algorithms like AES are only weakened by Grover's algorithm, which halves their effective strength, so AES-256 remains secure. Hash functions are affected the same way and are handled with longer outputs.

What are the NIST post-quantum cryptography standards?

NIST published its first three post-quantum cryptography standards on August 13, 2024: FIPS 203 (ML-KEM, for key encapsulation, derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, for digital signatures, derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, a hash-based backup signature standard derived from SPHINCS+). They are the standardized, quantum-resistant replacements for today's public-key algorithms.

What is post-quantum cryptography?

Post-quantum cryptography (PQC) is cryptography that runs on classical computers but is designed to resist attacks from both classical and quantum machines. It is based on math problems, such as those over structured lattices, that no known quantum algorithm solves efficiently. The NIST FIPS 203, 204, and 205 standards are the standardized PQC algorithms organizations are now migrating to.

How should an organization prepare for the quantum threat?

Start with a cryptographic inventory to find everywhere public-key cryptography is used. Prioritize migration by data lifetime, fixing systems whose data must stay confidential longest first, since those are what harvest-now-decrypt-later targets. Build crypto-agility so algorithms can be swapped without rewriting applications, begin testing ML-KEM in hybrid TLS, move symmetric encryption to AES-256, and require PQC roadmaps from vendors.

The bottom line

The quantum computing threat is not a future event with a clean start date. The capability to break RSA and ECC does not exist yet, but the attack does: harvest now, decrypt later means an adversary archives your encrypted traffic today and reads it once a cryptographically relevant quantum computer arrives. For any data that must stay confidential for a decade or more, the exposure is already real.

The shape of the response is settled. Public-key cryptography breaks under Shor's algorithm and must be replaced; symmetric cryptography is only halved by Grover's and survives at 256-bit keys. The replacements are standardized: NIST's FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA), finalized in August 2024. What is not settled is whether a given organization has started. The work that matters now is the unglamorous part, inventorying where public-key crypto lives, prioritizing by how long the data must stay secret, and building the agility to swap algorithms without a rebuild. The organizations that treat this as an exposure-management program starting today are the ones that will not be caught flat when the machine stops being hypothetical.