TheMurrow

Google Put ‘Q‑Day’ on the Calendar: The ‘Steal Now, Decrypt Later’ Trap That Could Make Your 2026 Backups Useless by 2029

Google’s unusually explicit 2029 post‑quantum migration target reframes quantum risk as a present-day confidentiality problem—because attackers can harvest encrypted data now and decrypt later. The real danger isn’t a dramatic 2029 break; it’s the quiet breach that becomes readable years after you thought it was contained.

By TheMurrow Editorial
April 10, 2026
Google Put ‘Q‑Day’ on the Calendar: The ‘Steal Now, Decrypt Later’ Trap That Could Make Your 2026 Backups Useless by 2029

Key Points

  • 1Track Google’s 2029 PQC target as a planning deadline, not a prophecy—migration lead times are the real constraint.
  • 2Assume “steal now, decrypt later” is already underway: long‑lived encrypted backups and archives can become future plaintext.
  • 3Separate confidentiality from signatures: protect long‑term secrets now, and harden trust infrastructure before forged signatures become feasible.

Google has started doing something rare for a company that usually speaks in horizons, not deadlines: it put a year on quantum risk.

On March 25, 2026, Google published a company-wide timeline that aims to complete its migration to post‑quantum cryptography (PQC) by 2029. It wasn’t a vague “someday” warning. It was a date stamped onto an uncomfortable idea: the cryptography that quietly holds together identity, software updates, banking, cloud logins, and confidential data may not fail all at once—but it could fail fast enough to upend operational security.

The industry has a nickname for the moment when quantum computers become dangerous to modern encryption: Q‑Day. It’s shorthand for the arrival of a cryptographically relevant quantum computer (CRQC)—a machine capable of breaking widely used public‑key systems like RSA and elliptic‑curve cryptography (ECC) quickly enough to matter in the real world.

Google’s 2029 target doesn’t mean Q‑Day is scheduled like a product launch. It does mean one of the world’s most technically literate organizations has decided the margin for waiting is shrinking—especially because the most damaging attacks don’t begin in 2029. They begin now.

“The most dangerous quantum breach may be the one you already suffered—because the data is sitting somewhere, waiting for the math to catch up.”

— TheMurrow

Q‑Day, explained: not the end of encryption, the end of today’s assumptions

The phrase “Q‑Day” invites melodrama, but the risk is more specific than the nickname suggests. A cryptographically relevant quantum computer wouldn’t “break the internet.” It would break particular cryptographic problems that today’s security relies on—most notably the hard math behind RSA and ECC.

Public‑key cryptography does two crucial jobs. First, it enables confidentiality (agreeing on keys securely so data can be encrypted). Second, it enables digital signatures (proving identity and integrity—who signed the software update, who issued the certificate, who authorized the transaction). Those functions underpin the mundane foundations of digital life: certificate chains, firmware updates, authentication flows, code signing, and secure messaging.

Google’s March 25, 2026 post draws a sharp distinction between these two timelines. It argues confidentiality risk is “relevant today” because attackers can collect encrypted traffic and files now and decrypt later. By contrast, signature risk is a “future threat”—but one that forces preparation before the threat arrives, because signatures secure the systems you would need to patch in an emergency.

Why Google’s decision to put “2029” in print matters

Google’s post doesn’t claim quantum computers will definitely break RSA/ECC in 2029. It says the company is setting a migration timeline to 2029 because of three converging trends:

- Quantum hardware progress
- Quantum error correction progress
- Improved resource estimates for quantum attacks

A date in a blog post is not a prophecy. It is a risk decision: a statement that the cost of migrating late has begun to outweigh the cost of migrating early.

“A date isn’t a forecast. It’s a budget for regret—and Google just published theirs.”

— TheMurrow

The “steal now, decrypt later” trap: why tomorrow’s quantum computer threatens today’s data

The quantum threat that matters most to many organizations is not a science‑fiction heist in 2029. It’s the breach you never fully contained in 2026.

Security researchers have long described “harvest now, decrypt later” (HNDL)—also called “store now, decrypt later” or “steal now, decrypt later”. The play is simple: exfiltrate encrypted data today, keep it, and wait for the cryptography to become solvable. Wikipedia’s overview frames it plainly: the attacker’s advantage is time.

Google’s 2026 timeline elevates that idea into corporate urgency. If confidentiality is already at risk, then migration is not merely about the day CRQCs arrive. Migration is about limiting the value of what attackers can collect before then.

The backup problem nobody wants to talk about

Backups and archives are a perfect match for HNDL. They are:

- Long‑lived (kept for years for compliance, disaster recovery, or simple habit)
- High‑value (containing customer PII, health data, contracts, source code, credentials)
- Often treated as set‑and‑forget (encrypted once, then assumed safe indefinitely)

Even without a public post‑mortem tied to quantum specifically, the logic is straightforward: a stolen archive does not need continuing access to your network. If the encryption protecting it becomes breakable later, the attacker wins later—quietly, and with a completeness that incident response rarely anticipates.

That is the chilling operational nuance: a breach that looks “contained” today can mature into a catastrophe later without any new intrusion. The risk does not require attackers to return. They just need the math to change.

Practical implication for readers

If your organization stores data with a confidentiality life of 5–10+ years, HNDL flips the planning frame. You are not securing data for the next quarter. You are securing it against the future capability of adversaries who may already have a copy.

Key Insight

HNDL turns “encrypted exfiltration” from a contained incident into a deferred breach: the attacker’s only remaining dependency is future compute.

Why the estimates keep falling: quantum progress isn’t only about hardware

Corporate security planning often assumes quantum risk advances at the pace of visible quantum hardware milestones. Google’s recent messaging pushes a different—and more unsettling—point: the threat can accelerate through improved algorithms and error correction, even if hardware progress looks incremental.

In May 2025, Google published “Tracking the Cost of Quantum Factoring,” describing how estimates for the resources needed to break RSA‑2048 have dropped dramatically compared with older assumptions. The emphasis was not hype; it was arithmetic. Better circuits, better compilation, better error correction, and better modeling can compress timelines without a single qubit being shipped.

Then came another jolt in 2026 reporting. Ars Technica covered Google‑linked research that highlights lower‑than‑expected resources for attacking ECC, the system used widely across security protocols and heavily associated in the public mind with cryptocurrency.

Key numbers—and why they’re not a countdown clock

Several specific figures have circulated in that reporting wave:

- < ~500,000 physical qubits (fault‑tolerant) to attack ECC‑256 in minutes in some models
- Around 1,200–1,450 logical qubits in certain circuit designs
- Tens of millions of Toffoli gates in those designs (a measure of quantum circuit cost)

Those are not promises. They are estimates under assumptions: error rates, architecture choices, connectivity, the practicality of sustained fault tolerance, and the real engineering of error‑corrected systems. Still, estimates moving downward is exactly the kind of change that forces large organizations to revise risk planning earlier.

Some preprints argue even more aggressive paths using alternative error‑correction approaches, such as LDPC‑code‑based architectures. Ars Technica notes those proposals carry major engineering caveats, and the field remains full of uncertainty. That uncertainty cuts both ways: it undermines precise prediction, but it also weakens the comfort of “not in my career.”

“The quantum threat is not a single breakthrough. It’s a steady reduction in the cost of breaking what we assumed was expensive forever.”

— TheMurrow
< ~500,000
Physical qubits cited in some models to attack ECC‑256 in minutes—an estimate under assumptions, but a sign the cost curve is moving.
1,200–1,450
Logical qubits in certain circuit designs discussed in 2026 reporting—illustrating how improved designs can shrink resource requirements.
Tens of millions
Toffoli gates in those designs—a quantum circuit “cost” measure that helps translate cryptanalytic ideas into engineering constraints.

Google’s 2029 PQC migration timeline: what it says—and what it doesn’t

Google’s March 25, 2026 post is unusually explicit: “We’re setting a timeline for post‑quantum cryptography migration to 2029.” That sentence is the headline, but the more revealing content is how Google separates immediate confidentiality concerns from longer‑lead signature concerns.

Confidentiality: the problem is already operational

Google says confidentiality risk is relevant today because of HNDL collection. That framing matters because it implicitly treats encrypted data as an asset with a shelf life. If your data must remain confidential for many years, the “encryption strength” you need is not what resists today’s attackers—it’s what resists tomorrow’s.

For readers, the practical takeaway is uncomfortable but clear: if an attacker can capture encrypted sessions or archives now, your future security posture depends on whether you migrate before the attacker’s decryption capability arrives, not before the attacker’s intrusion capability arrives.

Digital signatures: a future threat with present‑day deadlines

Google also calls signature risk a future threat, but it underscores why migration must happen in advance. Digital signatures underpin:

- Identity and authentication services
- Software updates and code signing
- Certificates and trust infrastructure

If CRQCs can forge signatures, the consequences can cascade. Trust chains can be imitated. Updates can be faked. Systems designed to recover from breaches can be turned into distribution channels for them. That is why Google’s internal threat modeling prioritizes migration for authentication services.

Google’s post is careful not to present 2029 as the day quantum arrives. The point is that large systems need years to migrate safely, test interoperability, and avoid outages. A date reflects the time required to change the aircraft while it’s in flight.

What 2029 really signals

Google’s 2029 target is not a prediction of Q‑Day.
It’s a statement that safe migration takes years.
It’s a warning that confidentiality risk exists before quantum capability does.

The enterprise reality: cryptography migrations fail slowly, then all at once

Security teams tend to treat cryptography as plumbing: vital, invisible, and addressed only when it leaks. PQC migration is the opposite. It is a coordinated change across protocols, libraries, certificate lifecycles, hardware security modules, devices, and third‑party vendors.

Google’s decision to publish a 2029 target is, in part, an admission about organizational physics. Big migrations take time even when everyone agrees. They take longer when dependencies sprawl across contractors, legacy systems, embedded devices, and procurement cycles.

Multiple perspectives: urgency versus credibility

There is a legitimate debate about how to communicate quantum risk. Critics worry that dates can become self‑fulfilling panic, driving rushed deployments or costly overhauls before standards and implementations mature. Supporters argue that without dates, organizations do what they always do with long‑range threats: postpone until the threat becomes immediate—at which point it is too late for safe, measured migration.

Google’s timeline lands on a pragmatic middle ground. It does not claim certainty. It claims planning responsibility. The underlying message is not “quantum will break everything in 2029.” It’s “if we wait until quantum breaks something, we will not be able to fix it in time.”

Real‑world example: a certificate ecosystem with long tails

Even outside quantum, certificate and signature systems demonstrate the long tail problem. Root certificates and long‑lived device firmware can remain in service for years. Update mechanisms may be rarely exercised until crisis. In a post‑quantum scramble, the systems you need to update might be the ones least capable of being updated quickly.

That’s why signature migration is not merely a cryptographic swap. It is an operational resilience project.

What readers should do now: a pragmatic quantum-readiness checklist

Google’s timeline is not a commandment for every organization. It is a signal that the “someday” category has moved into the “plan now” category. The most useful response is neither panic nor complacency, but inventory and prioritization.

Step 1: Map your “confidentiality lifetime”

Start with data that must remain secret for years. Identify where it lives, how it’s encrypted, and who can access copies. Pay special attention to archives and backups.

Questions worth answering:

- Which datasets have a confidentiality requirement beyond 3–5 years?
- Where are encrypted copies stored offsite or with vendors?
- Which systems use RSA/ECC for key exchange or key wrapping?

Step 2: Separate encryption from signatures in your planning

Google’s framing is helpful here.

- For confidentiality, assume adversaries may already be collecting ciphertext.
- For signatures, focus on systems of trust: authentication services, update pipelines, certificate authorities, code signing, and identity.

Treat these as distinct workstreams with different testing burdens and rollback risks.

Step 3: Demand PQC roadmaps from vendors—now, not later

Many organizations cannot migrate cryptography faster than their vendors can support it. Procurement should start asking specific questions:

- Which PQC algorithms will you support, and when?
- How will you handle hybrid modes during transition?
- What is your plan for certificate lifecycles and firmware updates?

The value here is less about the exact answers and more about forcing visibility into the dependency chain.

Step 4: Assume “harvest now” is already happening

HNDL is not a speculative new tactic. It’s a rational strategy described widely in the security community. If your incident response model treats encrypted exfiltration as “safe because encrypted,” quantum risk changes the meaning of “safe.”

Quantum-readiness, in four moves

  1. 1.Map long-lived secrets and where encrypted copies live—especially backups and archives.
  2. 2.Separate confidentiality work (HNDL risk now) from signature work (trust infrastructure risk later).
  3. 3.Press vendors for specific PQC support timelines, hybrid plans, and certificate/firmware update strategies.
  4. 4.Update incident response assumptions: encrypted theft can become plaintext later without a second intrusion.

The harder question: what happens to trust when signatures become forgeable?

Confidentiality is the headline most readers recognize: intercepted secrets made readable. But the deeper systemic risk is what forged signatures do to trust.

A world where signatures can be forged is a world where authentication becomes suspect. Software updates become questionable. Certificates become uncertain. Recovery becomes harder because the usual “trusted channel” assumptions break.

Google’s timeline highlights this explicitly by describing signatures as a future threat that still demands early migration. That is a subtle point, and it deserves emphasis. Signature systems are not just security features; they are the way modern systems know what to believe.

The public debate about quantum often gets stuck on a single question—“When will it happen?”—as though Q‑Day is a singular event. Google’s 2029 target encourages a better question: “How long will it take to restore trust once it does?”

That’s the real reason serious organizations pick dates. Not because the future is certain, but because recovery is slow.

Editor’s Note

Signature systems aren’t just another crypto primitive: they’re the trust rails for updates, identity, and recovery. If those rails fail, everything downstream becomes harder to repair.

TheMurrow takeaway: treat 2029 as a planning constraint, not a prophecy

Google’s choice to name 2029 is a marker of institutional seriousness, not clairvoyance. The supporting reasons—progress in hardware, error correction, and falling resource estimates—make the threat harder to dismiss as a distant academic concern. The specific numbers reported in 2026 about ECC attack costs, along with Google’s 2025 factoring analysis, show a consistent trend: what once looked impractically expensive keeps getting cheaper.

Still, readers should resist simplistic narratives. Quantum timelines remain uncertain. Estimates come with caveats. Engineering reality is unforgiving. None of that is a reason to wait.

The practical posture is clear-eyed preparation: identify long-lived secrets, stop assuming encrypted archives are future-proof, and treat signature infrastructure as mission-critical. Google’s 2029 target is a reminder that cryptography isn’t merely math. It’s the brittle social contract between machines—and it only works as long as the assumptions remain true.

“Google’s choice to name 2029 is a marker of institutional seriousness, not clairvoyance.”

— TheMurrow
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering technology.

Frequently Asked Questions

What is Q‑Day, exactly?

Q‑Day is industry shorthand for the moment a cryptographically relevant quantum computer (CRQC) can break widely used public‑key cryptography—especially RSA and ECC—fast enough to matter operationally. It’s not a single global event, and it won’t “turn off” security overnight. It marks when certain cryptographic assumptions stop being safe.

Did Google say quantum computers will break encryption in 2029?

No. On March 25, 2026, Google said it is setting a timeline for post‑quantum cryptography migration to 2029. That’s a planning target based on trends in quantum hardware, error correction, and improved attack resource estimates. It’s a risk-management decision, not a guarantee about when CRQCs will arrive.

What does “steal now, decrypt later” mean?

Also called harvest now, decrypt later (HNDL), it describes attackers stealing encrypted data today and saving it until they can decrypt it later—using quantum computers or other future breakthroughs. Google highlights confidentiality risk as “relevant today” because HNDL makes time an attacker advantage, not a defender advantage.

Why are backups and archives especially risky under HNDL?

Backups often contain concentrated, high-value data and may be retained for years. If attackers exfiltrate encrypted archives now, they can potentially decrypt them later without re-entering your systems. HNDL turns “we encrypted it” into “we postponed the problem,” especially for data with long confidentiality lifetimes.

What do the qubit estimates (like 500,000 qubits) actually tell us?

They are resource estimates under assumptions, not a delivery schedule. 2026 reporting on Google-linked work summarizes models suggesting under ~500,000 physical qubits could attack ECC‑256 in minutes, and some circuit designs use about 1,200–1,450 logical qubits with tens of millions of Toffoli gates. The lesson is that costs appear to be falling, which shifts planning earlier.

Why are digital signatures a bigger deal than people think?

Digital signatures underpin identity, certificates, and software updates. If signatures become forgeable, attackers could impersonate trusted services or distribute malicious updates that appear legitimate. Google describes signature risk as a future threat—but one that requires migrating before CRQCs arrive, because trust infrastructure can’t be rebuilt instantly.

More in Technology

You Might Also Like