Google Cloud's 2029 post-quantum date now comes with line items your 2027 plan must answer

Google Cloud has published an updated roadmap for moving its infrastructure to post-quantum cryptography, targeting full readiness by 2029 with some work expected to run into the following decade ^[1]. What makes this more than a whitepaper is that parts of it have already shipped: API endpoints including google.com and googleapis.com now use NIST-standardized ML-KEM key exchange in hybrid mode, and Cloud KMS has reached general availability for NIST-standardized post-quantum key exchange and digital signature algorithms ^[4][6].

The 2029 figure is itself a revision. Google moved the timeline forward in March, citing faster-than-expected advances in quantum hardware and error correction ^[2]. The plan is built around the company's own Quantum Threat Model and sorts work into three priorities: mitigating store-now-decrypt-later risk, strengthening digital signatures against forgery, and building enough cryptographic agility to absorb new standards as they arrive ^[3].

The dates are where operators should be reading. Store-now-decrypt-later mitigation is targeted for end of 2027, covering customer-facing workloads, administrative and developer tooling such as Cloud VPN and Interconnect, and data transfer services including the BigQuery CLI and Storage Transfer Service ^[7]. Signature integrity and identity protections carry an end-of-2028 target, including quantum-resistant software supply chain attestations, quantum-safe certificates across Google's infrastructure, and hardening of Cloud IAM ^[8]. Foundational key management shares the end-of-2028 date but moves at uneven speed: quantum-safe key import in Cloud KMS is slated as early as 2026, while confidential computing, Cloud HSM, external key management and partner-enabled key sovereignty options land in 2028 ^[9]. Those internal deadlines sit one to two years ahead of the headline 2029 goal, which is the useful detail for anyone building a migration plan around them ^[14].

Some of what exists today is opt-in rather than default. Application and proxy load balancers support quantum-safe hybrid key exchange for TLS 1.3 on an opt-in basis so customers can validate the change in their own environments ^[5]. Opt-in means a person has to own the setting, test it and keep it enabled through the next config change.

Google draws the responsibility line at its own infrastructure, leaving customers to update client-side software, manage the lifecycle of their own encryption keys, and reconfigure services to use quantum-safe settings once those settings exist ^[12]. Its recommended starting points are unglamorous and correct: inventory cryptographic assets such as keys and certificates, update development and operations tooling to support PQC-capable libraries, and test existing applications against the quantum-safe APIs and load balancers already available ^[13]. On silicon, the company says it is anchoring trust in open source components including Caliptra and OpenTitan, with OpenTitan already supporting quantum-secure boot ^[10].

Google also states that its efforts will continue into the 2030s to track CNSA 2.0 and the transition paths in NIST IR 8547, which anticipate final deprecation of legacy quantum-vulnerable algorithms between 2030 and 2035 ^[11]. That deprecation window opens one year after the 2029 target and closes six years after it ^[15]. Read plainly, 2029 is when one vendor expects to be ready, not when the problem ends.

Three things to watch. The 2026 quantum-safe key import milestone in Cloud KMS is the first checkpoint close enough to verify rather than plan around ^[9]. Whether the opt-in load balancer hybrid key exchange becomes a default, and on what notice, determines how much of this lands on customer change calendars. And external deadlines may arrive faster than vendor ones: SecurityWeek's related coverage notes an executive order signed by Trump accelerating post-quantum cryptography migration ^[16].