When is Q-Day? On its face it’s a reasonable question: one date, one answer. But it contains two questions: what breaks, and when. Mix the two together and you get most of the bad timelines and wasted migration spend. By the end you’ll be able to answer both halves without falling for the two confusions that drive the bad numbers: Shor versus Grover, and physical versus logical qubits. Get either split wrong and you migrate primitives that were never at risk. First the scope, then the date. Both answers matter, but neither sets the schedule. Why the deadline exists at all is a compliance question, not a physics forecast.
What actually breaks on Q-Day, and what survives?
On Q-Day, a cryptographically relevant quantum computer runs Shor’s algorithm to break the public-key cryptography behind key exchange and signatures: RSA, Diffie-Hellman, DSA, ECDH and ECDSA. Symmetric primitives survive. Grover’s algorithm gives AES only a square-root speedup, so AES-256 keeps roughly 128-bit security and SHA-2 and SHA-3 stay adequate.
Why Shor breaks RSA but not AES
Q-Day is the moment a cryptographically relevant quantum computer (CRQC) first breaks deployed public-key cryptography in practice: a code-breaking event, a machine that decrypts real traffic. A physics demonstration does not clear that bar. Shor’s algorithm is the mechanism: factoring and discrete logarithms hide a repeating period, which Shor finds, collapsing the problem.
The casualty list is short, and it is official. US government guidance enumerates the vulnerable algorithms, and Australia’s cyber guidance says one quantum attack defeats all traditional asymmetric cryptography. They sit in your TLS handshakes, SSH, VPNs, certificates, code signing and signed firmware.
What survives, and why you don’t need to double AES keys
Grover’s algorithm is why symmetric crypto gets a pass. It only searches, buying a square-root speedup rather than the exponential one Shor delivers. That means no symmetric key sizes need to change at all, and doubling your AES keys is unnecessary.
That leaves a mental model you can take to your team. Everything doing key exchange and signatures is in scope; everything doing bulk encryption with a 256-bit key is not. AWS’s guidance to executives puts it: data encrypted at rest with standard 256-bit symmetric encryption is not vulnerable to a quantum computer.
None of the replacements change that model; what changes is the underlying problem. Post-quantum cryptography (PQC) is worth defining by contrast. PQC is cryptography built on problems hard for classical and quantum machines alike, and it runs on ordinary classical hardware. Migration is a software and infrastructure problem; you are not buying quantum machines.
ML-KEM and ML-DSA rest on structured lattice problems with no known periodicity for Shor to exploit. The error terms in ML-KEM hide the secret, removing the structure that classical and quantum shortcuts rely on. They’re structurally different from what they replace.
The practical consequence is that signatures lag. Key exchange happens per session and can be swapped silently; signatures live in certificates and firmware images with lifetimes measured in years. That’s a slower problem worth its own treatment.
What does a cryptographically relevant quantum computer require, and is the date closer to 2029 or 2050?
Scope settled, the question becomes: when does the machine that does this actually arrive?
A cryptographically relevant quantum computer needs millions of physical qubits at realistic error rates, or tens of thousands of high-fidelity ones under favourable assumptions, plus error correction and coherence long enough to run Shor’s algorithm. Estimates range from roughly 2030 (aggressive) to 2050 (conservative); no such machine exists as of 2026.
Physical qubits versus logical qubits
Start with what a CRQC is: a fault-tolerant machine that runs Shor’s algorithm at cryptographic scale, error-corrected, for long enough. Logical qubits, the error-corrected units assembled from many noisy physical qubits, are the deciding factor. Breaking RSA-2048 needs roughly 1,400 logical qubits held stable through millions of gate operations; today’s machines are still noisy devices whose errors accumulate across every operation.
The 10,000-qubit figure, read carefully
The 10,000-qubit figure is often misread. It comes from a March 2026 preprint by Oratomic, Caltech and UC Berkeley, and it describes a space-time trade-off under stated assumptions. At 10,000 qubits their platform would need 120 years to crack RSA-2048; the faster design solves it in 97 days but needs 100,000 qubits. It isn’t peer-reviewed.
RSA-2048 has fallen from roughly 20 million noisy qubits in 2019 to under a million, then 100,000, now a 10,000-qubit floor. Falling estimates shrink the requirement; they say nothing about whether the machine can be built.
So when? The answer is a probability range. The Global Risk Institute’s expert survey puts the odds at one in four by 2030 and one in two by 2035. A Monte-Carlo forecast extends into the 2050s. Three things drive the spread: error-correction overhead, engineering scale-up, and whether an estimate describes a physics milestone or a usable machine.
NEC is the sceptic’s best case. It spent roughly 30 years on quantum hardware, demonstrated the first superconducting solid-state qubit in 1999, then quietly exited in 2026 after concluding commercialisation was too far off. A three-decade incumbent leaving is evidence the path is harder than the decks suggest.
It also hands you a hype test. A sell signal is a vendor selling quantum-safe products on a timeline that assumes a machine nobody has demonstrated. Cloudflare and Google publish engineering consensus and error-correction roadmaps in the open.
None of this is an argument to wait; the compliance clock behind the date runs independently of the hardware forecast. The decision is how long your data has to stay secret. Harvest-now-decrypt-later means data recorded today can be decrypted once a machine exists, pulling your real deadline earlier.
Strip the question down and you’re left with two answers. The scope is narrow: key exchange and signatures fall, while AES-256, SHA-2 and SHA-3 survive. The date is a probability spread from 2030 to 2050, gated by error-corrected logical qubits nobody has demonstrated.
Your migration surface is certificates, TLS handshakes, code signing, VPNs, SSH and signed firmware; bulk data under 256-bit keys sits outside that scope. The deadline that binds is data shelf life, and waiting for certainty has a cost: the data is already being recorded.
The next step is turning that into a plan: post-quantum readiness as a programme, and harvest-now-decrypt-later for the exposure that sets the real clock.
Frequently Asked Questions
Does quantum computing threaten data at rest in cloud storage and backups?
Check how the keys were protected, not just the cipher. Data at rest encrypted with AES-256 under a key you hold is not directly at risk, because the bulk cipher survives. But cloud storage and backups usually wrap those data keys with RSA or elliptic-curve key wrapping, and that layer falls. If the wrapped key is exposed next to the ciphertext, the archive is exposed too.
What is harvest now, decrypt later, and does it affect me today?
Harvest now, decrypt later means recording encrypted traffic today and decrypting it once a cryptographically relevant quantum computer exists. It matters when confidentiality must outlast the machine: health records, legal advice, intellectual property, source code, government archives. It does not threaten a session that expires in minutes. The practical question is how long your data must stay secret, not when Q-Day arrives.
Is it true that quantum computers might never break RSA?
No. Shor’s algorithm is a proven result, and RSA and elliptic-curve cryptography have no known classical defence against it once a suitable machine runs it. What remains uncertain is engineering and timing, not mathematics. A single cryptographically relevant machine breaks the widely deployed primitives, so there is no partial credit and no version of the future where RSA keeps working at scale.
Would a longer RSA key, say 4096 or 8192 bits, buy me time?
Not meaningfully. Shor’s algorithm scales polynomially with key size, so moving from RSA-2048 to RSA-4096 raises the qubit requirement by a modest factor rather than making the problem safe. You would pay a real performance and compatibility cost for a few extra years at most. Replacing the algorithm with ML-KEM or ML-DSA is the only durable answer.
Which parts of my stack should I look at first?
Start with a cryptographic inventory, because you cannot migrate what you cannot see. Prioritise anything doing key exchange: TLS termination points, VPN concentrators, SSH, and the certificate authorities behind them. Then map signatures, including code signing and firmware, which carry longer trust lifetimes. Key exchange comes first because hybrid options are deployable now and exposure begins the day traffic is recorded.
Why are signatures harder to migrate than key exchange?
Key exchange happens per session, between two endpoints that can negotiate a new algorithm without anyone noticing. Signatures live inside certificates, firmware images, signed code and trust stores with lifespans measured in years or decades, often verified by devices that cannot be patched. Changing a signature algorithm means reissuing credentials and coordinating an entire ecosystem, which is why it always lags key exchange.
Can I start using post-quantum cryptography today, or is it still experimental?
You can start now. NIST published the first post-quantum standards in 2024, and hybrid key exchange combining X25519 with ML-KEM is already shipping in mainstream browsers and content delivery networks. ML-DSA signatures are standardised and deployable, though tooling and certificate ecosystem support are still maturing. This is production technology, not a research experiment, and hybrid deployment keeps you safe if either half is later broken.
Will post-quantum algorithms slow my systems down?
The overhead is real but modest, and it sits mostly in handshake size rather than CPU. ML-KEM key exchange is fast, while ML-DSA signatures and public keys are larger than their elliptic-curve equivalents, which adds bytes to certificates and handshakes. Hybrid modes carry both a classical and a post-quantum share, so sizes roughly double. Measure against your own latency budgets before assuming a problem.
Does this threaten Bitcoin and blockchain wallets?
Partially. Bitcoin and similar chains authenticate spends with ECDSA, so a cryptographically relevant quantum computer could in principle derive a private key from an exposed public key and spend the coins. Addresses that have never spent are less exposed, while reused addresses and coins sitting on spent outputs are the obvious targets. Custodial wallets shift the risk to your provider’s own migration plans.
Why did NEC stop building quantum computers, and does that mean the threat is overblown?
NEC spent roughly 30 years on quantum hardware and exited in 2026, concluding that commercialisation was too far away to justify continued investment, while keeping its quantum-safe networking work. It is a serious signal about engineering difficulty and commercial uncertainty. It is not evidence that the threat is false: one company’s investment decision does not change what Shor’s algorithm does to RSA.
What would have to happen for the 2030 estimate to be right?
For 2030 to be right, someone would need to demonstrate error-corrected logical qubits at the thousands scale, with fidelities and coherence good enough to run Shor’s algorithm to completion, and then scale manufacturing quickly. Today’s devices demonstrate logical qubits only in small numbers. The aggressive end of the range assumes several engineering breakthroughs arrive close together, which is possible but not the base case.
Do I need to replace my SHA-256 password hashes?
No. SHA-256 and SHA-3 are not broken by Shor’s algorithm, and Grover’s quadratic speedup only halves the security margin, which leaves both with room to spare for password hashing. Your password store is far more likely to fall to weak passwords, reuse or a stolen credential database than to a quantum computer. Keep using memory-hard hashing such as Argon2id and spend the effort there.
