Google Cloud Post-Quantum Support in 2026

Google has been one of the most aggressive movers in the post-quantum cryptography (PQC) space. In March 2026, the company publicly committed to completing its full PQC migration across Chrome, Android, Google Cloud, and internal infrastructure by 2029. Unlike some vendors that announce roadmaps without shipping code, Google has already deployed PQC in production across multiple layers of its stack.

This article separates what is production-ready and generally available from what is still in preview, planned, or missing entirely. All information is verified against official Google Cloud documentation and announcements as of August 2026.

Cloud KMS: The centerpiece

Google Cloud Key Management Service (Cloud KMS) is where the most concrete PQC capabilities live. The maturity differs by workflow: post-quantum digital signatures are generally available (GA), while KEM operations and quantum-safe key import are Preview features. Those statuses are not interchangeable.

Digital signatures (GA)

Cloud KMS supports the following PQC signature algorithms in production:

Algorithm	NIST Standard	Security Level	Status
ML-DSA-44	FIPS 204	Level 2	GA
ML-DSA-65	FIPS 204	Level 3	GA
ML-DSA-87	FIPS 204	Level 5	GA
SLH-DSA-SHA2-128s	FIPS 205	Level 1	GA

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a lattice-based scheme offering fast signing and verification with relatively compact signatures. SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) provides an alternative based on hash functions rather than lattice assumptions, giving organizations algorithm diversity.

Google first announced quantum-safe digital signatures in Cloud KMS in preview in February 2025. The move to GA happened in July 2026, making these algorithms available with full production support and SLAs.

Key encapsulation (Preview)

Cloud KMS also supports post-quantum key encapsulation mechanisms (KEMs):

Algorithm	NIST Standard	Status
ML-KEM-768	FIPS 203	Preview
ML-KEM-1024	FIPS 203	Preview
X-Wing	Hybrid ML-KEM-768 + X25519	Preview

Google’s Cloud KMS release notes introduced these KEM algorithms in Preview in September 2025. You can create a KEM key with key purpose KEY_ENCAPSULATION, retrieve the public key, perform encapsulation in your client, and use Cloud KMS for decapsulation. Cloud KMS does not perform the encapsulation step. X-Wing combines ML-KEM-768 with the classical X25519 mechanism.

Quantum-safe key import (Preview)

On August 6, 2026, Cloud KMS added three Preview import methods that protect key material while it travels from a customer-controlled environment into Cloud KMS:

Import method	Construction	Status	Target protection level
`HPKE_KEM_XWING_HKDF_SHA256_AES_256_GCM`	X-Wing KEM, HKDF-SHA256, AES-256-GCM	Preview	Software only
`HPKE_KEM_ML_KEM_768_HKDF_SHA256_AES_256_GCM`	ML-KEM-768, HKDF-SHA256, AES-256-GCM	Preview	Software only
`HPKE_KEM_ML_KEM_1024_HKDF_SHA256_AES_256_GCM`	ML-KEM-1024, HKDF-SHA256, AES-256-GCM	Preview	Software only

This is an import transport protection feature, not a new encryption algorithm for data at rest. Local tooling uses the import job’s public key and HPKE to encapsulate a shared secret, derive a wrapping key with HKDF-SHA256, and encrypt the key material with AES-256-GCM. Cloud KMS decapsulates and unwraps the material when it creates a new version of the target key.

It also differs from a PQ signature. ML-DSA and SLH-DSA prove authenticity and integrity. ML-KEM and X-Wing establish the secret used to protect key material during import. Enabling one workflow does not make an application, project, or entire cloud workload quantum-safe.

Requirements and limitations

The feature is Pre-GA and subject to the Preview terms.
The target key must use the SOFTWARE protection level. These methods do not import into Cloud HSM, Cloud HSM Single-tenant, or Cloud EKM keys.
The local cryptographic library must support HPKE plus the selected KEM, HKDF-SHA256, and AES-256-GCM.
The caller needs the Cloud KMS Importer role or Cloud KMS Admin role.
An import job expires after three days.
The imported material becomes a new key version. Google recommends an empty import-only key when it will contain only imported versions.

For a pilot, inventory externally generated keys, select a non-production software-backed target, create a short-lived import job, wrap the material locally, import it, and validate the new version. Keep the existing import path until compatibility, audit logging, role separation, and recovery have been tested. See the cryptographic inventory guide and PQC migration checklist.

Pre-hash and external-mu variants

One practical challenge with PQC signatures is payload size. ML-DSA signatures are larger than ECDSA signatures, and transmitting large messages to a remote signing service adds latency and bandwidth costs.

Cloud KMS addresses this with support for pre-hash and external-mu (external-μ) variants of both ML-DSA and SLH-DSA. In this model, your application hashes the message locally and sends only the small digest to Cloud KMS for signing. This approach:

Reduces bandwidth between your application and the signing service
Lowers latency for large payloads
Binds the public key to the message representative (improving non-resignability)
Remains compatible with pure ML-DSA verifiers

This is particularly relevant for organizations handling large files, bulk signing operations, or high-throughput transaction signing.

PQC insights dashboard

The Cloud KMS Asymmetric PQC insights chart is Generally Available as of July 7, 2026. It identifies how many and which asymmetric keys use algorithms susceptible to a future cryptographically relevant quantum computer. This is an inventory input, not proof that every use of those keys or every application dependency has been discovered.

Keep this GA dashboard status separate from the Preview status of Cloud KMS KEM operations and quantum-safe key import. The dashboard reports posture; it does not upgrade those cryptographic workflows to GA.

GCP network encryption: ML-KEM by default

Since June 2025, Google has used ML-KEM for cryptographic key exchange in its internal network encryption layer. The announcement stated:

All Google and select Google Cloud-native services are safeguarded by default using Google Cloud network encryption, using ML-KEM for cryptographic key exchange.

This means customer workloads running on Google Cloud benefit from post-quantum protection for data in transit between Google data centers without any configuration changes. This applies to traffic flowing over Google’s internal network backbone.

What this covers:

Inter-service communication within Google’s infrastructure
Traffic between Google Cloud regions
Communication between Google Cloud-native services

What this does not cover:

TLS connections from your users to your application (that depends on your TLS stack)
Traffic between your VMs or containers (that depends on your application-layer encryption)
Connections to external services outside of Google’s network

BoringSSL: The engine underneath

BoringSSL is Google’s fork of OpenSSL, used across Chrome, Android, and Google Cloud services. It underpins most of Google’s TLS implementation.

BoringSSL has supported X25519MLKEM768 (hybrid post-quantum key agreement combining X25519 ECDH with ML-KEM-768) since August 2024. This is the same mechanism used in Chrome and in Google’s internal network encryption.

For GCP services that use BoringSSL for their TLS termination, post-quantum key exchange is available and often enabled by default for connections within Google’s network. However, the availability for customer-facing endpoints varies by service and is not uniformly documented.

Chrome: PQC key agreement in production

Chrome is arguably Google’s most visible PQC deployment. Chrome enabled X25519MLKEM768 as the default key agreement mechanism for TLS 1.3 connections starting with Chrome 124 in April 2024. As of early 2026, post-quantum key exchange reaches over 30% of all TLS 1.3 handshakes globally, according to Cloudflare Radar telemetry.

Current status

Feature	Status	Since
X25519MLKEM768 key agreement	Default (production)	Chrome 124, April 2024
Post-quantum signatures in certificates	Not supported	N/A
Merkle Tree Certificates	Under development	N/A

Chrome negotiates X25519MLKEM768 for regular HTTPS and HTTP/3 connections. The hybrid approach means that even if ML-KEM were somehow broken, the classical X25519 component still provides security equivalent to today’s TLS.

Chrome’s approach to post-quantum signatures

Chrome is not planning to add standard X.509 post-quantum certificates to the public Chrome Root Store in the traditional way. Instead, Google is developing Merkle Tree Certificates (MTCs) through the IETF PLANTS working group. This is currently in a feasibility study phase with Cloudflare.

The reasoning is that ML-DSA signatures are significantly larger than ECDSA signatures (approximately 2,420 bytes for ML-DSA-44 versus 64 bytes for ECDSA-P256), which would dramatically increase the size of certificate chains and TLS handshakes. MTCs aim to solve this bandwidth problem through a different certificate format entirely.

Enterprise policy controls

For enterprise deployments that encounter compatibility issues with post-quantum key agreement (some legacy middleboxes and proxies cannot handle the larger ClientHello messages), Chrome provides the DevicePostQuantumKeyAgreementEnabled policy to control this behavior at the device level.

Certificate Authority Service: Not yet PQC-ready

Google Cloud Certificate Authority Service (CAS) is a managed service for issuing and managing private certificates. As of August 2026, CAS does not support post-quantum signature algorithms for certificate issuance.

Google Trust Services (the public CA that issues TLS certificates for Google domains) has stated on its FAQ page that “Post-quantum ciphers (PQC) and hybrid PQC will be added as soon as the CA/Browser Forum standardizes PQC parameters for the Web PKI.”

This is a significant gap for organizations that want to issue PQC certificates within their private PKI using GCP services. The CA/Browser Forum has not yet finalized requirements for post-quantum certificates in the Web PKI, which explains the delay. However, you can use Cloud KMS keys with PQC algorithms to sign certificates manually if you build your own issuance pipeline.

Workaround

If you need PQC certificates today on GCP:

Create ML-DSA signing keys in Cloud KMS
Use an external CA solution (such as EJBCA or step-ca) that can call Cloud KMS for signing operations
Issue certificates signed with ML-DSA through that external CA

This approach works for private/internal PKI. For public-facing Web PKI certificates, you will need to wait for CA/Browser Forum standardization.

Google’s 2029 migration timeline

In March 2026, Google publicly committed to completing its full PQC migration by 2029. This timeline covers Chrome, Android, Google Cloud, and all internal infrastructure. Key aspects of this commitment:

Migration priority: authentication services first, then data-at-rest protection
Aligned with NIST IR 8547 timeline (which deprecates quantum-vulnerable algorithms after 2030 and disallows them after 2035)
Positioned one year ahead of the NIST deprecation deadline

This timeline means GCP customers should expect to see PQC support expand across additional services between now and 2029, with authentication-related services likely upgraded first.

What is still missing

Despite strong progress, several GCP services still lack PQC support as of August 2026:

Service	PQC status	Notes
Certificate Authority Service	No PQC	Waiting for CA/Browser Forum standards
Cloud HSM	No quantum-safe import method	The new Preview import workflow is limited to software-backed target keys
Secret Manager	No PQC at rest	Encryption keys are classical
Cloud Load Balancer (customer-facing TLS)	Partial	Depends on BoringSSL config, not user-configurable
VPC encryption	Not PQC	Service mesh/mTLS uses classical certs
Binary Authorization	No PQC signatures	Attestation uses classical signing

Comparison with AWS and Azure

For a maintained capability-by-capability matrix, see AWS vs Azure vs Google Cloud post-quantum support.

For context, here is how GCP compares to other major cloud providers on PQC support:

AWS: Offers hybrid PQ TLS (ECDH + ML-KEM) for API connections to KMS, ACM, Secrets Manager, S3, and Payment Cryptography. Opt-in via SDK configuration. ML-DSA signatures available in KMS.

Azure: SymCrypt library supports ML-KEM and ML-DSA in production since mid-2025. Azure Key Vault PQC support is in preview. Windows Server 2025 supports ML-DSA natively.

GCP: Cloud KMS supports ML-DSA and SLH-DSA signatures in GA. KEM operations and quantum-safe key import are Preview. Network encryption uses ML-KEM by default. Chrome provides client-side PQ key exchange. Certificate Authority Service lacks PQC support.

GCP’s advantage is in the network layer (default PQC encryption for internal traffic) and in Chrome (default PQC for billions of browsers). Its weakness is the gap in certificate services and the lack of customer-configurable PQ TLS for service endpoints.

How to start using PQC on GCP today

Step 1: Create ML-DSA signing keys

gcloud kms keys create my-pqc-key \
  --keyring=my-keyring \
  --location=global \
  --purpose=asymmetric-signing \
  --default-algorithm=ml-dsa-65

Step 2: Sign data with ML-DSA

gcloud kms asymmetric-sign \
  --key=my-pqc-key \
  --keyring=my-keyring \
  --location=global \
  --digest-algorithm=sha256 \
  --input-file=message.txt \
  --signature-file=signature.bin

Step 3: Create ML-KEM keys for key encapsulation

gcloud kms keys create my-kem-key \
  --keyring=my-keyring \
  --location=global \
  --purpose=key-encapsulation \
  --default-algorithm=ml-kem-768

Step 4: Use the PQC insights dashboard

Navigate to Cloud KMS in the Google Cloud Console and check the PQC insights view to identify classical keys that need migration planning.

Step 5: Pilot quantum-safe import

Follow Google’s quantum-safe import procedure with a software-backed target and one of the three exact HPKE methods. Wrap the source material locally, import it before the job’s three-day expiry, and verify the resulting key version. Do not use this path for HSM-backed targets.

Practical recommendations

Start with Cloud KMS. Use GA ML-DSA or SLH-DSA signing where it fits your production requirements. Keep ML-KEM, X-Wing, and quantum-safe import testing in a non-production Preview evaluation.
Inventory your classical keys. Use the PQC insights chart to understand your migration scope.
Do not wait for Certificate Authority Service. If you need PQC certificates now, use Cloud KMS signing keys with an external CA.
Leverage existing protection. Your GCP-to-GCP traffic already benefits from ML-KEM in the network layer without any action on your part.
Plan for 2029. Google’s own deadline suggests that by 2029, PQC will be the default across all GCP services. Plan your migration to complete before that date.

Frequently asked questions

Is Cloud KMS PQC support production-ready?

Partly. ML-DSA and SLH-DSA signing are GA. Cloud KMS KEM operations and the HPKE-based quantum-safe key import methods are Preview. Evaluate each workflow against its documented service terms.

Does my GCP traffic already use post-quantum encryption?

Traffic between Google Cloud services on Google’s internal network uses ML-KEM for key exchange by default. However, traffic from external clients to your GCP workloads depends on your TLS configuration and the client’s capabilities.

Can I issue PQC certificates using GCP?

Not directly through Certificate Authority Service. You can create ML-DSA signing keys in Cloud KMS and use them with an external CA solution to sign certificates. Native CAS support is expected to follow CA/Browser Forum standardization.

What about Cloud HSM?

The quantum-safe key import Preview supports only software-backed target keys. It does not support Cloud HSM, Cloud HSM Single-tenant, or Cloud EKM targets. Do not infer HSM support from other PQC features in Cloud KMS.

How does Chrome’s PQC relate to GCP?

Chrome uses X25519MLKEM768 for TLS key agreement by default. If your GCP application serves HTTPS traffic and the server supports this cipher suite (which BoringSSL-based servers do), Chrome users connecting to your application will negotiate post-quantum key exchange automatically.

Should I enable PQC now or wait?

For key exchange (protecting data in transit against future quantum decryption), there is immediate value in enabling PQC today because of the harvest-now-decrypt-later threat. For signatures (protecting data integrity), the urgency depends on how long your signed data needs to remain trustworthy. If your signatures need to be valid for more than 10 years, start now.

What is Google’s timeline for full GCP PQC support?

Google has committed to completing PQC migration across all products and services by 2029. This aligns with (and slightly precedes) the NIST IR 8547 deprecation timeline, which marks 2030 as the deprecation date for 112-bit classical algorithms and 2035 as the disallowance date for all quantum-vulnerable public-key algorithms.

Sources

Google Cloud KMS release notes — Status history and exact import method names
Google Cloud: Quantum-safe key import — Import workflow, roles, expiry, and software-only limitation
Google Cloud: Key encapsulation mechanisms — ML-KEM and X-Wing behavior
Google Cloud: Digital signatures — Signing workflow and algorithms
Google Cloud Blog: Future-proofing data integrity — Quantum-safe digital signatures in Cloud KMS — GA announcement for ML-DSA and SLH-DSA signing in Cloud KMS (July 2026)
Cloud KMS release notes, PQC Insights GA, signing GA, KEM Preview, and quantum-safe import Preview status history
Google Cloud Blog: How we’re helping customers prepare for a quantum-safe future — ML-KEM for internal network encryption by default (June 2025)
Google Blog: Digital security in the Quantum Era — Google’s 2029 PQC migration timeline commitment
Google Cloud Blog: Announcing quantum-safe Key Encapsulation Mechanisms in Cloud KMS — KEM preview announcement (June 2025)
Google Cloud Blog: Announcing quantum-safe digital signatures in Cloud KMS — ML-DSA preview announcement (February 2025)
NIST IR 8547: Transition to Post-Quantum Cryptography Standards — Federal deprecation timeline: 2030 deprecation, 2035 disallowance
NIST FIPS 203: ML-KEM Standard — ML-KEM specification