Google Cloud published a post-quantum cryptography (PQC) migration roadmap on August 11, 2026, assigning target years to named services and marking the ones it considers complete. Jai Haridas, Google Cloud’s vice president and general manager for regulated and sovereign cloud, wrote the post with Michael Bachman, vice president and general manager for cloud foundations. They wrote that the work would converge on “full PQC readiness by 2029.”
Google set the end of 2027 for the first of three risk domains, protection against what it called “Store Now Decrypt Later” attacks, in which an adversary records encrypted traffic to decrypt it once a capable quantum computer exists. It set the end of 2028 for the other two domains, one for integrity and non-repudiation, which covers digital signatures, and one for foundations and key management.
Google marked post-quantum key exchange as complete for its API endpoints and its internal service traffic but said customers remain responsible for updating client software “to negotiate PQC handshakes” and for managing the lifecycle of their asymmetric keys.
What Google marked complete
Google listed quantum-confidential ALTS, the protocol it uses to authenticate and encrypt traffic between its own services, as completed in 2025. Its API endpoints, including google.com and the googleapis.com domains, use ML-KEM, formerly CRYSTALS-Kyber, “in hybrid mode,” Google wrote. In hybrid mode, ML-KEM runs alongside a classical algorithm so that a connection stays protected as long as either one is unbroken.
Google dated other services in the first domain 2026 or 2027, among them Cloud VPN and its client libraries. The company wrote that the services it highlighted “are not exhaustive lists.”
Load balancer defaults
Google’s application and proxy load balancers support X25519MLKEM768, a hybrid key exchange for TLS 1.3 that pairs the classical X25519 algorithm with ML-KEM-768. Google marked that support as completed in 2026 but made it available “on an opt-in basis” so that customers could validate it first.
According to Google’s load-balancing documentation, post-quantum key exchange stays off until a customer turns it on in an SSL policy. Google plans to make it the default after October 2026 and to keep it always enabled after October 2027. Customers can postpone the first change until October 2027 by setting the policy’s post-quantum option to DEFERRED.
Signatures and certificates
In the second domain, Google set 2026 for Binary Authorization and Access Approval. It set 2027 for Assured Open Source Software and the Certificate Authority Service, and 2028 for Cloud IAM.
Google said its internal and external certificate authorities would support certificates signed with ML-DSA, formerly CRYSTALS-Dilithium. It said it would also use SLH-DSA, formerly SPHINCS+, “where meaningful,” following IETF standards work that is still in progress.
Google set 2028 as the target for Google Trust Services to support Merkle Tree Certificates, or MTCs. MTCs are a proposed certificate format designed to reduce the number of large post-quantum signatures sent and checked in each TLS connection.
Google said it is working with the IETF’s PLANTS working group, where the specification is still an Internet-Draft. Chrome’s networking team wrote in February that “Chrome is already experimenting with MTCs with real internet traffic” and described a feasibility study with Cloudflare.
Keys and hardware
In the third domain, Google marked ML-KEM keys and ML-DSA and SLH-DSA signing keys in Cloud KMS, its key management service, as completed in 2025 and dated quantum-safe key import 2026. It dated its hardware-backed services 2028, including Confidential Computing with attestation and virtual TPMs and a quantum-safe Cloud HSM targeting FIPS 140-3 Level 3.
Google named Caliptra v2.1 and TPM 2.0 v185 among its hardware foundations. It wrote that a third, OpenTitan, “already supports quantum-secure boot.”
Google wrote that it would replace hardware actively where feasible and otherwise through “natural equipment replacement cycles.” It also wrote that “the timeline for some physical components may extend beyond 2029.”
Google wrote that it projects most services will meet their domain’s target date and that “specific product timelines may be adjusted if necessary to account for evolving engineering requirements and any third-party dependencies.”
Customer responsibilities under the Google Cloud PQC roadmap
Google said it would handle the transition of its network and its global front ends. It also kept responsibility for encryption in transit and the ALTS protocol. Customers must apply quantum-safe settings and policies to their own Google Cloud services, the company wrote.
Google recommended that customers first inventory their keys and certificates with Cloud Asset Inventory and “solutions such as Wiz’s cryptography and PQC readiness.” Google completed its acquisition of Wiz on March 11, 2026.
It also advised customers to move development and site reliability teams to software that supports PQC, such as BoringSSL. Third, Google recommended that customers test applications against its quantum-safe APIs and load balancers. Google gave no figure for how much customer traffic already uses post-quantum key exchange.
Industry dates
Google set its 2029 target on March 25 in a post by Heather Adkins, its vice president of security engineering, with Sophie Schmieg, a senior staff cryptography engineer. They cited progress in quantum hardware and error correction and in estimates of the resources needed for quantum factoring.
Cloudflare set 2029 on April 7 for full post-quantum security, including post-quantum authentication. Microsoft set the same year for its products and services on June 30.
Google also cited NSA’s CNSA 2.0 suite and “the transition paths defined in NIST IR 8547, which anticipate the final deprecation of legacy, quantum-vulnerable algorithms between 2030 and 2035.” NIST’s report was still a draft when Google published its roadmap.
Update, November 12, 2026: As of November 12, Google’s load-balancing documentation still listed post-quantum key exchange as disabled by default and said Google “will begin enabling it by default in October 2026.” NIST published the final version of IR 8547 on October 27.
