Q Day Just Moved to 2029
Google and new quantum research say encryption could break within 3 years. What that deadline means for product teams shipping anything that stores sensitive data.
Three years. That's the window Google now believes separates us from a quantum computer capable of cracking the encryption protecting nearly every web transaction, password vault, and API secret in production today.
That's not a theoretical research horizon. It's a planning horizon — the kind that should be landing in your 2026–2027 roadmap conversations right now.
This week, two independent developments hit simultaneously. Ars Technica reported that Google has moved its internal "Q Day" estimate to 2029, far sooner than its previous projections suggested. And separately, new research published this week found that quantum computers need vastly fewer physical resources than previously thought to execute the kind of attacks that would shatter RSA and elliptic-curve encryption. Together, these stories don't just accelerate the timeline — they collapse the comfortable assumption that this is someone else's future problem.
The Double Compression Nobody Wanted
The conventional wisdom on quantum computing and encryption has always been: yes, it's coming, but it's decades away, and post-quantum cryptography (PQC) standards will be ready long before it matters. That logic was built on two assumptions — that the hardware would require enormous, error-corrected qubit arrays, and that NIST's finalized PQC standards (completed in 2024) would give organizations plenty of migration runway.
Both assumptions just got weaker in the same week.
The resource requirement finding is the more technically significant of the two. Prior estimates of the qubit counts needed to break 2048-bit RSA encryption ran into the millions of physical qubits. The new research suggests that number may be substantially lower, meaning milestones that felt safely distant are now within reach of near-term quantum hardware improvements. Google's 2029 estimate appears to incorporate similar thinking.
What this means practically: the migration window is not shrinking from 20 years to 15 years. It's compressing from "not our problem" to "someone on your team needs to own this by next quarter."
The "Harvest Now, Decrypt Later" Problem Is Already Your Problem
Here's the part of this story that most product teams miss: the threat isn't just future decryption of future data. It's the decryption of current data that adversaries are already collecting.
The "harvest now, decrypt later" (HNDL) attack strategy has been documented for years. Nation-state actors intercept and store encrypted traffic today, banking on quantum capabilities to decrypt it in the future. If your product handles anything sensitive — health records, financial data, authentication tokens, enterprise IP — data transmitted in the last several years may already be in someone's archive, waiting.
This means the effective exposure window isn't 2029 minus today. It's 2029 minus whenever your oldest sensitive data was last transmitted in an unprotected state. For some organizations, that calculation already lands in the past.
What a 2029 Deadline Actually Demands
NIST finalized its first set of post-quantum cryptographic standards in 2024, including ML-KEM (formerly Kyber) for key encapsulation and ML-DSA (formerly Dilithium) for digital signatures. The migration path exists. The standards are stable. The problem is that cryptographic migrations are genuinely hard organizational problems, not just engineering tasks.
A realistic PQC migration involves:
- Auditing your cryptographic surface area — TLS configurations, certificate authorities, JWT signing, API key schemes, data-at-rest encryption, third-party integrations. Most teams have no inventory of where RSA or ECC is actually in use.
- Dependency mapping — Many cryptographic dependencies live in libraries, cloud providers, and SaaS vendors, not in your own code. Your migration is partially conditional on vendor migration timelines you don't control.
- Hybrid transition architecture — Best practice currently recommends running classical and post-quantum algorithms in parallel during transition, which means temporary performance overhead and increased complexity.
- Regulatory and compliance alignment — Industries with long data-retention requirements (healthcare, finance, defense) face amplified exposure. Some are already operating under CISA guidance to begin PQC migration immediately.
None of this is a one-sprint project. For a mid-sized product team with a complex stack, eighteen months of effort is a reasonable minimum estimate for full migration.
The Uncomfortable Prioritization Question
Here's the tension product managers will face: quantum encryption risk sits in an awkward position on the prioritization grid. The probability of impact before 2029 feels abstract. The user-visible symptoms are zero until they're catastrophic. And the work competes with features that drive visible metrics.
This is exactly the failure mode that security debt exploits. The Ars Technica coverage this week notes that federal cyber experts famously called Microsoft's cloud a "pile of shit" and approved it anyway — a vivid example of what happens when institutional incentives override technical judgment. PQC migration faces the same organizational gravity.
The useful reframe for PMs: this isn't a security project, it's an infrastructure lifecycle project. Cryptographic algorithms have expected lifespans. RSA-2048 was already scheduled for eventual retirement. Q Day just made the retirement date legible. Framing it as planned infrastructure modernization — the same way you'd frame IPv6 migration or TLS 1.3 adoption — changes the prioritization conversation from "why does this matter now" to "when do we start."
What to Do This Quarter
You don't need a full migration plan before end of Q2. But you do need to start the audit phase now, while there's runway.
- Commission a cryptographic inventory — Ask your infrastructure and security leads to document every place RSA, ECC, or Diffie-Hellman key exchange is in use, including dependencies and third-party services.
- Check your cloud provider's PQC roadmap — AWS, Google Cloud, and Azure all have published timelines for PQC support. Know what's available now versus what's on their roadmap.
- Identify your highest-sensitivity data categories — For HNDL exposure, not all data is equal. Know what an adversary would most want to decrypt in three years.
- Book a 2026 planning item — Even a discovery sprint before end of year keeps this on the roadmap rather than letting it drift into the category of "important but never urgent."
The teams that handle this well won't be the ones with the best cryptographers. They'll be the ones where a PM asked the right question eighteen months before the crisis.
Sources: Quantum computers need fewer resources to break encryption — Ars Technica; Google moves Q Day estimate to 2029 — Ars Technica; Federal experts called Microsoft's cloud a 'pile of shit', approved it anyway — Ars Technica; CISA Post-Quantum Cryptography guidance