Google Cloud Maps Post-Quantum Crypto Readiness by 2029

Most post-quantum announcements are a single product shipping a single algorithm. Google Cloud has published something more useful: a dated, phased roadmap showing which services get post-quantum cryptography in which year, running from work already complete through to full readiness in 2029.

• Target: Full post-quantum readiness across Google Cloud by 2029, with work continuing into the 2030s as standards evolve
• Already live: Hybrid X25519MLKEM768 key exchange on API endpoints and load balancers; PQC algorithms generally available in Cloud KMS
• Algorithms: The NIST-standardised ML-KEM, ML-DSA, and SLH-DSA
• Published: August 11, 2026, on the Google Cloud security blog

What the Phases Actually Cover

The roadmap is organised around Google's own quantum threat model and splits into three priorities: mitigating store-now-decrypt-later risk, strengthening digital signatures against forgery, and building enough cryptographic agility to swap algorithms again when standards move.

The 2027 milestone targets the store-now-decrypt-later problem, bringing PQC to Cloud VPN, Cloud Interconnect, GCE OS Login, the Cloud SDK and gcloud CLI, GKE service mesh, Cloud Storage, Storage Transfer Service, BigQuery and its data transfer service, plus quantum-authentic ALTS across the internal infrastructure.

The 2028 milestone shifts to integrity and key management: the Certificate Authority Service, Merkle Tree Certificates through Google Trust Services, Cloud IAM, Confidential Compute, a FIPS 140-3 Level 3 quantum-safe Cloud HSM, and external key management. 2029 is where it all converges.

Why Store-Now-Decrypt-Later Sets the Deadline

This is the part that makes the timeline urgent rather than academic. An adversary does not need a quantum computer today to benefit from one later — they only need to capture encrypted traffic today and hold it.

Any data with a confidentiality lifetime measured in years is therefore already exposed to a machine that does not yet exist. Medical records, legal archives, long-lived credentials, and state secrets all fall in that bucket. That is why key exchange gets fixed first, ahead of signatures: signatures protect against forgery in the moment, while key exchange protects the recorded traffic.

NIST finalised ML-KEM, ML-DSA and SLH-DSA in 2024 after years of evaluation, and Google notes that legacy quantum-vulnerable algorithms are expected to be deprecated between 2030 and 2035 under NIST IR 8547 and CNSA 2.0. A 2029 readiness target leaves genuine margin against those dates rather than racing them.

What Should Security Teams Do Now?

Google's recommended sequence is refreshingly concrete, and it works regardless of which cloud you run on. Inventory your cryptographic resources so you know what you actually have. Update to software that supports PQC — BoringSSL, current Chrome, current SDKs. Then validate by testing against quantum-safe API endpoints and load balancers that are already live.

That first step is the one teams skip and the one that takes longest. You cannot migrate what you have not catalogued.

The vendor pattern here is consistent and encouraging. Cloudflare added IPsec downgrade protection for post-quantum tunnels in July, and OpenSSH 10.4 shipped post-quantum signatures the same month. The infrastructure layer is migrating ahead of any regulatory forcing function, which is exactly the order you want.

For teams tracking AI security and cryptographic defence, a published roadmap with named services and years attached is worth more than another algorithm announcement. It lets you plan against someone else's dates instead of guessing at them.

Sources: Google Cloud blog — August 11, 2026; SecurityWeek — August 14, 2026.