Google Cloud Targets 2029 to Be Quantum-Safe, and Here Is What That Means for You
Google has published a detailed plan to protect its cloud from the coming generation of quantum computers. The work is already underway, and parts of it run into the 2030s.

Key points
- Google Cloud set a 2029 readiness target in March 2025 after quantum hardware advanced faster than expected.
- The biggest near-term risk: criminals collecting encrypted data today, planning to crack it once quantum computers are powerful enough.
- Google Cloud's main API endpoints already use ML-KEM, a quantum-safe key-exchange standard approved by NIST.
- Customers must inventory their own keys, update developer tooling, and test against Google's quantum-safe settings.
- Legacy encryption algorithms are expected to be formally retired between 2030 and 2035.
Why does quantum computing threaten your data right now?
Quantum computers are advancing faster than most predicted. They can't break today's encryption yet. The danger is that criminals are already collecting encrypted data now, banking on decoding it once the machines are ready. Security professionals call this "Store Now Decrypt Later."
Data from a government form or a bank transfer sent over the internet today could be readable by criminals in a decade. As we reported on 12 June 2026, only 5% of security teams have a defined strategy for this despite NIST publishing its first post-quantum standards in 2024. Google's roadmap is built around closing that window before it matters.
What has Google actually done so far?
Several protections are already live. Google Cloud's main API endpoints now use ML-KEM, a key-exchange method that NIST standardised to resist quantum attacks. Key exchange is the handshake that establishes a secure connection before any data moves.
Google runs ML-KEM in hybrid mode, pairing it with the older method so nothing breaks if there's a compatibility problem. Load balancers also support this quantum-safe handshake for TLS 1.3, the current standard for encrypting web traffic, though customers must opt in. Cloud KMS, Google's key management service, now supports the new NIST algorithms at general availability, meaning it's out of testing and open to all customers.
When does the rest happen?
| Milestone | Target date |
|---|---|
| Store Now Decrypt Later risk closed for customer workloads | End of 2027 |
| Quantum-safe certificates across Google infrastructure | End of 2028 |
| Cloud IAM (identity and access controls) hardened | End of 2028 |
| Cloud KMS supports quantum-safe key import | 2026 |
| Hardware-backed protections (Cloud HSM, confidential computing) | 2028 |
| Legacy algorithms formally deprecated globally | 2030 to 2035 |
Google's roadmap organises the work into three areas: closing the Store Now Decrypt Later risk, hardening digital signatures against forgery, and building cryptographic agility, the ability to swap in new standards as they emerge.
What should customers do right now?
Protecting Google's infrastructure is Google's job. Protecting the software and keys customers run on top of it is the customer's job.
Google recommends starting with three things: inventory every encryption key and certificate your organisation holds; update developer tools and libraries to versions that support the new standards; test your applications against the quantum-safe APIs and load balancers Google has already switched on. Microsoft set the same 2029 target last month, as we reported on 1 July 2026. Two deadlines converging that fast should concentrate minds in any IT team still treating this as a future problem.
For individuals, there's no action needed today. If you work somewhere that stores sensitive records, it's worth asking your IT team whether they've got a quantum-readiness plan.
Common questions
Will my passwords or accounts be at risk?
Not immediately. Quantum computers powerful enough to break current encryption don't exist yet, and Google's roadmap aims to have protections in place well before they do.
Does MFA help here?
MFA, multi-factor authentication requiring a second proof of identity such as a code sent to your phone, doesn't directly address quantum decryption risk. That risk targets encrypted data in transit or storage rather than login processes. MFA remains essential for account security, just for different reasons.



