Google Cloud Post-Quantum Roadmap Targets Full PQC Readiness by 2029

What Google Cloud committed to

Google Cloud has published a staged plan to move its infrastructure and customer-facing services to post-quantum cryptography (PQC). The company says it expects to be fully ready by 2029, which it describes as the year its separate migration efforts come together21. The updated roadmap came out on August 11, 202625. It follows a company-wide announcement on March 25, 2026, which first set 2029 as Google's migration deadline26. SecurityWeek reported that Google pulled its timeline forward in March because quantum hardware and error correction were improving faster than expected22.

The plan is built on Google's internal Quantum Threat Model. It sorts the work into three priorities. The first is reducing "store now, decrypt later" (SNDL) risk. The second is protecting digital signatures from forgery. The third is cryptographic agility, meaning systems that can switch to new standards as they appear22. Each priority has its own deadline. SNDL protections are due by the end of 2027. Integrity and non-repudiation work, along with foundational key-management work, is due by the end of 2028. Full readiness follows in 202923.

What is already running

The roadmap is more than a set of future promises, because some protections are already live. Google says its API endpoints, including google.com and googleapis.com, now use ML-KEM key exchange in hybrid mode. ML-KEM is the key-encapsulation algorithm NIST standardized22. Customers can opt in to the hybrid X25519MLKEM768 key exchange for TLS 1.3 on application and proxy load balancers23. Cloud KMS lists ML-KEM, ML-DSA and SLH-DSA as generally available for encryption and signing keys2325.

Most outlets reported these items the same way, with one difference. One outlet said the NIST algorithms were still "being integrated" into Cloud KMS26. Others described them as already generally available2528. Google's own roadmap documentation supports the second reading. The difference in wording does not appear to reflect a difference in substance.

The hybrid design is deliberate. Pairing a new quantum-resistant algorithm with a proven classical one means a connection stays secure even if someone finds a flaw in the newer standard26. Google's internal ALTS protocol already uses PQC for confidentiality. Quantum-safe authentication for ALTS is still on the to-do list23.

Signatures are the harder problem

The most telling detail is how the deadlines are ordered. Google puts confidentiality first because of the harvest-now threat. An attacker can record encrypted traffic today and decrypt it years later, once a cryptographically relevant quantum computer exists25. Signatures, certificates and identity get an extra year. That covers quantum-resistant attestations for the software supply chain, quantum-safe certificates across Google's infrastructure, and hardened identity systems such as Cloud IAM22. One security news aggregator summed it up as signatures trailing key exchange by a year29.

The gap makes sense from an engineering standpoint. Post-quantum signatures are large, and that creates size and performance problems for certificate chains. Google is working with the IETF PLANTS working group and testing Merkle Tree Certificates to deal with this23. Chrome and Cloudflare are part of that experiment28. The roadmap targets quantum-safe support in Private CA in 2027, Merkle Tree Certificates from Google Trust Services in 2028, and Cloud IAM in 202824.

This reflects a change in how the industry thinks about PQC migration. Early planning mostly concentrated on key exchange. The next phase has to protect the systems that decide who can sign, authenticate, deploy and authorize23. Of the two, signatures may matter more. Captured traffic can only be read later, but a forged signature lets an attacker act in real time as a trusted party.

The research that moved the deadline

The reason Google, and the industry, settled on 2029 comes from cryptanalysis work done largely inside Google itself. In May 2025, Google Quantum AI researcher Craig Gidney estimated that RSA-2048 could be factored in under a week with fewer than one million noisy qubits11. His 2019 estimate with Martin Ekerå had been about 20 million qubits running for roughly eight hours14. The new figure is about 20 times lower, and it came from better algorithms and error correction rather than better hardware20. The improvements included approximate residue arithmetic, yoked surface codes that store idle qubits more densely, and magic state cultivation16. The estimate still assumes hardware that does not exist. It requires a 0.1% gate error rate, one-microsecond surface-code cycles, and five days of continuous operation11.

The numbers have kept dropping since then. In February 2026, Iceberg Quantum proposed an architecture that would need fewer than 100,000 physical qubits16. That design depends on qLDPC codes with connectivity no one has demonstrated at scale, and its runtime is about a month15. In March 2026, a Google team that included Gidney, Ryan Babbush and Hartmut Neven published estimates for the 256-bit elliptic-curve discrete logarithm problem. That problem underpins ECDSA and ECDH, which protect much of TLS, SSH and code signing18. The team estimated 1,200 to 1,450 logical qubits and under 500,000 physical qubits. It also found that the elliptic-curve attack needs about 100 times fewer Toffoli gates than RSA-2048, which cuts the runtime from days to minutes15.

One analyst observed that Google published these resource estimates in the same period it set its own migration deadline15. Google is in an unusual position. It builds quantum hardware, publishes the attack estimates, and runs one of the largest cloud platforms, so it sees both sides of the threat. Its choice to put a date on readiness carries information that a typical compliance plan does not.

How the hardware roadmaps line up

Vendor roadmaps show why 2029 keeps coming up. IBM plans to deliver Starling in 2029. Starling is a fault-tolerant system meant to run 100 million gates on 200 logical qubits2. In August 2026, IBM connected its first modular cryogenic systems, which it described as a step toward Starling3. A follow-on system, Blue Jay, is planned for around 2033 with about 2,000 logical qubits5. Quantinuum is targeting its Apollo machine in 2029, with hundreds of logical qubits5. Microsoft says it has halved its timeline and is aiming for a scalable fault-tolerant machine by 20295. IonQ has the most aggressive public targets: 8,000 logical qubits in 2029 and 80,000 in 20305. Google says it is working toward useful error correction around 2029. Its 105-qubit Willow chip showed below-threshold error correction in December 20245.

Public figures do not always agree. One explainer said IBM is targeting about 10,000 logical qubits around 203020. IBM's own published roadmap says 200 logical qubits in 20292. Demonstrated capability is also well behind the targets. Quantinuum and Microsoft's 12 logical qubits on the H2 machine is still among the strongest public results6.

The arithmetic leads to a clear conclusion. Gidney's RSA design needs about 1,400 logical qubits13, and the elliptic-curve estimate is in a similar range15. A 200-logical-qubit Starling would not break RSA in 2029. However, the leading vendors are aiming for thousands of logical qubits in the early 2030s, and the resource estimates keep falling. That leaves little room for an organization whose migration takes longer than five years. Analysts tracking IBM's plan concluded that a cryptographically relevant machine could arrive in the early 2030s1. A timeline table compiled by one outlet lists Google's 2029 planning date next to a median expert estimate of 2033 and a 50% probability estimate of 2035 from the Global Risk Institute14. Google's 2029 date is best read as a deadline with built-in margin, not a forecast of when an attack becomes possible.

The work that falls to customers

The most important caveat for enterprises is that 2029 is Google's target and not necessarily theirs25. Google takes responsibility for its network, encryption in transit, servers, operating systems and hardware. Customers still have to update their client-side software, manage the lifecycle of their own keys, and reconfigure services to use quantum-safe settings22. Some hardware will also miss 2029. Google is relying partly on normal equipment replacement cycles, so some physical components may be upgraded later than that21. Google also expects related work to continue into the 2030s in line with CNSA 2.0 and NIST IR 8547, which plan for quantum-vulnerable algorithms to be retired between 2030 and 203522.

Google's advice to customers comes down to three steps. Inventory your keys and certificates. Update tooling to libraries that support PQC. Test applications against the quantum-safe endpoints and load balancers that are already available22. Cloudflare and Microsoft have both set 2029 targets of their own, which points to an industry-wide consensus on the date26. The large cloud providers are converging on one deadline. The open question now is whether their customers' applications, certificates and older hardware can be upgraded in time.