Google Cloud dates its post-quantum work: 2027 for harvest-now risk, 2028 for signatures

Google Cloud published a post-quantum migration roadmap on August 12 that splits the work into three risk domains taken from its own quantum threat model and attaches an end date to each ^[2]. Store-now-decrypt-later risk, where traffic harvested now is decrypted later by a quantum computer, is targeted for the end of 2027; hardening digital signatures against forgery and rebuilding key management for cryptographic agility both run to the end of 2028 ^[3][4]. Both fall ahead of the 2029 date Google set alongside Cloudflare and Microsoft ^[5].

The reason this matters to operators is not the cryptography. It is that a dependency most enterprises cannot route around has now put years next to specific services, which is the input a crypto inventory needs to become a plan.

Some of it has shipped. Google Cloud API endpoints, including google.com and *.googleapis.com, now offer quantum-safe key exchange using NIST-standardized ML-KEM in hybrid mode ^[6]. Application and proxy load balancers support hybrid key exchange for TLS 1.3, initially opt-in so customers can validate before anything breaks ^[7]. Cloud KMS has reached general availability for ML-KEM, ML-DSA and SLH-DSA ^[8], and quantum-confidential ALTS, Google's internal traffic protocol, completed in 2025 ^[9].

The queue behind that is where the schedule pressure sits. Cloud VPN and Interconnect land in 2026 and 2027 ^[10], Private CA in 2027 ^[11], and Cloud IAM plus a quantum-safe Cloud HSM in 2028 ^[12]. Read against the domain deadlines, the pattern is that the enabling components arrive in the same year as the milestone they serve, with no visible slack: Private CA in 2027 against an end-of-2027 SNDL target, IAM and HSM in 2028 against an end-of-2028 signature and key-management target ^[19]. Anyone whose own migration assumes those services are available early in the year rather than late should mark that assumption as unfunded.

Certificates carry a further constraint. Post-quantum signatures are large enough to affect certificate chain validation performance, which Google is addressing through Merkle Tree Certificates ^[13]. Jason Soroko, senior fellow at certificate lifecycle management provider Sectigo, said the approach replaces multiple large signatures with one compact inclusion proof, keeping overhead near current levels ^[14]. He also said it folds transparency logging into issuance rather than bolting it on: "If a certificate is not in the tree, it simply does not exist" ^[15]. That is a change in how existence is proved, and it will land on certificate tooling, not only on servers.

Google was explicit that customers carry part of the load, including updating client-side software to negotiate post-quantum handshakes and managing their own asymmetric key lifecycles ^[16]. On hardware it was less committal, saying the timeline for some physical components may extend beyond 2029 because the transition depends partly on natural equipment replacement cycles ^[17]. That is the honest caveat in the document, and it is also the part with the longest lead time in most estimates.

For context on the deadline itself: Google warned in March that a cryptographically relevant quantum computer could arrive as early as 2029 ^[18], which leaves roughly a year between the end-of-2028 signature milestone and the earliest date Google itself cites ^[20].

What to watch: whether the 2026 Cloud VPN and Interconnect deliveries arrive on time, since they are the first dated items due after the roadmap and the cheapest early signal of slippage; and whether hybrid key exchange on load balancers moves from opt-in to default, which is when client-side compatibility problems stop being theoretical.