Google Cloud sets 2029 as the deadline for its post-quantum cryptography migration
On August 11, 2026, Google Cloud published its post-quantum cryptography migration roadmap, targeting full readiness by 2029 with dated milestones for 2027 and 2028. For a customer, Store Now Decrypt Later risk now has a deadline: the cryptographic inventory starts today.
August 11, 2026. Google Cloud published its post-quantum cryptography (PQC) migration roadmap. In March 2026, the company had already pulled its deadline forward to 2029. Now the milestones are dated, service by service, through 2028 — with work expected to continue “into the 2030s”.
The message for a CISO or CTO is simple: Store Now Decrypt Later risk — data encrypted today and decrypted later by a quantum computer — now has a vendor deadline. The question is no longer “should we migrate”, but “is your cryptographic inventory ready”.
Why 2029: the quantum threat became a schedule
In March 2026, Google announced it was moving its PQC target up to 2029, citing “faster-than-expected” advances in quantum hardware and error correction. The roadmap published on August 11, 2026 turns that ambition into an execution plan, built around an internal Quantum Threat Model and three priorities: mitigating SNDL risk, strengthening digital signatures against forgery, and building the cryptographic agility needed to adopt new standards as they emerge.
Several pieces are already in production. Google Cloud’s API endpoints — including google.com and googleapis.com — now use the NIST-standardized ML-KEM key exchange in hybrid mode with a classical algorithm. Application and proxy load balancers support quantum-safe hybrid key exchange for TLS 1.3 on an opt-in basis, letting a customer validate the change in their own environment. And Cloud KMS has reached general availability for NIST-standardized PQC algorithms, covering both key exchange and digital signatures.
Dated milestones: 2027 for encryption, 2028 for signatures
The roadmap sets end of 2027 as the target for mitigating SNDL risk across customer-facing workloads, administrative and developer tooling — including Cloud VPN and Interconnect — and data transfer services such as the BigQuery CLI and Storage Transfer Service.
Signature integrity and identity protection carry a longer runway, targeted for end of 2028. That covers quantum-safe software supply chain attestations, the rollout of quantum-safe certificates across Google’s infrastructure, and hardening of identity mechanisms such as Cloud IAM.
Key management follows the same end-of-2028 direction, but pieces move at different speeds: Cloud KMS is set to support quantum-safe key import as early as 2026, while hardware-backed protections — confidential computing, Cloud HSM, external key management and partner-enabled key sovereignty options — are slated for 2028. On the silicon side, Google anchors trust in open-source components including Caliptra and OpenTitan, the latter already supporting quantum-secure boot.
The company notes the effort will continue “into the 2030s”, to track CNSA 2.0 and the transition paths in NIST IR 8547, which anticipate the final deprecation of quantum-vulnerable algorithms between 2030 and 2035.
The customer’s share: infrastructure is not enough
The roadmap draws a clear line between what Google secures and what remains the customer’s job. The company owns the security of its infrastructure; the customer remains responsible for updating client-side software, managing the lifecycle of its own keys and reconfiguring services to enable quantum-safe settings once available.
In practice, Google recommends three first steps. Inventory cryptographic assets — keys, certificates, usages — to learn where SNDL exposes you. Update development and operations tooling to support PQC-capable libraries. And test existing applications against the quantum-safe APIs and load balancers that are already available, before migration becomes mandatory.
Store Now Decrypt Later: what the 2029 deadline really protects
SNDL does not need a working quantum computer to be a risk. The principle: an adversary records today your encrypted traffic — TLS, VPN, backups — and stores it; the day a quantum computer can break the underlying algorithm, they decrypt it retroactively. Data captured in 2026 that must stay secret until 2036 is therefore already exposed.
That is why the 2029 deadline matters. It does not say when the quantum computer will arrive — nobody knows precisely. It says when Google Cloud’s infrastructure will have replaced quantum-vulnerable algorithms with PQC ones. Between those two dates, your only protection against SNDL is to move your workloads onto quantum-safe key exchange as early as possible, because every day of classical encryption is a day of potentially captureable data.
Hybrid mode and cryptographic agility: migrating without breaking everything
The hybrid mode Google Cloud chose is the keystone of the transition. A hybrid key exchange combines a classical algorithm (X25519, for instance) with a PQC algorithm (ML-KEM): the session key is derived from both. If the quantum algorithm turns out fragile, the classical component still protects the session; if the classical algorithm falls, the PQC component takes over.
It is the compromise to imitate: do not wait for full standards maturity to start, but do not switch abruptly to a still-young algorithm. Cryptographic agility — the ability to swap algorithms without rewriting the application — is what makes that double safety net possible, and it is the most transferable lesson in the roadmap.
The roadmap also sits inside a broader regulatory current. The US CNSA 2.0 guidance and NIST IR 8547 govern the deprecation of classical algorithms, and US agencies have already been set migration deadlines. A cloud provider that publishes a dated PQC roadmap is no longer an exception; it is becoming a selection criterion.
The split between 2027 and 2028 is also worth reading closely. SNDL — protecting data from retroactive decryption — gets the earlier deadline, because every day of exposure is cumulative. Signatures — proving who issued what — get a longer runway, because a signature is only at risk from the moment a quantum computer can forge it, not retroactively. That asymmetry explains why Google ships key exchange first and certificates later, and it is the same ordering any customer should follow.
The inventory: the hard part
In practice, the inventory is the hard part. Most organizations know the certificates on their public-facing endpoints but not the keys and certificates inside internal services, database connections, message queues and third-party integrations. Start where SNDL hurts most — data with a confidentiality horizon beyond 2030 — and with the service accounts that protect it. The inventory you build for PQC doubles as the inventory you need for certificate lifecycle management: a rare case where a security migration pays for itself twice. That same inventory is the only input that makes the 2027 and 2028 milestones actionable on your side.
Verdict
If you handle data that must stay confidential beyond five to ten years — healthcare, defense, industrial property, design secrets — Store Now Decrypt Later is already a live risk: an adversary can capture your encrypted traffic today and decrypt it tomorrow. Start the cryptographic inventory now; it is the step everyone postpones and the one every other step depends on.
If you are a Google Cloud customer, test quantum-safe hybrid key exchange on your load balancers and API calls now — it is the most concrete way to measure the migration’s impact on your applications ahead of the 2027 deadline.
For teams waiting for “the final standard”: the standard is already here — ML-KEM, ML-DSA and SLH-DSA are NIST-standardized. Cryptographic agility is not a project you start in 2028; it is a capability you build now.