What is a cryptographically relevant quantum computer?
A cryptographically relevant quantum computer (CRQC) is a quantum computer powerful and stable enough to break the public-key cryptography (RSA and elliptic-curve) that secures the modern internet. Not every quantum computer qualifies. Today's machines are experimental and error-prone; a CRQC is the specific threshold at which quantum hardware can run Shor's algorithm at the scale needed to factor real encryption keys.
The term matters because it cuts through the noise. Headlines announce new "quantum breakthroughs" constantly, and it is easy to conflate any progress with imminent danger. The milestone that should actually drive enterprise planning is not "quantum computing exists" (it already does) but "a cryptographically relevant quantum computer exists." The gap between those two states is precisely the window enterprises must use to prepare.
What does it take to be "cryptographically relevant"?
Breaking RSA-2048 with Shor's algorithm requires thousands of stable, error-corrected logical qubits. That is the number that matters, and it is very different from the qubit counts in press releases. Those headline figures count physical qubits, which are noisy and error-prone. Quantum error correction spends many physical qubits to produce a single reliable logical one, so thousands of logical qubits may require millions of physical qubits.
Three things must come together, not just one: enough logical qubits, low enough error rates, and long enough coherence time to complete the computation before the quantum state decays. Progress on all three is real, but each is a distinct engineering challenge, and error rates in particular remain the central barrier. This is why a machine with an impressive physical-qubit count can still be nowhere near cryptographically relevant.
Why is the qubit-count headline misleading?
Because it measures the wrong thing. A vendor announcing "1,000 qubits" is almost certainly counting physical qubits with meaningful error rates, useful for research, but far from what breaking encryption demands. The honest metric is error-corrected logical qubits sustained long enough to run Shor's algorithm against a 2048-bit key, and by that measure the world is still well short.
For enterprise leaders, the takeaway is to treat sensational headlines with calm skepticism while treating the underlying trajectory with serious respect. The danger is neither panic nor complacency, but planning: assuming the threshold will be crossed and ensuring you are ready before it is.
When will a CRQC arrive?
No one can give a certain date, and any source that claims one is guessing. Expert surveys place a meaningful probability of a CRQC within roughly 10 to 15 years, with a non-trivial chance sooner and some chance later. For a deeper look at the timeline debate, see when will quantum computers break encryption.
But the arrival date is the wrong number to plan around, for two reasons. First, migration takes years, so you must act long before the threshold. Second, and more unsettling, a CRQC will not announce itself. The first one may be built quietly in a nation-state laboratory, its existence classified. Enterprises waiting for public confirmation would be waiting for an event that, by design, may never be announced.
Why does the CRQC threshold change enterprise planning?
Because the combination of long migration times and a silent, uncertain arrival means you cannot afford to react: you have to pre-empt. The harvest-now-decrypt-later threat compounds this: adversaries are capturing encrypted data today specifically to decrypt it once a CRQC exists. If your data must stay secret for a decade, the clock is already running, regardless of when the CRQC actually appears.
The formal way to reason about this is the Mosca inequality, which weighs how long your data must stay secret and how long migration takes against the uncertain threat horizon. For long-lived data, the math often already fails, meaning the responsible move is to start now, not when the threshold is confirmed.
What should enterprises do before a CRQC exists?
Treat the CRQC as a "when, not if" event and work backward from it. Inventory your cryptography so you know where RSA and ECC are used. Prioritize long-lived and high-value data, the assets a future CRQC would most damage. Begin migrating to NIST's post-quantum standards in hybrid mode, starting with the highest-risk systems. Build the crypto-agility to swap algorithms again if needed.
The organizations that wait for proof that a CRQC exists will find themselves defending data that was harvested years earlier, an unwinnable position. The ones that plan for the threshold in advance turn an uncertain future threat into a managed program on their own timeline.
