Google Cloud Put Dates on Its PQC Migration. Signatures Trail Confidentiality by a Year.

August 11, 2026 – Google Cloud published a dated post-quantum cryptography migration roadmap, setting target completion dates of 2027 and 2028 for three risk domains that converge on the company-wide 2029 commitment announced in March.

The post was written by Jai Haridas, vice president and general manager for regulated and sovereign cloud, and Michael Bachman, vice president and general manager for cloud foundations. It attaches target dates to named services rather than to the company as a whole, and marks which milestones are already complete.

The roadmap builds on what Google calls the Google Quantum Threat Model, splitting the migration into three domains. Domain 1 covers store-now-decrypt-later mitigation, Domain 2 covers integrity and non-repudiation, and Domain 3 covers foundations and key management. Within each domain, Google organizes the work around what it describes as customer journeys, a risk-based prioritization that its security teams identified as most exposed to quantum attack. The three journeys in the first domain cover customer workloads, administrator and developer flows, and data pipelines.

Domain 1 is targeted for the end of 2027. Google lists quantum-confidential ALTS, its internal application-layer transport protocol, as completed in 2025, and lists both Google Cloud API endpoints and application and proxy load balancer support as completed in 2026.

Several services remain in progress. Cloud VPN, Cloud Interconnect, GCE OS Login, the Cloud SDK, the gcloud CLI, GKE service mesh, and client libraries are marked 2026 or 2027, as are the Cloud Storage SDK, Storage Transfer Service, the BigQuery CLI, and Data Transfer Service.

Load balancer support uses the X25519MLKEM768 hybrid key exchange for TLS 1.3. It is currently opt-in, enabled only when an SSL policy sets it explicitly. Google’s documentation gives a three-stage rollout: disabled by default now, enabled by default after October 2026, and always on after October 2027, with a deferral setting available until that final date. API endpoints including google.com and the googleapis.com subdomains implement ML-KEM, standardized as FIPS 203, in hybrid mode.

Domain 2 covers digital signatures and attestations. Its target is the end of 2028. Binary Authorization and Access Approval are marked 2026 and Assured Open Source Software 2027.

Quantum-authentic ALTS is marked 2026 or 2027, Certificate Authority Service 2027, and Cloud IAM 2028. Google Trust Services support for Merkle Tree Certificates is marked 2028, with the rollout of PQC certificates across Google Cloud products and infrastructure scheduled across 2027 and 2028. The company says it intends to support ML-DSA certificates and, where meaningful, SLH-DSA certificates, following IETF standardization efforts still in development.

Google attributes part of the later date to unfinished standards work. The company is contributing to the IETF PLANTS working group, which is developing mechanisms to reduce the transmission and validation cost of large post-quantum signatures in certificate-transparency-based public key infrastructure. Its core Merkle Tree Certificate specification reached working-group draft revision 05 on July 6, 2026 and remains an Internet-Draft rather than an RFC. Chrome and Cloudflare have been testing the design against live traffic since February 2026.

Domain 3 is also targeted for the end of 2028, with Cloud KMS support for ML-KEM, ML-DSA, and SLH-DSA listed as generally available and quantum-safe key import marked 2026.

The hardware-backed and sovereignty rows all carry 2028, covering Confidential Computing including attestation and vTPM, a quantum-safe Cloud HSM targeting FIPS 140-3 Level 3, External Key Management, and partner enablement for key providers and sovereignty solutions.

Google says it is deploying PQC across its sovereign cloud offerings, naming Google Cloud Dedicated and Google Distributed Cloud. The same strategy extends post-quantum protections to its AI services, according to the company. The company describes the domain targets as projections, stating that most services are expected to meet them while specific product timelines may be adjusted for engineering requirements and third-party dependencies.

On hardware, Google names Caliptra v2.1, TPM 2.0 v185, and OpenTitan as quantum-safe hardware and roots-of-trust foundations. OpenTitan, the company says, already supports quantum-secure boot. The company states that the hardware transition involves both active replacement and natural equipment replacement cycles, and that the timeline for some physical components may extend beyond 2029.

The roadmap places three things on the customer side of the shared responsibility model – client-side software updates, asymmetric key lifecycle management, and quantum-safe configuration of Google Cloud services. Google retains responsibility for its network, global front ends, encryption in transit, and the ALTS protocol.

Google recommends three actions on the customer side, beginning with an inventory of cryptographic resources using Cloud Asset Inventory and Wiz, which the company describes as a way to map cryptographic resource usage and prioritize a migration backlog. The second action is updating development and site reliability engineering toolchains to software that supports PQC algorithms, naming BoringSSL, Chrome, and the SDKs. The third is validating application behavior against the quantum-safe APIs and load balancers to identify architectural bottlenecks before they reach production environments.

The document references CNSA 2.0 and the transition paths in NIST IR 8547. That report remains an initial public draft. Its tables propose deprecating classical public-key signature and key-establishment schemes at 112 bits of security strength after 2030, and disallowing the listed classical schemes after 2035. Google says it expects the work to continue into the 2030s to track evolving global standards.

The publication follows a March 25, 2026 announcement in which Google set 2029 as its company-wide PQC migration target, citing progress in quantum computing hardware, quantum error correction, and quantum factoring resource estimates. Cloudflare matched the 2029 date in April, committing to post-quantum authentication as well as encryption, and Microsoft moved its own completion target from 2033 to 2029 on June 30, 2026.

My Analysis

The 2029 date stopped being news months ago. Google set it in March, Cloudflare matched it in April, and Microsoft cut four years off its schedule at the end of June. Three major operators of internet-facing cryptography now share a single completion year.

What Haridas and Bachman published this week is a different kind of document. It is the decomposition underneath the target: 19 dated roadmap entries across three domains, several of them grouping multiple services, with labels showing which milestones Google already considers complete. Neither AWS nor Microsoft has published anything at that resolution.

Public companies disclose two entirely different things to investors. One is the audited statement of where the business actually stands. The other is forward guidance about where management intends to take it, and neither is ever accepted as a substitute for the other. A company offering only guidance would be asked for the financials, immediately and rudely, and a company offering only financials would be asked for the outlook.

Cryptographic disclosure has not reached that standard anywhere in the industry. AWS publishes a service-wise current-state table, including whether post-quantum key exchange is transparent or requires customer opt-in, and lists services where every public endpoint supports it. It attaches no completion year to its own migration at all, positioning itself instead as running ahead of regulatory deadlines like CNSA 2.0. Google Cloud has now published the forward guidance and left the running current state to be inferred from a handful of “completed” labels. Microsoft publishes a corporate date and a set of phases at product-family level.

None of the three publishes a complete service-by-service current state alongside a complete dated forward roadmap – the two halves a buyer actually needs – and I’ve been asking for both for years. What we got instead is two incompatible disclosure formats and a gap where the reconciliation should sit, which leaves every buyer assembling the picture from vendor pages that were never designed to be read together.

The Difference Between a Roadmap and a Negotiated Connection

The verification problem here isn’t hypothetical, and on the measured evidence Google earns real credit. Google-owned Wiz reported in May that every Google Cloud API server in its scan supported hybrid post-quantum key exchange, against roughly 13% of AWS API servers, concentrated in specific services like KMS, and no Azure API servers its researchers could identify.

Wiz isn’t an independent third party on this question, and the scan covers externally reachable API servers rather than anyone’s internal estate. It still tested the algorithm actually negotiated at the service boundary rather than the algorithm claimed on a product page, which is the only kind of evidence available from outside. None of us can audit a provider’s internals from outside, which is why a cryptographic inventory that stops at the vendor’s attestation stops too early. Observing what the connection negotiates is the one check no roadmap can overwrite.

Scott Piper put a harder number on the rest of the market in the same report. Across 42 cloud services with cryptographic configuration options, 81% offered no post-quantum-compliant setting at all.

The same discipline applies to the new roadmap. Load balancer post-quantum key exchange is disabled by default today, so a customer on default TLS policies has a provider-side capability and no post-quantum connection to show for it. Google will flip that default in October 2026 and remove the deferral in October 2027. Defaulting it on a year before forcing it on gives the clients that cannot negotiate the hybrid group time to surface. Until then, an opt-in capability is evidence about the provider, not evidence about the estate.

One line in that same documentation goes further than Google’s own security team ever has. The load balancer page states that the company believes TLS asymmetric cryptography could be broken by quantum computers as soon as 2029. The March blog it cites set a migration deadline and said nothing of the kind. A migration target has quietly become a CRQC arrival forecast somewhere between the security blog and the product documentation, and that is precisely the slippage this site spends its time flagging when vendors do it.

Signatures Land a Year Behind Confidentiality

Google’s March post stated that the company had adjusted its threat model to prioritize PQC migration for authentication services and digital signatures, and recommended that other engineering teams follow. The roadmap published this week puts confidentiality at the end of 2027 and integrity at the end of 2028.

Signatures trail confidentiality by a year. That is my Trust Now, Forge Later track landing behind the harvest now, decrypt later track, at an organization that said five months ago it had elevated authentication in its threat model.

The gap between risk priority and delivery sequence is not a broken promise, because a workstream can be more urgent and still finish later when it depends on more parties – urgency doesn’t buy consensus.

In April I wrote that Google’s March announcement made it the first hyperscaler to publicly put authentication ahead of encryption, and that Cloudflare had become the second within a fortnight. Our arriving at TNFL as an industry was the story then. This roadmap is the first look at what the new priority converts into on a calendar, and the answer is that the reprioritized track still lands a year behind the one it was promoted over.

Google-controlled deployment of hybrid key exchange is comparatively engineering-paced. An operator with enough engineers can enable it across its own fleet on a schedule of its own choosing, which is what Google did between 2025 and 2026.

The browser-trusted portion of signature migration is consensus-paced instead, and consensus does not accelerate under budget pressure. Certificate authorities, browser root programs, relying parties, and the standards process all have to move together. The Merkle Tree Certificate specification is at working-group draft 05 and still an Internet-Draft, which means Google Trust Services can experiment against it but cannot treat it as a settled production dependency.

A standards dependency is a more uncomfortable finding than a slipped date, because it applies to every organization dependent on public WebPKI and no amount of internal urgency shortens it.

Cloudflare is the useful control, because it shipped a signature milestone while Google was still writing one down. Cloudflare committed in April to post-quantum authentication for connections to customer origin servers by mid-2026 and shipped it on June 17, publishing the engineering account on July 29, including the June 10 incident when a BoringSSL KeyUsage enforcement change invalidated a small number of customer certificates.

Cloudflare delivered on schedule, and it is unusually candid about why that was possible. On the origin connection Cloudflare is the client, not the server, and connection pooling amortizes the cost of larger signatures across many requests. More to the point, the pre-existing account relationship with the customer let Cloudflare use a custom PKI rather than tie itself to WebPKI’s constraints and timelines. The customer still runs the origin. Cloudflare simply had a bounded, account-linked surface to deploy into, which isn’t the same thing as owning both endpoints.

Its next milestone, visitor-to-Cloudflare authentication targeting 2027, depends on Merkle Tree Certificates and the open web, and it sits much closer to Google’s 2028 row than to its own June one. A major variable across all these dates is whether the relying party is a browser the operator does not control.

AWS complicates the picture usefully, and in Google’s disfavor. AWS Private CA has supported ML-DSA certificate issuance since November 2025 and AWS KMS has offered ML-DSA signing since June 2025, while Google’s Certificate Authority Service is marked 2027. Private CA against Certificate Authority Service is a fair comparison; KMS signing against Cloud IAM is not, so this establishes something narrower than AWS leading on signatures overall. It does establish that a provider with no published completion year has shipped private-PKI capabilities the provider with the detailed roadmap hasn’t. A roadmap and a shipped capability are different objects.

The planning consequence forks cleanly enough to act on. Private PKI – the internal mutual TLS meshes, device certificates, enterprise wireless, internal code signing – need not wait for Merkle Tree Certificate standardization at all, provided the issuing CA, the HSMs, and the relying-party libraries support ML-DSA. That is PKI modernization work with its own justification. Chrome’s current path for the public web runs through Merkle Tree Certificates and therefore sits on the browser, CA, and standards schedule.

An organization that stalls its internal PKI modernization until the public web settles has confused two separate problems, and the 2027 and 2028 rows in Google’s own table are a fair proxy for what that confusion costs in calendar time.

The Discovery Tool Google Now Owns

A smaller point, in the interest of applying the same standard here that this site applies to everyone else.

The roadmap’s first recommended action is cryptographic inventory, and it names two tools for the job. One is Cloud Asset Inventory, which is Google’s. The other is Wiz, which is also Google’s.

Google closed the $32 billion acquisition of Wiz on March 11, 2026, the largest deal in the company’s history, and Assaf Rappaport’s team now sits inside Google Cloud. The post links out to a wiz.io blog and does not mention the ownership anywhere. It reads as third-party validation and it functions as a house recommendation.

That is a small disclosure miss on an otherwise unusually straight document. The standard I would apply to a vendor citing its own subsidiary as external validation applies here too.

Roots of Trust Migrate on Replacement Cycles

Google states plainly that some physical components may not complete the transition by 2029, because roots of trust migrate on equipment replacement cycles rather than on software release schedules. Caliptra, OpenTitan, and TPM 2.0 v185 are the right foundations to have chosen, and fleet turnover is one of several constraints on when they arrive everywhere, alongside design, validation, and supply cycles.

This is the most honest paragraph in the document and also the one most likely to be quoted back in 2029. Systems whose cryptographic identity is set at manufacture usually inherit the manufacturer’s replacement timeline, which is the same argument that applies to industrial controllers, vehicles, and satellites across every enterprise estate.

The sovereign cloud line is the one European readers should carry into their next procurement review. Google names Google Cloud Dedicated and Google Distributed Cloud as PQC deployment targets, which lands directly on the EU coordinated roadmap’s 2030 milestone for high-risk systems. Regulated European buyers evaluating sovereign cloud offerings now have a dated commitment they can write into a renewal.

The shared responsibility section moves three things onto the customer. Client libraries, TLS policy configuration, and asymmetric key lifecycle all remain on the customer side of the line.

Piper measured what that costs in practice. On AWS services that already support post-quantum key exchange server-side, only about 10% of observed client requests actually negotiated it, because the connection uses whatever the application’s TLS library defaults to. Server-side support is necessary and nowhere near sufficient. Any organization that files this roadmap under “the cloud provider is handling it” has misfiled it, and the load balancer opt-in default is the proof.

What Would Actually Move These Dates

One thing the roadmap does not do, to its credit, is claim a Q-Day estimate. Google’s stated reasons for the March acceleration were progress in quantum computing hardware, quantum error correction, and factoring resource estimates, which are three of the dimensions my CRQC Quantum Capability Framework tracks separately, because vendors tend to collapse them into a single number.

None of those three drives the 2027 and 2028 rows, though. Those dates are set by standards bodies, engineering dependencies, and the replacement cycle of physical hardware, and they would look much the same if the CRQC estimate moved two years in either direction. That is the argument I keep making about deadlines, and here it is in a hyperscaler’s own project plan rather than in a regulator’s guidance.

The Renewal Cycle Now Has a Document to Point At

Sunil Gentyala of HCLTech argued in an April contributed post on the Cloud Security Alliance site that cloud service agreements contained no post-quantum adoption commitments and no published migration timelines, and that enterprises renewing in 2026 had a narrow window to negotiate readiness language before the major providers published their own schedules. Which is the vendor governance argument in one sentence. Four months later, one of them has. The window narrowed exactly as predicted.

A public roadmap with named services and dated targets is a document a procurement team can put on the table and ask a vendor to stand behind. It belongs on the Global PQC Migration Clock alongside the regulatory dates. None of it is contractual, none of it appears in an SLA, and Google’s own hedge about product timelines being adjusted for engineering requirements and third-party dependencies is right there in the text. It is still considerably more than existed a week ago.

The reasonable ask in the next renewal cycle is both halves of the disclosure. The current state per service, as AWS publishes it. The dated targets per service, as Google now does. Neither one alone tells a risk owner whether their traffic is protected today or whether it will be by the date their regulator picked. Both together do, and no provider can credibly claim any longer that publishing them is premature.