Google Cloud PQC Roadmap 2029: What It Means for Your PKI

On August 11, 2026, Google Cloud published "PQC in Plaintext: Google Cloud's post-quantum cryptography roadmap", signed by Jai Haridas (VP/GM, Regulated and Sovereign Cloud) and Michael Bachman (VP/GM, Cloud Foundations). The announcement sets a clear target: full post-quantum readiness across Google Cloud by 2029, with efforts continuing into the 2030s to track evolving guidance such as CNSA 2.0 and the transition paths of NIST IR 8547, which anticipate the final deprecation of quantum-vulnerable algorithms between 2030 and 2035.

Hyperscaler roadmaps deserve attention beyond their own customer base, because they function as de facto industry clocks. When one of the world's largest infrastructures commits engineering resources and dates to a cryptographic transition, it moves the baseline for everyone: standards bodies gain implementation feedback at scale, auditors gain a reference point, and every organization consuming cloud services inherits a schedule it did not set. This roadmap is worth reading closely for a second reason as well. Buried in its most consequential section is a reminder that no cloud provider, however capable, can perform your part of the migration.

Three Domains, One Convergence Date

Google structures its migration around the Google Quantum Threat Model, translated into three risk domains, each with its own deadline.

The first domain is Store Now, Decrypt Later (SNDL) mitigation, targeted for the end of 2027. This is the same harvest-and-decrypt threat the IETF's recent TLS guidance treats as the urgent front: an adversary records encrypted traffic today and decrypts it once a cryptographically relevant quantum computer exists. Google's answer covers customer-facing ingress, administrator and developer pathways (Cloud VPN, Interconnect, SDKs, client libraries), and data pipelines for analytics and storage platforms.

The second domain is integrity and non-repudiation, targeted for the end of 2028. It covers everything a quantum attacker could forge rather than decrypt: software supply chain attestations, digital signatures, identity tokens, and above all certificates. Google commits to transitioning its internal and external certificate authorities to ML-DSA certificates, with SLH-DSA where meaningful, following IETF standardization efforts it actively contributes to. Its private CA offering is slated for PQC support in 2027, Cloud IAM in 2028, and a broad rollout of PQC certificates across products in 2027 and 2028.

The third domain is foundations and key management, also targeted for the end of 2028: NIST-approved algorithms in Cloud KMS and the BoringSSL and Tink libraries, quantum-resistant hardware roots of trust in Confidential Computing and Cloud HSM (FIPS 140-3 Level 3), and PQC orchestration for external and client-side key management. One honest caveat stands out: hardware transition follows both active replacement and natural equipment cycles, so some physical components may extend beyond 2029. Anyone who has managed an HSM fleet will recognize the realism.

What Is Already Live: The 2026 Milestones

The roadmap's credibility rests on what has already shipped, and the list is substantial. Google Cloud API endpoints, including google.com and *.googleapis.com, now offer quantum-safe hybrid key exchange using NIST-standardized ML-KEM (FIPS 203). Application and proxy load balancers support X25519MLKEM768 for TLS 1.3 on an opt-in basis, letting customers validate behavior before broad enablement. Cloud KMS has reached general availability for ML-KEM, ML-DSA, and SLH-DSA, and quantum-safe key import is in progress.

The most forward-looking item concerns certificates. Google is collaborating with the IETF PLANTS Working Group and experimenting, alongside Chrome and Cloudflare, with Merkle Tree Certificates, a novel construction designed to tame the size of post-quantum signatures in the WebPKI. Large PQC certificate chains are one of the transition's hardest practical problems, the same one the IETF's TLS application guidance addresses through compression and abridged certificates, and the fact that a hyperscaler, a browser, and a CDN are testing structural alternatives at scale says the industry considers incremental fixes insufficient on their own.

Two observations follow from these milestones. First, hybrid key exchange is no longer experimental: it is deployed on some of the highest-traffic endpoints on the Internet. Second, the confidentiality half of the transition is measurably ahead of the authentication half, exactly the sequencing the standards community has converged on. Key exchange first, because SNDL makes it urgent. Certificates next, because PKI migration takes years and the standards are still stabilizing.

The Sentence That Concerns Every Reader

The roadmap's most important passage for anyone outside Google is its shared responsibility section. Google states its own scope precisely: security of the cloud, meaning the network, encryption in transit, global front ends, internal protocols, servers, and silicon roots of trust such as OpenTitan, Caliptra v2.1, and TPM 2.0 v185. Then comes the division: security in the cloud remains the customer's responsibility. In Google's own framing, organizations manage their own applications, update client-side software to negotiate PQC handshakes, manage the lifecycle of their asymmetric keys, and update service configurations with quantum-safe settings and policies.

Translated into operational terms, the provider migrates the pipes, and everything flowing through them that you created remains yours to migrate: your certificates, your keys, your trust anchors, your application cryptography, and your private PKI. A quantum-safe load balancer terminates a quantum-safe handshake, and it says nothing about the certificate hierarchy your workloads authenticate with, the code-signing keys in your release pipeline, or the ten-year device certificates in your factory.

Google's own recommended first steps confirm where the customer's work begins: inventory cryptographic resources, update software stacks to PQC-capable versions, validate application behavior against quantum-safe endpoints. Inventory comes first for a reason. It is the step no provider can perform on your behalf, because only you can know which keys and certificates exist across your estate, who owns them, what data lifetime they protect, and which of them can even tolerate an algorithm change. Every credible migration methodology, from NIST to ANSSI to the cloud providers themselves, now begins at the same place: knowing what you have.

Reading the Roadmap from Europe

For European organizations, the roadmap intersects three ongoing conversations.

The first is regulatory alignment. Google's 2027 and 2028 domain deadlines land comfortably ahead of the EU coordinated roadmap on post-quantum cryptography, which calls for hybrid protection of high-risk flows before 2030 and full migration trajectories by 2035, and ahead of the horizons in NIST IR 8547 and CNSA 2.0. Entities regulated under DORA and NIS2 will find the provider side of their cloud dependency moving faster than their obligations require, which shifts scrutiny to the customer side of the shared responsibility line. An auditor asking about quantum readiness in 2028 will get a strong answer about the infrastructure and will then ask about the certificates and keys the organization itself controls.

The second is algorithmic posture. Google's roadmap includes pure ML-DSA and SLH-DSA certificates in its private CA services. European guidance, notably from ANSSI and BSI, has consistently favored hybrid constructions during the transition period, combining classical and post-quantum algorithms so that security holds if either component fails. Both positions are defensible, and they are not mutually exclusive across a large estate. The practical consequence is that European organizations may operate hybrid requirements on some perimeters and pure PQC options on others, which makes policy enforcement per certificate population a governance requirement rather than a nicety.

The third is sovereignty. It is notable that the announcement is co-signed by the executive responsible for Google's Regulated and Sovereign Cloud, and that PQC deployment across Google Cloud Dedicated and Google Distributed Cloud is called out explicitly. Quantum readiness is becoming part of the sovereignty conversation, and European organizations weighing where their roots of trust live, who operates their CAs, and who holds their keys will now factor post-quantum timelines into decisions that were already strategic. A provider's excellent roadmap secures the infrastructure layer, and it leaves untouched the question of who governs the trust hierarchy above it.

Closing Thoughts

"PQC in Plaintext" is a serious, dated, and unusually candid roadmap, down to its admission that some hardware will outlast the 2029 target. It confirms the sequencing the whole industry has converged on: hybrid key exchange now, certificates and signatures through 2028, agility as the permanent foundation. It also draws, in the provider's own words, the boundary that defines the coming three years of work for everyone else. The infrastructure half of the quantum transition is being handled by people with world-class resources and public deadlines. The other half, the certificates, keys, and trust hierarchies that organizations own, has the same deadlines and only one owner.

The prudent reading mirrors Google's own advice, generalized beyond any single cloud: inventory what you have, wherever it lives. Organizations that can enumerate their cryptographic estate, assign ownership, and rehearse algorithm change at the hierarchy level will experience the provider roadmaps of the late 2020s as a tailwind. Those that cannot will discover in 2029 that the pipes turned quantum-safe years before the traffic did.