If your organization relies on RSA or elliptic curve cryptography (ECC) to protect data, authenticate systems, or sign software — and virtually every organization does — you just lost several years of planning runway.
Last week, Google set a 2029 internal deadline to complete its migration to post-quantum cryptography, years ahead of NIST’s 2035 guideline and the NSA’s 2031 target. The company cited faster-than-expected advances in quantum hardware, error correction, and factoring estimates. In plain terms: the machines that could break today’s encryption are getting real, faster than anyone outside Google’s labs expected.
This isn’t a vendor selling fear. Google operates the world’s most widely used browser, one of two dominant mobile operating systems, and a major cloud infrastructure platform. When that organization says its own risk calculus demands migration by 2029, it’s a signal the rest of the industry can’t afford to ignore.
The numbers behind the shift
The trajectory tells the story. In 2012, breaking a 2,048-bit RSA key was estimated to require a quantum computer with one billion physical qubits. By 2019, that dropped to 20 million. In 2025, Google’s own researchers showed it could be done with one million noisy qubits in under a week.
Google also made an underreported but critical shift in its threat model: it’s now prioritizing PQC migration for digital signatures and authentication, not just encryption. Signature keys are long-lived, deeply embedded, and far harder to rotate. When those break, the damage is systemic — not a single data breach, but a collapse of trust across infrastructure.
Meanwhile, the Keyfactor Digital Trust Digest: Quantum Readiness Edition found that 48% of organizations are not prepared to confront quantum threats, and 91% lack a formal PQC migration roadmap according to the Trusted Computing Group. Those numbers were already concerning. After Google’s announcement, they’re alarming.
Keyfactor’s view
I’ve been making this case for over a year: Q-Day is a myth — not because the threat isn’t real, but because the severity is not compounded into a single day. It’s a slow accumulation of risk that’s already underway. Adversaries are harvesting encrypted data now. Furthermore, new threats continue to present themselves; recently, there has been increased acknowledgment that Trust Now, Forge Later presents considerable risk to command and control systems that rely on public key authentication and encryption. The question was never if Q-Day arrives, but whether your data would still be safe when it does.
Google’s announcement validates the Keyfactor point of view. The regulatory landscape was already converging: CNSA 2.0 requires quantum-safe algorithms for National Security Systems by January 2027, OMB M-23-02 mandates annual cryptographic inventories, and the EU’s 21-state joint statement targets PQC transition of sensitive systems by 2030. None of those deadlines moved. What has changed is the shift from theory and technical debate to planning and action to ensure business continuity and cyber resilience.
The real question: can your infrastructure adapt?
The conversation needs to shift from timelines to action. If you wait until the deadline to plan, you have already lost.
Whether Q-Day is 2029 or 2035 matters less than whether your infrastructure can respond when the timeline becomes clear — or when it shifts again, as it just did. Quantum readiness is not a one-time migration. NIST plans to issue a draft standard with the HQC algorithm soon, with final standardization expected in 2027. FIPS 206 is in draft. New standards will emerge, and some current selections may be revised.
This is why cryptographic agility matters more than any single algorithm choice. It’s the ability to evolve your cryptographic infrastructure continuously — swap algorithms, update policies, adapt to new standards — without redesigning applications or replacing hardware. Organizations that build this capability now are preparing for PQC while building infrastructure that absorbs whatever comes next.
The alternative is exactly the pattern that got us here: RSA and ECC embedded so deeply that replacing them becomes a multi-year, multimillion-dollar project. The lesson of this moment isn’t “migrate to ML-KEM as fast as possible.” It’s “stop building brittle cryptographic infrastructure.”
Where to start
If Google’s announcement is the catalyst that gets your organization moving, start with visibility.
- Map everything first. You can’t migrate what you can’t see. Build a complete inventory of every algorithm, certificate, and cryptographic dependency across your environment. This is what every major regulatory framework begins with.
- Assess risk holistically. Don’t just look at algorithms and instead, prioritize by the intersection of algorithm vulnerability system criticality with data sensitivity and longevity. Pay particular attention to long-lived signature keys; Google’s threat model shift should inform yours.
- Design for agility, not just compliance. Build systems that can swap algorithms continuously, not once. If you hardcode today’s best answer into tomorrow’s infrastructure, you’ll be back here over and over again. Building once correctly is the less expensive option over time.
- Don’t wait for timeline certainty. The SHA-1 to SHA-2 migration took 12 years. The PQC transition is bigger, and if Google is right, on a shorter clock. Every previous cryptographic transition has taught the same lesson: the organizations that moved early moved cheaply.
The bottom line
Google didn’t move Q-Day. What Google did is tell the world that the organization with the deepest visibility into quantum progress believes 2029 is the right planning horizon. With Google and IBM both building quantum computers and sharing similar timelines, this might be the best indication we have of Q-Day’s timing, given their open communications.
The clock didn’t start ticking last week. It’s been ticking. Google just made it louder.
Take the first step toward quantum readiness. See how Keyfactor helps organizations manage their cryptographic posture — from discovery and inventory to PQC migration planning.
