Google Cloud PQC Roadmap: Post-Quantum Cryptography by 2029

Google Cloud has published an updated roadmap to migrate its infrastructure and customer-facing services to post-quantum cryptography (PQC) by 2029. The announcement is more than a future-looking statement: several customer-facing protections are already available in 2026, including hybrid quantum-safe key exchange for Google Cloud API endpoints and load balancers, plus NIST-standardized PQC algorithms in Cloud KMS.

The message for security teams is clear: the quantum transition is no longer only a cryptography research problem. It is now a cloud migration, inventory, identity, certificate, and application-compatibility problem.

This article summarizes the roadmap announced by Google Cloud on August 12, 2026, and explains what organizations should do next.

Google Cloud’s PQC strategy in four domains

Google Cloud says its migration is based on the Google Quantum Threat Model and prioritizes three security domains:

1. Store Now, Decrypt Later (SNDL): Protect data encrypted today from being harvested and decrypted by a future cryptographically relevant quantum computer (CRQC).
2. Integrity and non-repudiation: Replace vulnerable digital-signature and authentication mechanisms so attackers cannot forge identities, certificates, attestations, or data.
3. Foundations and key management: Build cryptographic agility into key-management systems, libraries, hardware, and cloud services so future algorithm changes do not require another large-scale redesign.
4. Infrastructure: Maintain hardware integrity through quantum-safe, open-source silicon foundations such as Caliptra v2.1, TPM 2.0 v185, and OpenTitan.

Google also says it is extending PQC work to sovereign cloud initiatives such as Google Cloud Dedicated and Google Distributed Cloud, as well as AI services and other workloads that depend on cloud encryption and identity.

2026 milestones: what is already available

The 2026 roadmap includes several important customer-facing milestones:

• Google Cloud API endpoints: google.com and *.googleapis.com now support NIST-standardized ML-KEM, based on FIPS 203, in hybrid key-exchange mode.
• Application and proxy load balancers: Support the opt-in X25519MLKEM768 hybrid key exchange for TLS 1.3, allowing customers to test quantum-safe connections before broader enforcement.
• Cloud KMS: NIST-standardized ML-KEM, ML-DSA, and SLH-DSA algorithms are generally available for encryption and signing keys.
• PQC certificate research: Google is working with the IETF PLANTS Working Group and experimenting with Merkle Tree Certificates to address the size and performance challenges of post-quantum certificates.
• Quantum-confidential internal traffic: Google’s ALTS protocol already supports PQC for confidentiality, with quantum-safe authentication continuing as a roadmap item.

These milestones show the difference between hybrid migration and a risky “replace everything at once” approach. Hybrid key exchange combines classical and post-quantum mechanisms while organizations validate compatibility, performance, and operational behavior.

For a deeper explanation of hybrid TLS and ML-KEM, see The Quantum-Proof Handshake: Your Blueprint for Migrating to Post-Quantum TLS.

The Google Cloud PQC roadmap to 2029

Google Cloud’s roadmap is organized around customer journeys rather than one global cutover date. Most service timelines are targets and may change because of engineering requirements, standards development, or third-party dependencies.

Security domain	Target	Main focus
Store Now, Decrypt Later mitigation	End of 2027	Quantum-safe ingress, administration and developer flows, VPN, Interconnect, client libraries, and data pipelines.
Integrity and non-repudiation	End of 2028	Quantum-safe software attestations, certificates, signatures, IAM, and authentication.
Foundations and key management	End of 2028	PQC key import, KMS, cryptographic libraries, Confidential Computing, HSM, EKM, and sovereignty solutions.
Full Google Cloud PQC readiness	2029	Convergence of the major infrastructure and customer-service migration efforts.

Google expects the work to continue into the 2030s as global standards mature and legacy quantum-vulnerable algorithms are eventually deprecated. The roadmap references CNSA 2.0 and NIST IR 8547, which anticipate final deprecation paths between 2030 and 2035.

Domain 1: Store Now, Decrypt Later mitigation

The first domain addresses the confidentiality risk created by harvesting encrypted traffic today. An attacker does not need a quantum computer now if the captured data will remain valuable for years and can be decrypted later.

Google Cloud is prioritizing three customer journeys:

Protecting customer workloads

Quantum-safe ingress will protect the cloud perimeter and user sessions through standardized post-quantum algorithms. Application and proxy load balancing already supports hybrid key exchange on an opt-in basis, with broader SNDL mitigation targeted for the end of 2027.

Protecting administrator and developer flows

The roadmap covers Cloud VPN, Cloud Interconnect, GCE OS Login, the Cloud SDK, the gcloud CLI, GKE service mesh, client libraries, and related management paths. These connections matter because a quantum migration that protects public application traffic but leaves privileged administration channels exposed is incomplete.

Protecting data pipelines

Google also plans to address data movement through services such as the Cloud Storage SDK, Storage Transfer Service, BigQuery CLI, and Data Transfer Service. Long-lived intellectual property, customer records, research data, and regulated information should be prioritized according to their confidentiality lifetime.

The Definitive PQC Migration Checklist provides a practical way to inventory TLS, SSH, OpenSSL, cloud services, keys, and certificates before beginning this work.

Domain 2: Integrity and non-repudiation

Encryption protects confidentiality, but it does not solve quantum threats to signatures and identity. A future quantum attacker could target certificates, signed software, service-account credentials, tokens, and other public-key mechanisms to forge trust.

Google Cloud’s integrity roadmap includes:

• Quantum-safe software attestations: Binary Authorization, Cloud Build, and Assured Open Source Software will help ensure that only trusted and untampered images reach production.
• Quantum-safe certificates: Google is working toward ML-DSA and, where appropriate, SLH-DSA certificates across private and public trust systems.
• Merkle Tree Certificates: These experiments aim to reduce the operational and performance impact of large PQC signatures in WebPKI certificate chains.
• Private CA support: Certificate Authority Service is targeted for quantum-safe certificate support.
• Quantum-safe identity: Cloud IAM and broader infrastructure authentication are targeted for NIST-standardized signatures between 2027 and 2028.

This is an important evolution in the migration conversation. Early PQC planning focused heavily on key exchange and SNDL. The next phase must also protect who is trusted to sign, authenticate, deploy, and authorize.

The recent Cloudflare post-quantum authentication to origins offers a useful comparison because it shows how ML-DSA can protect origin authentication, not only session confidentiality.

Domain 3: Foundations and key management

Cryptographic agility is the foundation of the entire plan. Applications should be able to change algorithms, keys, certificates, and protocol settings without a major rewrite or an emergency migration.

Google Cloud’s foundation work includes:

• Cloud KMS: ML-KEM, ML-DSA, and SLH-DSA are available, while quantum-safe key import supports bring-your-own-key migration scenarios.
• Libraries: BoringSSL and Tink provide implementation foundations for quantum-safe protocols and application cryptography.
• Hardware-backed protection: Confidential Computing, attestation, vTPMs, and a quantum-safe Cloud HSM are part of the longer-term roadmap.
• Key sovereignty: External Key Management, Google Workspace Client-side Encryption, and partner-managed key providers are included in the 2028 target horizon.

The Google Cloud Next 2026 security recap provides additional context on Google’s KMS quantum-safe key-import work and the wider cloud security announcements.

Shared responsibility for quantum safety

Google Cloud describes PQC as a shared responsibility:

Google’s responsibility: security of the cloud

Google is responsible for transitioning its network, global front ends, encryption-in-transit systems, ALTS, servers, operating systems, and underlying hardware. The company also highlights open silicon foundations such as Caliptra, TPM, and OpenTitan, including quantum-secure boot capabilities.

Customer responsibility: security in the cloud

Customers still need to:

• update applications and client libraries so they can negotiate PQC or hybrid handshakes;
• manage the lifecycle of asymmetric keys and certificates;
• configure quantum-safe settings and policies in Google Cloud services;
• test load balancers, APIs, SDKs, VPNs, and service-to-service connections; and
• identify systems that depend on RSA, classical Diffie-Hellman, ECDH, or vulnerable signature algorithms.

A cloud provider’s roadmap reduces infrastructure work, but it does not automatically make customer applications quantum-safe.

Three actions to start your Google Cloud PQC migration

Google Cloud recommends a practical sequence that works beyond Google Cloud as well:

1. Inventory: Identify cryptographic resources, including keys, certificates, algorithms, protocols, libraries, and service dependencies. Cloud Asset Inventory and cryptography discovery tools can help create a migration backlog.
2. Update: Ensure development and SRE teams use PQC-capable software such as current BoringSSL, Chrome, SDKs, and supported client libraries. Build cryptographic agility into new services rather than adding it after deployment.
3. Validate: Test existing applications against quantum-safe APIs and load balancers. Look for handshake failures, packet-size issues, certificate-chain problems, incompatible clients, latency changes, and hard-coded algorithm assumptions.

For an executive-level approach to prioritization, data longevity, governance, and migration sequencing, read The Quantum Horizon: Your PQC Migration Strategy Can’t Wait.

What this means for security teams

Google Cloud’s 2029 target makes PQC planning more concrete, but the deadline should not be interpreted as permission to wait until 2029. The highest-priority systems are those handling data that must remain confidential for many years, internet-facing services with long-lived sessions, certificate and identity infrastructure, software supply chains, and cross-cloud connections that depend on classical public-key cryptography.

The migration should be treated as a program of discovery, prioritization, hybrid deployment, validation, and continuous crypto-agility. Organizations that begin with an accurate cryptographic inventory will have more options when standards, provider defaults, and regulatory deadlines converge.

Conclusion

Google Cloud’s post-quantum cryptography roadmap moves PQC from an abstract future concern into a staged cloud-security program. Key exchange protections are already appearing at API endpoints and load balancers. Cloud KMS now provides standardized PQC algorithms for encryption and signing. The next milestones extend protection to data pipelines, certificates, software attestations, IAM, hardware roots of trust, and customer-controlled keys.

The best time to begin is before a provider changes a default or a certificate ecosystem forces an emergency migration. Inventory your cryptography, update your clients, and validate hybrid PQC connections now.

To further enhance your cloud security and start PQC migration, contact me on LinkedIn Profile or [email protected].

Frequently Asked Questions (FAQ)

What is Google Cloud post-quantum cryptography roadmap ?

Google Cloud's roadmap is a staged plan to achieve full post-quantum readiness by 2029. It covers Store Now, Decrypt Later protection, quantum-safe signatures and identity, cryptographic agility, Cloud KMS, certificates, hardware, networking, and customer-facing cloud services.

What PQC algorithms does Google Cloud support in 2026 ?

Google Cloud says Cloud KMS generally supports the NIST-standardized ML-KEM, ML-DSA, and SLH-DSA algorithms for encryption and signing keys. Google Cloud API endpoints also support hybrid ML-KEM key exchange, and supported load balancers offer X25519MLKEM768 for TLS 1.3.

What is the Google Cloud PQC migration deadline ?

Google Cloud plans to achieve full post-quantum readiness by 2029. Major roadmap domains have earlier targets: Store Now, Decrypt Later mitigation is targeted for the end of 2027, while integrity, non-repudiation, foundations, and key-management milestones are targeted for the end of 2028.

What is Store Now, Decrypt Later in post-quantum security ?

Store Now, Decrypt Later describes an attack in which adversaries capture encrypted data today and retain it until a future quantum computer can break the underlying public-key cryptography. Organizations should prioritize long-lived sensitive data, internet-facing TLS, administrative connections, and data pipelines.

Do Google Cloud customers need to do anything for PQC?

Yes. Customers remain responsible for their applications, client libraries, asymmetric-key lifecycle, certificates, service configurations, and compatibility testing. Start by inventorying cryptographic assets, updating PQC-capable software, and validating quantum-safe APIs, load balancers, and internal service connections.

How should organizations prepare for Google Cloud PQC roadmap ?

Build a cryptographic inventory, classify data by confidentiality lifetime, identify RSA and classical elliptic-curve dependencies, test hybrid ML-KEM connections, plan ML-DSA certificate and identity changes, and design systems for cryptographic agility. Do not wait for a final 2029 cutover to discover incompatible clients or hard-coded algorithms.

Sources

• Google Cloud: PQC in Plaintext: Google Cloud’s post-quantum cryptography roadmap
• Google Cloud: Post-quantum cryptography resources
• NIST: FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST: FIPS 205: Stateless Hash-Based Digital Signature Standard

This article summarizes and adapts information from Google Cloud’s official announcement. Product timelines and availability may change as standards, engineering requirements, and third-party dependencies evolve.