GCP Cloud KMS and CMEK: Key Management Guide

Google Cloud KMS is the managed service that creates, stores, and controls encryption keys in Google Cloud, and CMEK (customer-managed encryption keys) is the model that lets you point a Google Cloud service at a key you own instead of a key Google manages for you. Getting KMS right is one of the highest-leverage things a cloud security engineer can do, because a key you control is also a key you can disable, rotate, or destroy when something goes wrong.

This guide walks through how Cloud KMS is structured, what the protection levels actually mean, how CMEK differs from default encryption, and how to design a key strategy that survives an audit.

Default encryption, CMEK, and CSEK

Every byte of customer data at rest in Google Cloud is encrypted by default. You do not enable it, you cannot turn it off, and it costs nothing. So the first question is not "should I encrypt" but "who should hold the key."

There are three models, and mixing them up is a common interview mistake:

Model	Who generates the key	Who can disable it	Typical use case
Google-managed (default)	Google	Google only	Non-regulated workloads, internal tooling
CMEK (Cloud KMS)	You, in Cloud KMS	You	Regulated data, compliance requirements, tenant isolation
CSEK (customer-supplied)	You, outside Google Cloud	You	Narrow legacy cases, limited service support
Cloud EKM (external)	You, in an external KMS	You, outside Google	Strict key residency or hold-your-own-key mandates

CMEK is the model most organizations land on. It gives you an auditable key lifecycle without forcing you to run key infrastructure yourself. Cloud EKM goes further: the key material lives in your external key management system, and Google Cloud stores only a reference to it, so Google cannot access the raw key.

If the difference between encryption at rest and in transit is still fuzzy, start with our cloud encryption fundamentals guide and come back here.

How Cloud KMS is organized

Cloud KMS uses a simple hierarchy, and every design decision flows from it:

1. Project: the billing and IAM boundary. Many teams use a dedicated key project separate from the projects holding the data.
2. Key ring: a container tied to a specific location. Key rings cannot be moved or deleted, so name them carefully.
3. Key (CryptoKey): the logical key your services reference. This is where rotation schedules and purpose are set.
4. Key version: the actual cryptographic material. Rotation creates a new primary version while older versions stay available for decryption.

Location matters more than beginners expect. A key can only protect resources in a compatible location, so a key ring in us-east1 cannot encrypt a bucket that lives in europe-west1. Plan locations alongside your data residency requirements, not after.

Key purposes

A key has a fixed purpose set at creation time and it cannot be changed later:

• Symmetric encrypt/decrypt: the default, used for nearly all CMEK integrations
• Asymmetric sign and asymmetric decrypt: for signing workflows and public key cryptography
• MAC: for message authentication codes

Pick the wrong purpose and you create a new key, so slow down for thirty seconds at creation time.

Protection levels: software, HSM, and external

Cloud KMS offers several protection levels, and the choice drives both cost and compliance posture.

SOFTWARE keys are handled in software using Google's BoringCrypto module, which uses FIPS 140-3 Level 1 validated cryptographic primitives. This is the least expensive option and is appropriate when you have no regulatory requirement for a higher validation level.

HSM keys are generated and used inside hardware security modules. Cryptographic operations never leave the HSM boundary. This is the right default for regulated data, and there is also a single-tenant HSM option for organizations that need a dedicated instance rather than a multi-tenant one.

EXTERNAL and EXTERNAL_VPC keys use Cloud EKM, where the key material lives in a supported third-party key manager. Google Cloud stores only additional cryptographic material and a path to your key. This satisfies the strictest hold-your-own-key requirements, but it also means an outage or misconfiguration in your external system can make Google Cloud data inaccessible. That is the tradeoff, and you should model it deliberately.

For a full treatment of the tradeoffs, Google publishes a detailed Cloud KMS overview that is worth reading end to end.

IAM: separation of duties is the whole point

CMEK only adds security if the people who can use a key are not the same people who can delete it. Cloud KMS supports this cleanly with predefined roles.

Role	What it allows	Who should hold it
roles/cloudkms.admin	Create, update, and destroy keys and key rings	Central security or platform team
roles/cloudkms.cryptoKeyEncrypterDecrypter	Use a key to encrypt and decrypt data	Service agents and applications
roles/cloudkms.viewer	Read key metadata	Auditors, compliance reviewers
roles/cloudkms.publicKeyViewer	Retrieve public keys for asymmetric keys	Verification and signing workflows

Three rules make this work in practice:

1. Key administrators should not hold encrypt and decrypt permissions. Administration and usage are different jobs.
2. Grant the encrypter/decrypter role to the specific service agent that needs it, at the key level, not at the project level.
3. Never grant roles/owner on the key project as a convenience. It collapses every boundary you just built.

If IAM modeling in Google Cloud is new to you, our Google Cloud security guide covers the identity layer that sits underneath all of this.

Rotation, disabling, and destruction

Rotation is the part teams most often configure once and then forget.

Automatic rotation applies to symmetric keys. You set a rotation period, and Cloud KMS creates a new key version and promotes it to primary on schedule. Data encrypted under older versions is still decryptable, because the older versions remain enabled. Rotation limits the volume of data protected by any single version, which is the actual security benefit.

Manual rotation is required for imported keys and for asymmetric keys. If you import key material, build the rotation cadence into a runbook rather than relying on memory.

Disabling a key version stops it from being used for encrypt or decrypt operations but keeps it recoverable. This is your emergency brake during an incident: disable the key, and the data it protects becomes inaccessible until you re-enable it.

Destruction is scheduled, not immediate. Cloud KMS puts a version into a pending destruction state for a configurable waiting period before the material is destroyed. Use that window. Once material is destroyed, data encrypted under it is unrecoverable, and no support ticket will bring it back.

A practical policy that holds up well in audits:

• Annual rotation for HSM-backed symmetric keys, or more frequently if a framework requires it
• A documented disable-first procedure before any destruction
• A destruction waiting period long enough for your slowest approval chain
• Alerting on key disable, destroy, and IAM policy change events

Cloud KMS Autokey

Autokey automates CMEK provisioning. Instead of creating key rings and keys ahead of time and wiring up IAM grants by hand, Autokey generates keys on demand as part of resource creation and grants the required roles to the service agents automatically.

Keys created by Autokey have consistent characteristics: HSM protection level, AES-256 GCM, and a one-year rotation period, created in the same location as the resource they protect. Autokey also enforces separation of duties by design, since developers can request key creation and assignment but cannot view or manage the keys themselves.

Google recommends Autokey when the keys it produces meet your requirements, because it removes the most common source of CMEK mistakes: inconsistent manual setup. You choose between dedicated-project key storage, where a designated key project holds keys for resources in other projects in a folder, and same-project key storage. For most enterprises, a centralized key project per environment folder is the cleaner model. Google's CMEK best practices documentation is the authoritative reference here.

A practical CMEK rollout order

If you are introducing CMEK to an existing environment, sequence matters:

1. Inventory which services hold regulated data and confirm each one supports CMEK
2. Create the key project and folder structure, with IAM separated between admins and users
3. Decide protection level per data class, defaulting to HSM for regulated workloads
4. Enable Autokey, or create key rings per location and keys per data class
5. Grant the encrypter/decrypter role to service agents at the key level
6. Enable Cloud Audit Logs for Cloud KMS and route them to your SIEM
7. Test the incident path: disable a key in a non-production project and confirm your alerting fires

Step seven is the one teams skip and later regret. A key you have never disabled is a key you do not actually know how to use in an incident.

Where KMS fits across the three clouds

Cloud security engineers are rarely single-cloud for long. The concepts transfer, and the vocabulary shifts:

Concept	Google Cloud	AWS	Azure
Managed key service	Cloud KMS	AWS KMS	Key Vault / Managed HSM
Customer-managed key	CMEK	Customer managed key (CMK)	Customer-managed key
Hardware backing	Cloud HSM	KMS HSM-backed, CloudHSM	Managed HSM
External key	Cloud EKM	External key store (XKS)	Managed HSM BYOK

If you already know one, the other two come quickly. Our guides on AWS KMS best practices and Azure Key Vault security cover the same ground on the other platforms.

Frequently asked questions

Is CMEK required for compliance?

No single framework names CMEK by name, but many require demonstrable control over encryption keys, key rotation, and key access logging. CMEK is the practical way to satisfy those control objectives in Google Cloud, which is why auditors often expect to see it for regulated data.

Does CMEK make data more secure than default encryption?

The cryptography is equally strong either way. CMEK changes who holds control, not the algorithm. The security benefit comes from your ability to rotate, disable, destroy, and audit the key independently of Google.

What happens if I disable a CMEK key?

Services that need the key to read data lose access until it is re-enabled. This is intentional and is the reason CMEK is useful during an incident, but it also means an accidental disable can cause an outage. Alert on disable events and restrict who can perform them.

How often should I rotate encryption keys?

Annual rotation is a common baseline for symmetric keys, and it matches what Cloud KMS Autokey provisions by default. Rotate more frequently if a framework or internal policy requires it. Rotation limits how much data any single key version protects.

Can I recover data after destroying a key version?

No. Once the key material is destroyed, data encrypted under that version cannot be decrypted. This is why Cloud KMS schedules destruction with a waiting period instead of destroying immediately. Always disable first and confirm nothing breaks before you schedule destruction.

Do I need to learn all three cloud KMS services to get hired?

Depth in one plus working familiarity with the others is the realistic target. Most job postings name a primary cloud, and the key management concepts are portable enough that a strong foundation in one transfers quickly.

Build key management skills you can demonstrate

Reading about key hierarchies is not the same as building one. PrimeSec Academy's 20-week Cloud and AI Platform Security Engineer program includes hands-on labs across AWS, Azure, and Google Cloud, with 36 projects and a defended capstone so you finish with evidence, not just notes.

See the full curriculum or enroll now to start building.