I work at a quantum security company, so let me concede the obvious. You have been told the sky is falling for the better part of a decade, and it hasn't. Skepticism has become the default. Most of what gets written about the quantum threat is a vendor selling urgency or a lab selling a press release. This one is different.
Google Quantum AI published a paper on attacks against cryptocurrencies, co-authored with the Ethereum Foundation and Dan Boneh at Stanford. It is a blockchain paper. And the elliptic curve assumption the paper attacks is the same one holding up TLS, SSH, secure boot, code signing, firmware and microcode updates, e-passports, FIDO authenticators, and DNSSEC. It is in every constrained device you shipped this year and most of the ones you shipped a decade ago.
Here is the one sentence in the paper that should change how you think about your own PQC roadmap. The authors write that a successful public demonstration of Shor's algorithm against a 32-bit elliptic curve “should not be seen as a wake-up call to adopt PQC as much as a potential signal that PQC adoption has already failed.”
The milestone most of us are quietly waiting for is not a starting gun. It is a post-mortem.
Ask a security team when the real PQC work begins and you will get a defensible answer about inventory and vendor readiness. Ask what would cause them to accelerate, and you get something closer to the truth: ‘we'll know when it's time.’ Somebody will break something. It will be on the news.
The paper dismantles that assumption.
Progress is not linear.
Quantum computing is still in what the authors call an “era of ferment,” with a dozen competing hardware architectures and no dominant design. Advances arrive as discrete jumps, not as a tidy climb in qubit count. This means the distance between breaking a 32-bit curve and breaking a 256-bit one may be much shorter than the distance already traveled. Counting qubits is a comfortable metric precisely because it looks like a slope. It isn't one.
The finish line is moving toward you.
Google's new estimates put a break of 256-bit secp256k1 at roughly 1,200 logical qubits and fewer than half a million physical qubits on a planar superconducting architecture, in minutes. That is about a twentyfold reduction over the best previously published estimate, and it came from algorithms and error correction, not from new hardware. Hardware scaling gets the headlines. The algorithms, compilers and the error-correcting code have been doing at least as much work, and those gains compound.
Visibility only gets worse from here.
The authors expect transparency from quantum programs to decrease as they near commercial relevance. They raise the prospect of late entrants sprinting to a breakout, possibly assisted by industrial espionage. Their conclusion is something I keep coming back to: the first cryptographically relevant quantum computer may be detected on a blockchain before it is announced anywhere.
You are not going to get a memo.
Nobody circulated a date on which phishing stopped having tells. Voice cloning went from needing a research lab to needing thirty seconds of a keynote on YouTube. In early 2024, a finance employee at the engineering firm Arup transferred roughly $25 million after a video conference in which every other participant was synthetic. Callback verification had stopped working and there was no announcement. None of that came with a date attached. It got recognized in incident reports, one case at a time, after the fact.
In July, we watched AI-assisted cryptanalysis force a NIST candidate to withdraw. The capability that was a conference paper eighteen months ago is commodity tooling now, and the gap between "demonstrated" and "used against a client" has collapsed to something close to zero. Nobody sent a memo about that either.
Quantum has one difference. A CRQC does something else. It removes a mathematical assumption, and everything resting on that assumption becomes decorative at the same instant. There is no partial credit and no graceful degradation.
If observable milestones can't be your trigger, then your own readiness has to be. That flips the question. It stops being when do CRQCs arrive, which nobody can answer, and becomes how long would our migration actually take, which is answerable and entirely within your control.
So: how long would it take to replace elliptic curve cryptography in your slowest-moving system? And can you name that system?
Most teams can't, and that's the real finding here. Cryptography accumulates in places nobody enumerated. OT with a twenty-year service life. Appliances with roots of trust burned into silicon. Transitive dependencies four layers down. Certificates issued by a team that reorganized out of existence in 2019.
The Google paper's genuinely unsolvable problem is a version of this. Roughly 1.7 million bitcoin sit in dormant scripts that cannot be migrated, because the keys are lost and nobody can reach them. Those assets are simply going to be taken, eventually, by whoever gets there first. Enterprise cryptography is not lost in that sense. But you cannot migrate what you cannot find, and discovery is the long pole. It is also the least glamorous line item you will ever defend to a board, which is exactly why it keeps sliding.
It just doesn't start with a signal. It starts with an inventory.