Google Just Published Its Post-Quantum Roadmap. Here's the Part That Isn't Google's Job.
A Hyperscaler Just Set a Public Clock
On August 11, 2026, Google Cloud published its updated roadmap to migrate to post-quantum cryptography (PQC) by 2029, written by Jai Haridas (VP/GM, Regulated and Sovereign Cloud) and Michael Bachman (VP/GM, Cloud Foundations). It's a substantial commitment: google.com and *.googleapis.com API endpoints already run NIST-standardized ML-KEM (FIPS 203) in hybrid mode, load balancers support quantum-safe TLS 1.3 key exchange, and Cloud KMS's PQC algorithm suite — ML-KEM, ML-DSA, and SLH-DSA — is already generally available.
Read past the headline and the post says something more specific, and more useful, than "the cloud is handling this." It draws a line, in Google's own words, between "security of the cloud" — which Google owns — and "security in the cloud" — which the customer owns. That distinction is the actual story, and it's easy to miss if you only read the first paragraph.
What Google Committed To — And What It Didn't
Google's roadmap is organized into three domains, each with its own 2027–2029 target: protecting data in transit against harvest-now-decrypt-later attacks, hardening digital signatures against forgery, and building cryptographic agility into its own key-management and hardware infrastructure. All three are real, specific, and dated — this isn't a vague pledge.
All three are also scoped to Google's infrastructure. The roadmap secures the network, the load balancers, the API surface, the physical hardware roots of trust. It does not — and does not claim to — secure the application code your team writes, the signing pipelines your CI/CD runs, the certificates your services issue to each other, or the third-party SaaS integrations sitting on top of Google's platform. Google says this directly: customers are responsible for "updating client-side software to negotiate PQC handshakes and managing the lifecycle of your asymmetric keys."
Google's Own Advice Is the Point
The post ends with three recommended steps for Google Cloud customers, and they're worth reading exactly as written, because they describe a gap rather than close one:
1. Inventory your cryptographic resources — keys, certificates, algorithms in use — across your organization. 2. Update your development and SRE workflows to use PQC-capable software. 3. Validate your applications against Google's quantum-safe APIs and load balancers before you assume you're covered.
That's not a checklist Google performs for you. It's a checklist Google is handing you, because a fully PQC-ready cloud provider under an application layer that's never been inventoried is still a fully exposed organization. "We run on Google Cloud" answers a real question about network-layer transport security. It does not answer "where does RSA or ECDSA still live in our own code, our own certs, our own key stores" — and that second question is the one that actually determines your harvest-now-decrypt-later exposure.
The Clock Was Already Running
This isn't a new deadline stacked on an old one — it's confirmation of a timeline TAI has been tracking since June. Executive Order 14412 already set December 31, 2030 for federal high-value-asset key-establishment migration and December 31, 2031 for digital signatures. NIST IR 8547 sets a broader, non-federal deprecation window for RSA, ECDSA, and other quantum-vulnerable algorithms between 2030 and 2035. Google's August post doesn't move any of those dates. It's a hyperscaler publicly confirming the same clock everyone else is already on — and drawing a clean boundary around how much of your own exposure it actually reduces.
The Practical Read
If your organization runs on Google Cloud, AWS, or Azure, none of those providers' infrastructure roadmaps are your cryptographic inventory. That inventory — knowing precisely where RSA, ECDSA, and 3DES live across your applications, signing pipelines, and third-party integrations, and how exposed each one is given how long that data has to stay confidential — is exactly the first deliverable of the TAI Quantum Pen Test: a fixed-scope, 60-day assessment that produces the inventory Google is telling every one of its customers to go build themselves, plus a migration roadmap mapped to ML-KEM, ML-DSA, and SLH-DSA, plus reproducible Shor/Grover exposure evidence rather than a checklist.
Your cloud provider securing its own infrastructure was never the hard part. Knowing what's still yours is.
---
Sources: Google Cloud Blog, "PQC in Plaintext: Google Cloud's post-quantum cryptography roadmap," by Jai Haridas and Michael Bachman, Aug 11, 2026 — canonical URL confirmed via the page's own <link rel="canonical"> and og:url tags, not just the share.google redirect it was originally reached through. Also: Executive Order 14412; NIST IR 8547.