Google Cloud encrypts all customer content at rest by default with AES-256, and Google owns and manages those default keys. If you need to own, rotate, log or revoke keys yourself, you use Cloud KMS, either customer-managed keys (CMEK) or Autokey. The choice is about control and evidence, not about whether data is encrypted.
What does Google do by default?
Google's documentation says all customer content stored at rest is encrypted at the storage layer with AES-256, with no action needed from you. Encryption is done through a shared cryptographic library, Tink, which includes a FIPS 140-2 validated module called BoringCrypto. Google owns and manages the keys used for this default layer.
Google also notes that data from multiple customers is typically protected under shared key encryption keys. You cannot see metadata for these keys, set their rotation, or read usage logs for them. That is fine for many workloads. It is not fine when a regulator or a customer contract says "you must control the key".
The default page carries a note that it was last updated in May 2024, so check the current text before you quote it in an audit answer.
What are the three key options?
Google's CMEK overview compares three models.
- Google-owned and Google-managed (default). Google owns the key. Nothing to configure, and no key metadata, rotation control or key usage logs for you.
- Cloud KMS Autokey. You own the key. Creation and assignment are automated, and you still see metadata, control rotation and get logs.
- Cloud KMS customer-managed (manual). You own the key and control creation, protection level, access, rotation and destruction by hand.
Both customer-owned options support CMEK organization policies, key usage logging, and logical data separation through encryption. Google lists pricing for these as varying, and the default as free. Check the live pricing page for your region before you plan a rollout.
What does a CMEK integration actually do?
A service with a CMEK integration encrypts your resource with a key you control in Cloud KMS, in place of the default Google-managed key. After setup, the service agent handles encryption and decryption, so users and applications see the same experience as before.
The practical effect is a cryptographic boundary. If you disable or destroy the key version, the service can no longer decrypt the data it protects. That is a strong control, and also a way to hurt yourself, so treat key destruction as a change that needs review, not a routine clean-up.
What is envelope encryption, and when do you do it yourself?
For data your own application encrypts, Google describes envelope encryption: a data encryption key (DEK) encrypts the data, and a key encryption key (KEK) wraps the DEK. Cloud KMS holds the KEK centrally. Its best practices for DEKs are concrete:
- Generate DEKs locally.
- Always keep stored DEKs encrypted at rest.
- Store the DEK near the data it protects.
- Generate a new DEK every time you write the data, so you do not need to rotate DEKs.
- Do not use one DEK for two different users.
- Use a strong algorithm such as 256-bit AES in Galois Counter Mode.
For KEKs, store them centrally, size their scope to the workload, and rotate them regularly and after a suspected incident. One KEK can wrap many DEKs, which keeps the number of keys in KMS manageable. The Encrypt and Decrypt calls in Cloud KMS accept at most 64 KiB, which is why you wrap a DEK rather than sending bulk data to KMS.
Constructed example: a billing service stores invoices in a bucket. The team enables a CMEK on the bucket for the storage layer. Inside the app, it also encrypts the tax ID field with a fresh DEK per record and wraps each DEK with one KEK for the billing workload. A leaked database dump exposes ciphertext and wrapped DEKs. Without KMS access the attacker has nothing readable.
What to do
- List which datasets have a contractual or regulatory need for customer-owned keys. Leave the rest on default encryption.
- For those datasets, check that the Google Cloud service you use has a CMEK integration before you design around it.
- Choose Autokey if you want fewer manual steps, or manual keys if you need to set every control.
- Apply a CMEK organization policy so new resources cannot be created without a key.
- Turn on logging for key administration and key use, and decide who reviews those logs.
- Set a rotation period for KEKs and write down the procedure for rotation after an incident.
- Require a second approver for disabling or destroying key versions.
- Keep application-level DEKs per record or per write, never shared across users.
Keys are one piece. Your code still decides who may call decrypt, so dependency and code scanning of the services that hold KMS permissions still matter. Safeguard's dependency scanning and policy gates can help you check the services that hold those permissions, but it does not replace key management.
Quick check
Is my data unencrypted if I never configure a key?
No. Google states that customer content at rest is encrypted by default with AES-256. What you give up without Cloud KMS is ownership, rotation control and key usage logs.
Do I need CMEK to meet every regulation?
Not necessarily. CMEK matters when a rule or contract asks you to control the key. Read the actual requirement and map it, rather than enabling CMEK everywhere by default.
Why wrap a DEK instead of encrypting data in KMS?
Cloud KMS limits Encrypt and Decrypt input to 64 KiB and is designed to manage KEKs. Bulk data is encrypted locally with a DEK, and KMS protects the DEK.
Sources
- Default encryption at rest, Google Cloud, fetched 18 October 2026
- Customer-managed encryption keys (CMEK), Cloud KMS, fetched 18 October 2026
- Envelope encryption, Cloud KMS, fetched 18 October 2026
Last reviewed: 18 October 2026.
