The question everyone asks — and the answer they deserve
"When will a quantum computer break encryption?" is now one of the most searched questions in security, and most of the answers are bad. Half are fearmongering — a countdown to digital apocalypse next Tuesday. The other half are false precision — a confident year, usually one that conveniently aligns with a sales cycle.
The honest answer is more useful than either: no one can give you an exact date, and that is precisely why you should act now. Not because the sky is falling, but because the math of data secrecy doesn't need a date to tell you whether you already have a problem.
This post defines the threat carefully, explains why the timeline is genuinely uncertain, and then hands you the one calculation that actually drives a migration decision. Spoiler: it has nothing to do with predicting the quantum computer.
First, define CRQC — the only quantum computer that matters here
The threat is not "a quantum computer." Quantum computers already exist; they are not breaking your TLS. The threat is a specific machine: a cryptographically relevant quantum computer, or CRQC. A CRQC is one with enough stable, error-corrected logical qubits to run Shor's algorithm against the key sizes we actually deploy in real-world systems.
The reason today's headline qubit counts don't translate into a CRQC is error correction. Physical qubits are noisy; running Shor's algorithm against a real RSA or elliptic-curve key requires a large number of error-corrected logical qubits, each built from many physical qubits. The distance between a press-release qubit count and a CRQC is measured in that overhead — and it is enormous.
So when you read "quantum computer breaks encryption," mentally substitute "CRQC," and the question sharpens: not "do quantum computers exist?" (yes) but "when will one cross the threshold of cryptographic relevance?" (unknown).
What actually breaks — and what doesn't
Getting the cryptography exactly right matters, because the popular version is wrong in a way that leads to wasted effort and bad architecture.
Shor's algorithm breaks public-key cryptography: RSA, Diffie-Hellman, ECDH, and ECDSA. That means key exchange and digital signatures — the mechanisms by which two parties agree on a key and by which we prove who signed what. This is the real damage.
Grover's algorithm is the other quantum result people cite, and it is far weaker. Grover gives only a quadratic speedup against symmetric primitives, which effectively halves the security level. AES-256 therefore retains roughly 128-bit security and remains safe. AES-128 drops to about 64-bit effective security, which is marginal. Hash functions like SHA-384 and SHA-512 remain safe.
Why nobody can give you a date (and why that's the honest position)
Reaching a CRQC depends on a stack of open research problems: physical qubit quality, gate fidelity, the overhead of fault-tolerant error correction, and the pace of algorithmic improvement — any of which could move the goalpost in either direction. These are not knobs anyone can forecast to the year.
Expert surveys of quantum researchers reflect this honestly: they produce wide ranges and probability distributions, not a single deadline. That spread is not a failure of the experts; it is an accurate representation of genuine uncertainty.
Which is why any vendor who hands you a precise CRQC year should make you reach for your wallet protectively. Confident specificity here is a marketing tell, not a scientific result. The honest position — "we don't know the date, and here's how to plan without one" — is the one that survives scrutiny.
The reframe: you don't plan against the CRQC date at all
Here is the move that turns an unanswerable question into a planning exercise: stop trying to predict the CRQC, and plan against your own data instead. The uncertainty in the CRQC timeline is not a reason to wait — it is the reason to act, because you cannot manage a risk whose arrival you can't schedule by waiting for it to be scheduled.
The number that drives your decision is your data's secrecy lifetime: how many years a given piece of data must remain confidential. That number you actually know. A session token's secrecy lifetime is minutes. A signed software update's trust lifetime is the validity of its certificate. A medical record, a legal contract, a defense document, or a long-term encryption key may need to stay secret for decades.
Mosca's inequality: the only date-free math you need
Cryptographer Michele Mosca framed the risk as a simple inequality. Let X be the number of years your data must remain secret, Y the number of years it will take your organization to migrate to quantum-safe cryptography, and Z the number of years until a CRQC exists.
If X + Y > Z, you have a problem — your data will be exposed before the threat arrives, because you'll still be carrying it (or its signatures will still be trusted) when a CRQC shows up.
Notice what this does: it lets you reason about exposure even though Z is unknown. You don't need to pin down Z to a year. You only need to recognize that if your secrecy lifetime plus your migration time is long, then even a distant Z catches you. For long-lived data, the inequality is already satisfied today — regardless of where in its honest range the CRQC actually lands.
"Harvest now, decrypt later" makes today's date the deadline
The reason the secrecy-lifetime math bites now, and not in some future year, is the harvest-now-decrypt-later (HNDL) threat. An adversary doesn't need a CRQC today to attack your long-lived data today. They can record your encrypted traffic — or exfiltrate your encrypted data at rest — and simply store it, waiting for the day a CRQC can decrypt it.
For ephemeral data, HNDL is a non-event: nobody is warehousing your password-reset tokens to crack them in a decade. For long-lived data, it changes everything. The exposure clock started the moment that data crossed the wire, not on some future CRQC announcement date.
This is why "we'll migrate when quantum computers get closer" is a logically broken plan for long-secrecy data. By the time the threat is obviously close, the data you needed to protect has already been harvested. The only effective defense is to make today's traffic quantum-safe before it's captured.
The strongest signal we do have: CNSA 2.0 and the 2027-2033 timeline
If the CRQC date is unknowable, what should you anchor on? Policy. The clearest non-vendor signal is the U.S. CNSA 2.0 suite, which sets a federal transition timeline for national-security systems: PQC required for new systems starting January 2027, all existing systems by December 2030, and classical algorithms prohibited by December 2033.
Read that signal correctly. Governments do not impose multi-year, mandatory migration programs across their most sensitive systems to counter a threat they consider imaginary. They impose them because key exchange and signatures must be migrated well before any CRQC could plausibly arrive — accounting for exactly the X + Y lead time Mosca's inequality describes.
The CNSA 2.0 timeline is not a CRQC prediction. It is a migration deadline derived from secrecy-lifetime reasoning at national scale. It is the closest thing to an authoritative "act by" date you will find, and it points to this decade, not the next.
The tools are finalized — the work is migration
There's a comforting fact buried under all this uncertainty: the cryptography you migrate to is already standardized. In August 2024, NIST finalized FIPS 203 (ML-KEM, the key-encapsulation standard), FIPS 204 (ML-DSA, the primary signature standard), and FIPS 205 (SLH-DSA, the hash-based signature standard).
Be precise about what is and isn't final: FIPS 206 (FN-DSA, based on Falcon) is still in draft. HQC was selected as a backup KEM in March 2025 but is not yet a finalized FIPS standard. So the workhorses — ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures — are ready today; a couple of additional algorithms are still finishing the standards process.
That means the blocker is no longer "the standards aren't ready." The blocker is organizational: inventorying where you use vulnerable public-key crypto, prioritizing by secrecy lifetime, and migrating without breaking everything. That is an engineering and program-management problem, and it's solvable now.
What to actually do — migrate by secrecy lifetime, not by CRQC ETA
- Inventory your cryptography. You can't migrate what you can't see. Build a cryptographic bill of materials (CBOM) covering where RSA, ECDH, ECDSA, and Diffie-Hellman are used across your key exchange and signing.
- Sort your data by secrecy lifetime. Tag each data class with how many years it must stay confidential, and each signature with how long its trust must hold. This is the X in the inequality, and it's the number that drives priority.
- Migrate the long-lived and the trust-rooted first. Decades-secret data and long-validity signing keys are where X + Y > Z is already true. Ephemeral tokens can wait; certificate roots and archival data cannot.
- Build for crypto-agility. The algorithm set will keep evolving — FIPS 206 and HQC are still finishing. Architect so the next algorithm change is a configuration change, not a rebuild, and so you can run hybrid (classical + PQC) during transition.
- Verify, don't trust. Ask any PQC vendor — including us — for evidence: NIST ACVP conformance results, a tamper-evident digest, and exact algorithm coverage. 'Quantum-safe' on a slide is not evidence.
Where QNSP fits
QNSP is the flagship post-quantum cryptography platform from CUI Labs (CUI LABS PTE. LTD., Singapore) — built precisely for the migrate-by-secrecy-lifetime approach this post argues for. It is a full managed platform, not a single tool: PQC key management, an encrypted vault, SSE-X encrypted storage, vector search, AI orchestration, a tamper-evident audit trail, and a CBOM crypto-inventory service, all behind crypto-policy enforcement.
It spans 90 PQC algorithms across 14 families with dual-provider cross-verification (liboqs native C primary, @noble/post-quantum pure-JS secondary), so operations can be independently checked by two implementations. In the live platform, JWTs default to ML-DSA-44 and the audit trail to ML-DSA-65 — real PQC signatures, not labels. Crypto-policy tiers run from default through strict, maximum, and government (which restricts KEM to FIPS-203 ML-KEM-1024).
And consistent with the honesty this whole post is built on: the conformance evidence is public. ACVP results live at /verify/conformance, bound to a SHA-3-256 tamper digest that regenerates each release. To be clear about the limits of that claim — QNSP runs and publishes the official NIST ACVP test vectors, but that is not a NIST endorsement, certification, or CAVP/CMVP validation, and we don't present it as one.
The bottom line
When will a quantum computer break encryption? Honestly: nobody knows the date, the credible estimates are wide ranges, and anyone selling you a precise year is selling you fear. The threat is real and specific — a CRQC running Shor's algorithm against key exchange and signatures — but its arrival is genuinely uncertain.
That uncertainty is the argument for acting now, not for waiting. Because the decision was never about the CRQC date. It's about your data: if its secrecy lifetime plus your migration time exceeds the time until a CRQC, you're already exposed — and harvest-now-decrypt-later means the capture can happen today.
So don't migrate by CRQC ETA. Migrate by secrecy lifetime. The standards are finalized, the policy signal (CNSA 2.0, 2027-2033) points to this decade, and the only thing left is to do the work — starting with the data that has the longest to keep its secrets.