Google Cloud Encryption Explained: GMEK vs CMEK vs CSEK

Encryption in Google Cloud: the short version

When you store a file in Cloud Storage or write a row to BigQuery, Google encrypts it automatically before it hits disk. When data travels between your browser and a Google Cloud API, it goes over TLS. You do not opt in to any of this. It is always on.

The part you can control is the key. Every piece of data is encrypted with a key, and that key is itself wrapped by another key. By default, Google manages both. If your compliance requirements or risk model demands more control, you can manage the outer key yourself using Cloud KMS, Google’s managed key management service. Or, for the highest control level, you can supply raw key material yourself with each request.

The three options are:

• GMEK: Google-Managed Encryption Keys. The default. Zero operational overhead.
• CMEK: Customer-Managed Encryption Keys. You own the key in Cloud KMS. Audit trail, rotation control, and revocation ability.
• CSEK: Customer-Supplied Encryption Keys. You provide raw key material per request. Maximum control, very limited service support.

How encryption works in Google Cloud

Encryption at rest

All data stored in Google Cloud services is encrypted at rest using AES-256 by default. This applies to Cloud Storage, BigQuery, Persistent Disks, Cloud Spanner, Cloud SQL, and all other storage services. Encryption happens at the infrastructure layer before data is written to disk. There is nothing to enable.

Envelope encryption

Google uses a technique called envelope encryption to manage keys at scale. Rather than encrypting everything with one key, each data object gets its own unique key:

1. Each data object is encrypted with a unique Data Encryption Key (DEK).
2. The DEK itself is then encrypted with a Key Encryption Key (KEK) stored in Cloud KMS.
3. The encrypted DEK is stored alongside the encrypted data object.
4. To read the data: Cloud KMS unwraps the DEK using the KEK, then the DEK decrypts the data.

Disabling the KEK makes all data encrypted under it inaccessible, without needing to touch the actual data objects. That property is exactly what CMEK uses to give you revocation control.

Encryption in transit

Data in transit between Google Cloud services, and between clients and Google Cloud APIs, is encrypted using TLS. Google enforces a minimum of TLS 1.2 for connections to its APIs, with TLS 1.3 supported and preferred where both sides support it.

Traffic within Google’s internal network is protected by Application Layer Transport Security (ALTS), Google’s internal mutual authentication and encryption protocol. For on-premises connections to GCP, Cloud VPN and Cloud Interconnect with MACsec provide additional transport-layer protection.

Cloud KMS and the key hierarchy

Cloud KMS is Google Cloud’s managed key management service. It stores and manages cryptographic keys, handles key rotation, enforces IAM-based access control on key operations, and logs every key use to Cloud Audit Logs.

Cloud KMS is the foundation for CMEK. When you configure CMEK on a service like BigQuery or Cloud Storage, you are telling that service to use a specific Cloud KMS key as the KEK for your data. Every time the service needs to read or write data, it calls Cloud KMS to wrap or unwrap the relevant DEK.

This means Cloud KMS availability and key health directly affect your workloads. If a key is disabled, the service cannot decrypt your data. If a key version is destroyed, data encrypted under it is permanently unrecoverable. Before enabling CMEK in production, you need a plan for key IAM grants, key incidents, and rotation. You also need to ensure the GCP service agent for each service has the cloudkms.cryptoKeyEncrypterDecrypter role on the key.

Keys in Cloud KMS are organised into key rings, which are regional resources. Keys are versioned: you can rotate to a new version while keeping older versions available to decrypt data they previously encrypted. See the Cloud KMS overview for a full walkthrough of key rings, versions, protection levels, and IAM.

Key management options in Google Cloud

Google-managed encryption keys (GMEK)

The default for all GCP services. Google creates, stores, rotates, and protects the KEKs used to encrypt your data. You have no visibility into those keys and no direct control over them.

Who controls the key: Google
Operational overhead: Zero
Audit visibility: None (key operations are not visible to you)
Use when: Most workloads where compliance does not require customer key ownership

GMEK provides strong encryption with no effort. The trade-off is that you cannot revoke Google’s ability to decrypt your data, and there is no audit trail of when your data was decrypted by Google services. For the majority of workloads, this is the correct option.

Customer-managed encryption keys (CMEK)

You create and manage the KEK inside Cloud KMS. GCP services use your key to wrap and unwrap the DEKs they use for your data. You do not handle raw key material (Cloud KMS abstracts that), but you control the key’s lifecycle.

Who controls the key: You (via Cloud KMS)
Operational overhead: Moderate (key IAM management, service agent setup, incident planning)
Audit visibility: Full, every key operation appears in Cloud Audit Logs
Use when: Regulated data, compliance requirements for key ownership, or when you need rapid access revocation

CMEK gives you:

• Control over key rotation schedule
• The ability to disable a key version to make data inaccessible
• Full audit trails for every key wrap and unwrap operation
• Evidence of encryption key ownership for compliance frameworks

Customer-supplied encryption keys (CSEK)

You generate raw AES-256 key material and supply it directly with each API request. Google uses it for that operation only and never stores it anywhere. This means Google cannot decrypt your data independently. They have no record of the key.

Who controls the key: You (entirely external to GCP)
Operational overhead: High (you are fully responsible for generating, storing, and supplying the key material)
Audit visibility: Limited (GCP logs requests but not key material)
Use when: You have a specific threat model requiring Google to have zero stored key material and the operational maturity to manage this safely

CSEK is also supported only by Cloud Storage and Compute Engine persistent disks. It is not available for BigQuery, Cloud SQL, Cloud Spanner, or most other GCP services. If you need to store sensitive credentials or key material securely, Secret Manager is a better-fit tool for centralised secret storage with versioning and access control.

GMEK vs CMEK vs CSEK at a glance

When to use each option

Use GMEK when

• Your workload has no compliance requirement for customer key ownership
• You want strong encryption without any operational overhead
• Your data does not require an audit trail of key operations
• You are in development or early-stage and want to keep things simple

GMEK is the right default for most workloads. Do not add CMEK complexity unless you have a clear reason.

Use CMEK when

• A compliance framework (PCI-DSS, HIPAA, FedRAMP, ISO 27001) requires you to demonstrate ownership and control of encryption keys
• You need an audit trail showing when your data encryption keys were used
• You need the ability to rapidly revoke access to a dataset by disabling a key version
• Your risk model requires that your team, not Google, controls key rotation timing
• You are handling regulated data such as financial records, health data, or PII at scale

Before enabling CMEK in production: grant service agents the correct IAM roles, test end-to-end in a non-production environment, and document your incident response plan for a key being accidentally disabled. Apply least privilege to key IAM and restrict who can disable or destroy key versions.

Use CSEK when

• Your threat model requires that GCP never holds stored key material in any form
• You have internal key management infrastructure capable of reliably supplying key material per request
• You are working exclusively with Cloud Storage or Compute Engine disks
• Your team has the operational maturity to manage raw key material without a managed service as a safety net

Most teams who think they need CSEK actually need CMEK. CSEK provides stronger theoretical isolation but at significant practical cost: very limited service support, no recovery if the key is lost, and high operational complexity. Choose CSEK only when the threat model genuinely demands it.

Verifying and configuring encryption

Use the commands below to check whether a resource is using Google-managed or customer-managed encryption, and to configure CMEK where needed. An empty result from a describe command means Google-managed encryption is active, not that data is unencrypted.

# Check whether a Cloud Storage bucket has a CMEK key configured
gcloud storage buckets describe gs://my-app-prod-data \
  --format="value(encryption.defaultKmsKeyName)"
# Empty output = Google-managed encryption (NOT unencrypted)
# A KMS key path = CMEK is configured

# Configure a Cloud Storage bucket to use a CMEK key by default
gcloud storage buckets update gs://my-app-prod-data \
  --default-encryption-key=projects/my-app-prod/locations/europe-west2/keyRings/prod-ring/cryptoKeys/storage-key

# Check the CMEK key configured on a BigQuery dataset
bq show --format=prettyjson my-app-prod:my_dataset | jq '.defaultEncryptionConfiguration'

# Create a Compute Engine disk with CMEK
gcloud compute disks create app-data-disk \
  --project=my-app-prod \
  --zone=europe-west2-a \
  --size=100GB \
  --kms-key=projects/my-app-prod/locations/europe-west2/keyRings/prod-ring/cryptoKeys/disk-key

For a full walkthrough of enabling CMEK across services, see the CMEK configuration guide. Key rotation and automatic secret management is covered in rotating secrets automatically.

Frequently asked questions

Is data in Google Cloud encrypted by default?

Yes. All data at rest in GCP is encrypted with AES-256 by default, at no additional cost. This includes Cloud Storage, BigQuery, Persistent Disks, Cloud SQL, Cloud Spanner, and all other storage services. All data in transit uses TLS 1.2 minimum. You do not need to opt in or configure anything to get these protections.

What is the difference between CMEK and CSEK?

CMEK uses Cloud KMS to store and manage your key. GCP services call Cloud KMS to wrap and unwrap data encryption keys on your behalf. You control the lifecycle of the key (rotation, disabling, destroying) but you do not handle raw key bytes yourself. CMEK is supported across most GCP services.

CSEK requires you to provide raw AES-256 key bytes with each API request. Google uses the key for that operation only and never stores it. Maximum control, but supported only by Cloud Storage and Compute Engine disks. If the key is lost, the data is permanently unrecoverable.

Does CMEK mean Google cannot access my data?

Not exactly. CMEK means Google cannot decrypt your data without using your key in Cloud KMS. If you disable or destroy the key, the data becomes inaccessible, including to Google. However, CMEK primarily gives you audit visibility, rotation control, and revocation ability. For stronger isolation, consider CSEK or external key managers (EKM) via Cloud KMS.

Which GCP services support CSEK?

CSEK is supported by Cloud Storage (object encryption) and Compute Engine persistent disks. It is not available for BigQuery, Cloud SQL, Cloud Spanner, Pub/Sub, or most other GCP services. If you need customer-controlled keys across a broader range of services, CMEK is the practical option.

Does encryption replace IAM in GCP?

No. Encryption protects data at the storage layer against physical and infrastructure threats. IAM controls who can request that data through the API. A user or service account with the right IAM role can read encrypted data just as easily as unencrypted data. See IAM policies in GCP for how to configure access controls alongside encryption.