# Google Cloud's 2029 Quantum Deadline Is Actually a 2027 Fire Drill
Somewhere in a foreign intelligence archive, copies of encrypted enterprise traffic from 2023 are sitting in cold storage. The bet being made by whoever collected it is simple: a quantum computer capable of breaking RSA-2048 will exist within the decade, and when it does, that harvested ciphertext becomes plaintext. This is the threat that shaped Google Cloud's updated post-quantum cryptography roadmap — and it's why the actual deadline isn't 2029. It's 2027.
Google published its updated PQC timeline this week, organizing a complex multi-year infrastructure migration into three parallel tracks: neutralizing Store Now Decrypt Later (SNDL) risk, hardening digital signatures against quantum forgery, and building the cryptographic agility to absorb whatever standards emerge next. The full readiness target is 2029, with some work expected to continue into the early 2030s. But the structure of the plan reveals where Google considers the bleeding edge to be — and it isn't the headline date.
## The Clock They're Racing Against
In March, Google moved its PQC timeline up after faster-than-expected advances in quantum hardware and error correction. That sentence deserves more weight than it gets in most coverage. Google's quantum team has direct visibility into where the hardware is heading. When they accelerate an enterprise-scale cryptographic migration affecting billions of users, it's not a marketing play.
NIST finalized its first set of post-quantum cryptographic standards in 2024 — ML-KEM for key encapsulation, ML-DSA and SLH-DSA for digital signatures. The standards exist. The algorithms are ready. The problem now is pure execution: migrating decades of infrastructure that was built around RSA, ECDSA, and Diffie-Hellman key exchange. Every certificate, every VPN tunnel, every key management workflow, every hardware security module — all of it needs to be touched.
The SNDL threat is why none of this can wait. Data encrypted today with classical algorithms can be harvested and stored cheaply. A nation-state adversary with patience and a quantum computer in 2032 can decrypt your 2025 M&A discussions. High-value targets — financial institutions, defense contractors, healthcare systems, government agencies — are the obvious concern. But any organization whose data has long-term sensitivity is in scope.
## What's Actually Live Right Now
Google isn't just publishing targets. Several pieces of the migration are already in production.
Traffic to google.com and googleapis.com — which covers essentially all Google Cloud API calls — now uses ML-KEM key exchange in hybrid mode for TLS. Hybrid mode matters: it runs the classical key exchange alongside the quantum-safe one, so if ML-KEM turns out to have an unforeseen weakness, the classical component still provides coverage. It's belt-and-suspenders cryptography for an algorithm class that hasn't had decades of real-world cryptanalysis yet.
Application and proxy load balancers support quantum-safe hybrid key exchange for TLS 1.3 on an opt-in basis — which means enterprises can already start testing their applications against the quantum-safe stack before it becomes mandatory. Cloud KMS has reached general availability for NIST-standardized PQC algorithms covering both key exchange and digital signatures. Quantum-safe key import for Cloud KMS is slated for as early as this year.
These aren't promises. They're shipped features.
## The Deadline Behind the Deadline
Google's roadmap structure tells you what the company considers urgent vs. what it considers important but not on fire.
SNDL mitigation carries the earliest deadline: end of 2027. That covers customer-facing workloads, administrative tooling like Cloud VPN and Interconnect, and data transfer services including BigQuery CLI and Storage Transfer Service. The 2027 target exists because SNDL is a retrospective attack — the damage from failing to meet this deadline has already been happening for years, accumulating in adversary archives.
Signature integrity and identity protections — quantum-resistant supply chain attestations, quantum-safe certificates, Cloud IAM hardening — carry a 2028 target. These matter enormously for software security and identity systems, but the threat model is forward-looking: a quantum computer that can forge signatures doesn't exist yet, and the window before it does is wider than the window for SNDL.
Hardware-backed protections, including confidential computing and Cloud HSM, are also slated for 2028. The trust anchor is being built on Caliptra and OpenTitan open-source silicon components — OpenTitan already supports quantum-secure boot. This is the right foundation: if you can't trust the hardware layer, everything above it is exposed regardless of algorithm choice.
## What Google Handles, What You Still Own
This is the section of the roadmap that most enterprise readers need to sit with: Google frames infrastructure security as its own responsibility. The pipe is getting quantum-safe. But customers remain responsible for their own keys, their own certificates, and their own client-side code.
That boundary matters more than most organizations are treating it. Migrating your applications to use PQC-capable libraries isn't a cloud vendor problem. Rotating long-lived encryption keys that were generated using classical algorithms isn't a cloud vendor problem. Ensuring your CI/CD pipeline, your VPN clients, your partner integrations, and your internal tooling can negotiate quantum-safe sessions — none of that is on Google's 2027 target list, because it's on yours.
Google's recommended starting point for customers is sensible:
The inventory step is where most organizations will discover they have no idea what they're running. Shadow certificates, long-lived service account keys, hardcoded classical key exchange in legacy applications — the audit itself is often the most uncomfortable part of this process.
## HackWire Analysis
Google's announcement sits at the intersection of two converging pressures: an accelerating quantum hardware timeline and a post-NIST-standardization window where the excuse for inaction has largely expired. The standards are final. The reference implementations exist. The cloud providers have shipped. What remains is enterprise execution, and that's historically where cryptographic migrations go to die.
The broader context most coverage is missing: this isn't happening in isolation. In recent months, AWS published its own PQC migration documentation, Microsoft Azure has been quietly extending ML-KEM support, and the Trump administration signed an executive order accelerating federal agency PQC migration. The hyperscalers are running a coordinated race — not against each other, but against a quantum capability timeline that no single vendor controls.
What's genuinely underreported is the software supply chain angle. Google has slated quantum-resistant supply chain attestations for 2028, and that timeline deserves scrutiny. If a nation-state can forge a code-signing certificate using a quantum computer before those attestations are in place, the implications for software integrity go well beyond cloud infrastructure. The 2028 date on signature hardening is the one to watch.
For defenders, the most actionable near-term move isn't waiting for 2027 to arrive — it's starting the cryptographic asset inventory now. Organizations that know what they have will be able to migrate systematically. Organizations that don't will be scrambling when their cloud provider stops supporting classical-only key exchange and the deadline is next quarter.
The 2029 headline date is real. But the 2027 SNDL deadline is the one that maps to data that already exists, already encrypted, already in someone else's hands. That's not a future problem. That's a present one with a future unlock date.
— HackWire Editorial
## Related Coverage