Google Cloud Sets 2029 Target for Post-Quantum Cryptography Readiness

Google Cloud's Post-Quantum Security Roadmap

Quantum computing promises major advances in areas ranging from scientific research to optimization and artificial intelligence. But the same technology could eventually threaten widely used cryptographic systems that protect today's digital communications and data.

Google Cloud is preparing for that possibility with an updated roadmap aimed at achieving full post-quantum cryptography, or PQC, readiness by 2029.

Google says it has been working toward protection against a future cryptographically relevant quantum computer for a decade. As PQC standards have matured, the company has been introducing post-quantum protections across its internal infrastructure and customer-facing services.

The updated roadmap focuses on three major security challenges:

• Protecting encrypted information from future decryption

• Preventing quantum-enabled forgery of digital signatures and identities

• Building cryptographic agility so systems can adapt as standards evolve

Google expects its major PQC migration efforts to converge in 2029, while work will continue into the 2030s as global standards and regulatory guidance develop.

Why Post-Quantum Cryptography Matters Now

The threat from quantum computing is not limited to data that might be exposed in the future.

One of the risks Google is prioritizing is known as Store Now, Decrypt Later (SNDL).

Under this scenario, an attacker can capture encrypted information today and store it until a sufficiently powerful quantum computer becomes available. If the underlying cryptography is vulnerable to quantum attacks, that previously collected information could potentially be decrypted in the future.

For organizations handling sensitive customer information, intellectual property, financial records, government data, or other long-lived secrets, waiting until quantum computers become capable of breaking existing algorithms could therefore be too late.

Google's roadmap is designed to address that risk while also preparing cloud infrastructure for quantum-resistant authentication, signatures, certificates, and key management.

Google's Strategy: Secure by Design

Google says its migration strategy is based on the Google Quantum Threat Model.

Rather than treating PQC as a single cryptographic upgrade, Google is dividing the transition into three major domains.

1. Store Now, Decrypt Later Mitigation

The first domain focuses on protecting confidential information against future quantum decryption.

This includes customer workloads, administrative and developer connections, and data pipelines.

Google is working toward quantum-confidential TLS 1.3 connections for cloud services and configured load balancers, while also upgrading management and data-transfer pathways.

2. Integrity and Non-Repudiation

The second domain focuses on digital signatures, certificates, identity, and software integrity.

A future quantum computer could potentially undermine today's public-key signatures, creating risks beyond confidentiality.

Google is therefore preparing quantum-resistant mechanisms for software attestations, certificate infrastructure, authentication, and identity systems.

3. Foundations and Key Management

The third domain is focused on cryptographic agility.

Google wants its infrastructure to be flexible enough to adopt new cryptographic standards without requiring major engineering changes every time algorithms evolve.

This includes Cloud KMS, cryptographic libraries, hardware-backed security, key import, external key management, and partner solutions.

Together, these three areas form the foundation of Google's broader quantum-readiness strategy.

Google Cloud's 2026 PQC Milestones

Google Cloud has already achieved several foundational PQC milestones in 2026 that provide immediate protection for customers.

Quantum-Safe API Endpoints

Google Cloud API endpoints now support quantum-safe key exchange.

This includes google.com and .googleapis.com, which use the NIST-standardized ML-KEM (FIPS 203) in hybrid mode.

The objective is to protect incoming traffic against the possibility that encrypted communications captured today could be decrypted by a future quantum-capable adversary.

PQC Support for Load Balancers

Google Cloud's application and proxy load balancers now support quantum-safe hybrid key exchange using X25519MLKEM768 for TLS 1.3.

The capability was initially introduced on an opt-in basis, allowing customers to validate compatibility with their existing applications before broader adoption.

Quantum-Safe Certificate Experiments

Google is also working with the IETF PLANTS Working Group on approaches for quantum-safe public key infrastructure.

One challenge is the larger size of many PQC signatures, which can affect certificate-chain validation and WebPKI performance.

Google, Chrome, and Cloudflare are experimenting with Merkle Tree Certificates as one potential approach to addressing these challenges.

PQC Algorithms in Cloud KMS

Google Cloud says ML-KEM, ML-DSA, and SLH-DSA, the NIST-standardized PQC algorithms, are now generally available in Cloud KMS for encryption and signing keys.

Google is also working toward quantum-safe key import capabilities.

These 2026 milestones establish the foundation for the broader migration planned through 2027, 2028, and 2029.

The Roadmap to 2029

Google's roadmap uses customer journeys and risk-based prioritization rather than treating every cloud service as equally urgent.

The company has identified core scenarios that security experts consider particularly exposed to the potential impact of quantum computing.

The target dates vary by domain.

2026: Foundational customer-facing PQC capabilities are already available.

2027: Major progress is targeted for protecting encrypted workloads and data flows.

2028: Google aims to complete major integrity, identity, certificate, and foundational infrastructure milestones.

2029: Google plans to achieve full PQC readiness across Google Cloud.

Work is expected to continue into the 2030s as standards and industry requirements evolve.

This longer horizon reflects the complexity of replacing cryptographic infrastructure across a global cloud environment.

Domain 1: Protecting Against Store Now, Decrypt Later

The first major roadmap domain addresses confidentiality.

The primary concern is asymmetric encryption that could eventually be broken by a cryptographically relevant quantum computer.

Google's goal is to give customers incremental protection based on the way they use Google Cloud.

Securing Customer Workloads

Google plans to provide quantum-confidential TLS 1.3 handshakes for Google Cloud services and configured load balancers.

This is intended to protect user sessions against future decryption.

Application and proxy load balancing already reached a PQC milestone in 2026.

Securing Administrator and Developer Flows

Administrative and development pathways are another priority.

Google identifies services and tools including Cloud VPN, Cloud Interconnect, GCE OS Login, Cloud SDK, gCloud CLI, GKE service mesh, and client libraries as part of this transition.

The objective is to make management and deployment infrastructure resistant to SNDL risks.

Google also points to its client libraries and Tink, its open-source cryptographic library, as important components of the developer-side transition.

Securing Data Pipelines

Data moving through analytics and storage systems can also be targeted for future decryption.

Google plans to strengthen relevant data-transfer pathways, including:

• Cloud Storage SDK

• Storage Transfer Service

• BigQuery CLI

• Data Transfer Service

The roadmap targets these SNDL-related changes for 2027.

Domain 2: Protecting Integrity and Digital Trust

Confidentiality is only one side of the quantum-security challenge.

A sufficiently capable quantum computer could also threaten cryptographic signatures used to prove that software, certificates, identities, and other digital assets are authentic.

Google's second domain therefore focuses on integrity and non-repudiation.

Securing the Software Supply Chain

Software supply chains increasingly depend on cryptographic attestations to prove that software has been built and approved correctly.

Google is working toward quantum-safe protections for services including:

• Binary Authorization

• Cloud Build

• Assured Open Source Software

The objective is to help ensure that only trusted, untampered software artifacts are deployed into production.

Google says Binary Authorization and Access Approval milestones were completed in 2026, with Assured OSS targeted for 2027.

Building Quantum-Safe Certificates

Certificates are another major challenge.

Google plans to transition public key infrastructure toward ML-DSA certificates, along with SLH-DSA where appropriate.

The company is working with industry standards bodies because large PQC signatures can create operational and performance challenges for certificate chains.

One of the approaches under experimentation is Merkle Tree Certificates.

Google's roadmap targets:

• Private CA support in 2027

• Google Trust Service Merkle Tree Certificates in 2028

• Broader PQC certificate rollout across Google Cloud products and infrastructure during 2027 and 2028

Protecting Identity and Access

Identity systems also need to become resistant to quantum-enabled forgery.

Google plans to strengthen authentication mechanisms involving service account keys and tokens, including JWT and OAuth-based systems.

The roadmap targets Cloud IAM for 2028, alongside a broader rollout of quantum-safe authentication and access mechanisms.

Domain 3: Cryptographic Agility and Key Management

Google describes cryptographic agility as the foundation of its PQC migration.

The idea is straightforward: security systems should be able to adopt new cryptographic standards without requiring major architectural changes.

This becomes increasingly important as PQC standards continue to evolve.

Cloud KMS and Cryptographic Libraries

Google is expanding support for NIST-approved PQC algorithms through Cloud KMS and cryptographic libraries including BoringSSL and Tink.

Cloud KMS already provides general availability for ML-KEM, ML-DSA, and SLH-DSA.

Google is also working on quantum-safe key import, allowing organizations to bring their own quantum-safe keys into cloud environments.

Hardware-Backed Cryptographic Security

Quantum readiness also extends below the software layer.

Google plans to incorporate PQC protections into hardware-backed security capabilities, including:

• Confidential Compute

• Attestation

• vTPM

• Cloud Hardware Security Module

The roadmap targets these hardware-related milestones for 2028.

Key Sovereignty and Partner Solutions

Organizations with strict requirements around control and location of cryptographic keys also need a PQC migration path.

Google plans to support PQC orchestration for Google Workspace Client-side Encryption and External Key Manager solutions.

The company also plans to work with partners to support PQC on-premises key providers.

Google Cloud's Shared Responsibility Model

Quantum security is not entirely a cloud provider responsibility.

Google separates the transition into two sides of the shared responsibility model.

(1) Google's Responsibility: Security of the Cloud

Google is responsible for transitioning its underlying cloud infrastructure toward quantum safety.

This includes:

• Network infrastructure

• Encryption in transit

• Global front ends

• ALTS protocol

• Servers

• Hardware

• Operating systems

Google says its ALTS protocol already supports PQC for confidentiality.

The company is also working with open-source silicon foundations including Caliptra v2.1, TPM 2.0 v185, and OpenTitan.

Google describes OpenTitan as an open-source silicon root of trust that already supports quantum-secure boot.

However, the physical transition of hardware cannot happen instantly.

Google says its approach combines active replacement where feasible with natural equipment replacement cycles. As a result, some physical infrastructure changes may extend beyond the 2029 target.

(2) Customer Responsibility: Security in the Cloud

Customers still have responsibilities.

Organizations need to manage their own applications and client-side software so they can negotiate PQC-compatible handshakes.

They also need to manage the lifecycle of asymmetric keys and update Google Cloud configurations with quantum-safe settings and policies.

This makes PQC migration a shared effort rather than something that can be completed entirely by the cloud provider.

What Organizations Should Do Now

Google's 2029 target does not mean organizations should wait until 2029 to begin.

The company recommends three practical steps.

(1) Inventory

Organizations should identify their cryptographic resources, including keys and certificates.

Google recommends using Cloud Asset Inventory along with solutions such as Wiz's cryptography and PQC readiness capabilities.

The objective is to understand where cryptography is being used and identify which systems should be prioritized for migration.

Without an inventory, organizations may struggle to determine the true size of their PQC transition.

(2) Update

Development and Site Reliability Engineering teams should begin using software that supports PQC algorithms.

Google specifically points to technologies such as:

• BoringSSL

• Chrome

• SDKs

Preparing these components early allows internal applications and workflows to negotiate quantum-safe connections as Google enables them across its infrastructure.

(3) Validate

Organizations should test their existing applications against quantum-safe APIs and load balancers.

Early validation can reveal compatibility problems and architectural bottlenecks before quantum-safe configurations become part of production environments.

The three-step approach can therefore be summarized as:

Inventory → Update → Validate

These actions allow organizations to begin preparing without waiting for the broader migration to reach its final stage.

Why the 2029 Target Matters

Google's updated roadmap signals that post-quantum cryptography is moving from long-term research into a large-scale infrastructure migration.

The company is not treating PQC as a single algorithm replacement.

Instead, the roadmap spans encryption, certificates, digital signatures, identity, key management, hardware security, software supply chains, cloud networking, and customer applications.

That breadth is important because quantum resistance needs to exist across the entire security chain.

Protecting only one layer would leave other components exposed.

The timeline also reflects the broader industry transition.

Google points to guidance such as CNSA 2.0 and the transition paths described in NIST IR 8547, which anticipate the eventual deprecation of legacy quantum-vulnerable algorithms between 2030 and 2035.

Google's 2029 target therefore places its major cloud migration ahead of those later deadlines.

What Comes After 2029?

Google describes 2029 as the point where its major PQC readiness efforts converge, not the end of quantum-security work.

The company expects efforts to continue into the 2030s as standards, industry guidance, hardware cycles, and cryptographic requirements evolve.

That continued work is particularly relevant for physical infrastructure.

Replacing or upgrading hardware at global scale is different from deploying a software update.

Google says some hardware transitions will follow natural equipment replacement cycles, meaning certain physical components may remain part of the migration process beyond 2029.

The broader objective is therefore not simply reaching a date.

It is creating an infrastructure capable of adapting as cryptographic standards continue to change.

The Bigger Picture for Cloud Security

Google Cloud's PQC roadmap highlights a larger shift in cybersecurity.

Quantum computing may still be developing, but the security transition cannot necessarily wait until quantum computers become capable of breaking today's cryptography.

Sensitive information can have a long lifespan.

Certificates, identity systems, software signatures, encryption keys, and cloud infrastructure also have complex dependencies.

Migrating these systems requires planning, testing, engineering, and coordination across organizations.

For cloud customers, the message is increasingly practical.

Quantum readiness is becoming a migration project that should begin with understanding where cryptography is used today.

Google's recommended sequence is simple:

Inventory the cryptographic environment.

Update systems and software.

Validate applications before production migration.

Conclusion

Google Cloud has set 2029 as its target for full post-quantum cryptography readiness, outlining a multi-year migration across encryption, identity, certificates, software supply chains, key management, hardware security, and cloud infrastructure.

The company has already reached several milestones in 2026, including PQC support for API endpoints and load balancers, as well as general availability of NIST-standardized PQC algorithms in Cloud KMS.

The next stages focus on protecting customer workloads and data pipelines against Store Now, Decrypt Later risks, strengthening digital signatures and identity systems, and expanding quantum-safe key management and hardware-backed security.

Google's strategy is built around three priorities: confidentiality, integrity, and cryptographic agility.

But the transition is not solely Google's responsibility.

Cloud customers will need to update applications, manage their cryptographic keys, configure quantum-safe settings, and test their systems as PQC capabilities become available.

The most important takeaway is that post-quantum security is no longer only a future research topic.

It is becoming an infrastructure migration that organizations can begin preparing for today.

The quantum era may not have arrived yet, but the cryptographic transition has already begun.