Filippo Valsorda, a cryptography engineer who spent years on Go’s standard library and Cloudflare’s security team, published an argument this week that the timeline for cryptographically-relevant quantum computers has compressed dramatically. His core claim: this is no longer a “might happen in 20 years” problem. It is a “might happen before your next major infrastructure cycle” problem.
The trigger is a series of recent research results. Google reduced the estimated logical qubit count needed to break standard elliptic curve cryptography — the foundation of most TLS connections and blockchain signatures. Separate research from Oratomic showed that neutral atom architectures could break 256-bit curves with around 10,000 physical qubits. These numbers are still beyond current hardware, but the trajectory matters: each research generation has moved the goalposts closer, and the physical qubit counts for fault-tolerant quantum computers have been revised downward repeatedly. Google has reportedly set an internal migration deadline of 2029. Valsorda compares the current research environment to nuclear fission research going classified in 1939, suggesting the most alarming advances may no longer be publicly disclosed.
For engineers building systems today, the relevant attack is “harvest now, decrypt later.” An adversary does not need a quantum computer to break your traffic today. They can capture encrypted traffic now and decrypt it retrospectively once capable hardware exists. Any data that needs to remain confidential for more than three to five years is already at risk from this strategy. That includes long-term secrets, authentication credentials with extended validity, and any protocol that does not offer forward secrecy.
The migration path is defined. NIST finalised its post-quantum standards last year: ML-KEM for key exchange (replaces ECDH), ML-DSA for signatures (replaces ECDSA). The practical blockers are not algorithmic — they are operational. Certificate infrastructure, HSM firmware, hardware attestation mechanisms, and TLS libraries all need coordinated updates. Blockchain ecosystems face a particularly difficult version of this problem: migrating wallets and on-chain signature schemes requires either a protocol fork or a user-initiated key rotation, and there is no obvious forcing function to drive participation.
Start with the threat model, not the algorithm. Identify which data in your systems needs long-term confidentiality, which authentication mechanisms have extended validity periods, and which connections involve parties that cannot easily be upgraded. Those are your immediate priorities. The 2029 deadline Google is working to is not a guarantee that CRQCs arrive then — it is an acknowledgment that waiting until the threat is confirmed is too late. Infrastructure migrations at scale take years.