Managing CMEK and EKM Encryption Keys

Execute key revocation and destruction is the process of making customer-controlled encrypted data temporarily inaccessible or permanently irretrievable by disabling, destroying, and deleting keys in Cloud Key Management Service (Cloud KMS) (opens in a new tab). Cloud External Key Manager (Cloud EKM) (opens in a new tab) keys are pointers to key material that resides outside Google Cloud with a supported external partner, while customer-managed encryption keys (CMEK) reside in Cloud KMS. Revocation through disablement stops cryptographic operations quickly but remains reversible, while destruction through crypto-shredding permanently removes the ability to decrypt data protected by that key version.

1.1Immediate Revocation by Disabling Keys in Cloud KMS

Immediate revocation by disabling a key is the act of turning off a key version in Cloud KMS so services can no longer use it to encrypt or decrypt data. Google Cloud services that use CMEK call Cloud KMS to validate the key during each operation on encrypted data, so when Cloud KMS reports the key as disabled or destroyed, all data protected by that key becomes inaccessible. Disablement can take up to three hours to propagate through Cloud KMS, while permission changes usually propagate much faster, so access loss is not always instantaneous across every service.

A disabled key still exists in Cloud KMS and the underlying key material is preserved, so a formerly disabled key that is re-enabled restores access automatically once services detect the valid state again. This reversibility makes disablement the correct first response when compromise is suspected, access must be suspended for investigation, or retention policy requires a temporary hold before permanent action. By contrast, deleting an in-use CMEK project or deleting an external key that cannot be recovered makes the data permanently inaccessible, so revocation decisions must account for whether recovery will ever be needed.

1.2Scheduled Destruction Lifecycle and Crypto-Shredding

Scheduled destruction is the irreversible lifecycle that permanently removes a key version's ability to perform cryptographic operations and starts logical deletion of its key material from active systems. Destruction is used for crypto-shredding, where destroying the key version that encrypted the data makes that data permanently unrecoverable even though the ciphertext may still exist. A destroyed key version enters the DESTROYED state, cannot be used for cryptographic operations, and is no longer billed, but it remains visible in lists of Cloud KMS resources until it is separately deleted.

The destruction lifecycle moves through ordered states with a built-in recovery window:

1. Request destruction: The request moves the key version from ENABLED or DISABLED to SCHEDULED FOR DESTRUCTION for its configured destruction duration.
2. Restoration window: The key version remains restorable only while it is SCHEDULED FOR DESTRUCTION; a restoration request returns it to usable state before the timer expires.
3. Destroyed state: After the configured duration passes, the key version moves to DESTROYED, logical deletion of key material from active systems begins, and the customer cannot recover the material.
4. Residual retention: Key material can remain in Google systems for up to 45 days from the scheduled destruction time while deletion completes across storage layers.

Destroying all active key versions does not change the key's rotation schedule, so new key versions continue to be created on schedule unless automatic rotation is also disabled. Cloud KMS can send an alert through Cloud Monitoring when a key version enters SCHEDULED FOR DESTRUCTION, which provides oversight for compliance and prevents accidental loss. If an organization requires key versions to be disabled before destruction, the version must be disabled first and then submitted for destruction.

1.3Destroying Cloud EKM External Keys Across Trust Boundaries

Destroying a Cloud EKM key version permanently removes the association in Cloud KMS between the Cloud EKM key version and the external key URI or key path. After the SCHEDULED FOR DESTRUCTION period passes and the version becomes DESTROYED, data encrypted with that Cloud EKM key version can no longer be encrypted or decrypted through Cloud KMS. A destroyed Cloud EKM key version cannot be recreated, even when the same external key URI or key path is reused, and Google does not control the availability of keys held in the external partner system.

The effect on the external system depends on how the external key is managed:

For partner-managed sovereign controls, destruction follows an approval workflow that spans both trust boundaries, with key material in Google Cloud on one side and key material in the partner system on the other. The operator first schedules the Cloud KMS key version for destruction, then submits a destroy request through Issue Tracker with the resource name of the key version. The partner confirms the request and provides a destruction date and time, restoration before that time preserves both the Cloud KMS key and the partner key, and if destruction proceeds the Cloud KMS key is removed first and then the partner key is removed.

1.4Permanent Deletion and Retention Compliance in Cloud KMS

Permanent deletion (opens in a new tab) in Cloud KMS is different from destruction, and the distinction controls compliance with data retention policies and regulatory mandates. Destruction permanently disables a key version and irreversibly destroys its key material after the destruction period, which enforces crypto-shredding for data that must be unrecoverable. Deletion only removes a key, key version, or key ring from listings in the console, command line, API, and client libraries to streamline search and list operations, and deleted CryptoKey names cannot be reused.

A key version can be deleted only when it no longer holds usable key material:

• The version is in the DESTROYED, IMPORT_FAILED, or GENERATION_FAILED state
• An imported version can be deleted only if the import failed
• A key can be deleted only when all of its versions are already deleted, automatic rotation is not scheduled, and the key was not created by Autokey

Deleted key names remain blocked from reuse, and the list of retired names can be viewed through the retired resources list operation. This order of operations — disable for immediate revocation, destroy after the scheduled period for irretrievability, then delete for inventory cleanup — ensures that retention requirements are met by destruction, not merely by hiding the resource from listings.

Cloud External Key Manager (Cloud EKM) (opens in a new tab) is the Google Cloud service for using keys that remain outside Google Cloud to protect data inside Google Cloud. Secure import for Cloud EKM does not move key bytes into Google Cloud. The external key material stays in the supported external key manager (EKM), Cloud Key Management Service (Cloud KMS) (opens in a new tab) holds only a key reference plus its own internal key material, and every encrypt or decrypt operation calls across that trust boundary to the EKM.

2.1Key Structure and Wrapping Flow for Cloud EKM

A Cloud EKM key version has three linked parts that enforce separation between Google and the external owner. External key material is cryptographic material created and stored in the EKM and never shared with Google, a key reference is the key URI or key path that Cloud EKM uses to request operations on that material, and internal key material is additional key material created in Cloud KMS for symmetric keys that never leaves Cloud KMS. For symmetric encryption, data flows first from Cloud KMS to its internal key material for an initial encryption, then from Cloud KMS to the EKM for a second wrapping layer with the external key material, then back to Cloud KMS as ciphertext that requires both materials to decrypt.

This double wrap is different from Cloud KMS with key import, where customer-generated bring-your-own-key (BYOK) material is imported for use inside Cloud KMS. Cloud EKM implements hold-your-own-key (HYOK) where the external key never enters Google. Because both the Cloud EKM key version and the external key are required for every request, loss of access on either side means the data cannot be decrypted.

2.2Manually Managed External Keys in Cloud EKM

A manually managed external key is a Cloud EKM key where the administrator performs matching changes in both the EKM and Cloud KMS. The key appears in Cloud KMS alongside other keys with protection level EXTERNAL or EXTERNAL_VPC, but automatic rotation is not supported and the external material is never exposed to Google. Creation follows an ordered workflow:

1. Create external key: Create or select a key in the supported EKM system, which provides a unique URI or key path.
2. Grant Google access: Grant the Google Cloud project access to use that key inside the EKM system.
3. Create Cloud EKM version: Create the Cloud EKM key version in Cloud KMS using that URI or key path.
4. Maintain both sides: Perform rotation or destruction in both systems, because a change in only one side leaves the paired version unusable.

When created with the API or Google Cloud CLI, a Cloud EKM key must not have an initial key version. This rule does not apply to keys created in the Google Cloud console.

2.3Coordinated External Keys Managed from Cloud KMS

A coordinated external key is a Cloud EKM key whose lifecycle can be driven from Cloud KMS through an EKM connection that uses Cloud KMS EKM management mode. The connection depends on a VPC network, the hostname of the EKM, and a crypto space path that identifies the customer's container of resources inside the EKM partner. Coordinated keys appear with protection level EXTERNAL_VPC, and the external material still resides only in the EKM.

1. Set up EKM connection: Set up the EKM connection over VPC with management mode set to Cloud KMS, authorizing the EKM to access the VPC network and authorizing the Google Cloud project service account to access the crypto space.
2. Create key from Cloud KMS: Create the external key in Cloud KMS, which causes Cloud EKM to send a creation request to the EKM, the EKM to create the material and return a key path, and Cloud EKM to create the key version with that path.
3. Manage from Cloud KMS: Initiate rotation, creation, or destruction of versions from the console, gcloud CLI, Cloud KMS API, or client libraries, and Cloud EKM forwards the request to the EKM.

Destruction moves through ordered states. The version first enters scheduled for destruction in Cloud KMS, then Cloud EKM destroys its part of the cryptographic material and sends a destruction request to the EKM after the period ends. Data encrypted with that version cannot be decrypted after destruction in Cloud KMS, even if the EKM has not yet destroyed its copy.

2.4Authorization, Revocation, and Audit Controls for Cloud EKM

Authorization for Cloud EKM keys is split between the EKM and Cloud KMS, so access can be cut off on either side. The Google Cloud project cannot use an externally managed key until access is granted in the EKM, and that access can be revoked at any time to make the data undecryptable. This split creates separation of duties and multiple enforcement points:

• EKM access grant: The key owner grants and revokes the Google Cloud project permission to call the external key in the EKM system.
• Cloud KMS IAM and separation of duties: Cloud KMS provides predefined IAM roles for key administrators versus data administrators, so key management can be centralized in a separate project from the data.
• Key Access Justifications: Each request to the EKM can carry a justification reason code, and the EKM completes the request only for codes allowed by the external policy.
• Audit logging: Cloud KMS data audit logs record Cloud EKM errors and key use, and the external key manager should also enable audit logging for access to EKM keys.
• CMEK organization policies (opens in a new tab): Organization policies control which projects can supply keys for customer-managed encryption keys (CMEK) and which protection levels are allowed.

2.5Connectivity and Location Tradeoffs for Cloud EKM

Connectivity for Cloud EKM determines availability, latency, and where keys can be placed. Cloud EKM must reach the EKM quickly, so the Cloud KMS location should be geographically near the EKM partner location, and multi-region failover can change network distance and timeout behavior because a new data center initiates the key requests. The choice between internet and VPC connectivity controls supported locations and management modes:

If an external key is unavailable, Cloud KMS returns a FAILED_PRECONDITION error with PreconditionFailure detail. Unavailability can stop workloads that depend on decryption, such as Google Kubernetes Engine application-layer secrets becoming unavailable on nodes, and a Spanner database encrypted with an unavailable CMEK key is automatically deleted after more than 30 consecutive days without access. Rotating to a new version does not recover data when the current version is unavailable.

Implementing and automating key rotation policies means configuring Cloud Key Management Service (Cloud KMS) (opens in a new tab) to create a new primary version of each customer-managed encryption key (CMEK) (opens in a new tab) on a defined schedule. Rotation limits exposure if a version is compromised because new data encryption keys are wrapped with the new version, while older versions remain available to decrypt existing data. Automated schedules enforce consistency for compliance and remove reliance on manual rotation.

3.1Automated Rotation Schedules for CMEK Keys

Automated rotation schedules for customer-managed encryption keys (CMEKs) define how often Cloud KMS generates a new primary key version for encryption of new data. The recommended practice is to enable automatic rotation on every CMEK key, with a period that meets compliance needs and is ideally no less than once per year. Sensitive workloads should use more frequent rotation to further limit the amount of data protected by any single version.

Compliance frameworks typically state high-level principles for encryption and key management but do not prescribe a specific product or rotation interval. The key owner is responsible for mapping framework requirements to a Cloud KMS rotation period and proving the control is enforced. Keys created by Cloud KMS Autokey follow industry-standard rotation schedules automatically, while manually created keys require the administrator to set and maintain the rotation period.

3.2Key Configuration That Enables Automatic Rotation

Key configuration that enables automatic rotation starts with the required CMEK key type and the source of key material. All CMEK keys must use the symmetric ENCRYPT_DECRYPT purpose with the GOOGLE_SYMMETRIC_ENCRYPTION algorithm, which supports envelope encryption where the CMEK acts as a key encryption key (KEK) that encrypts data encryption keys (DEKs). Only keys with Google-generated key material can automatically create new versions on the configured rotation schedule without external action.

Keys that use imported key material, often called bring-your-own-key (BYOK), cannot rotate automatically inside Cloud KMS and require automation outside Cloud KMS to generate and import each new version on time. If import automation fails, no new version appears and data continues to be protected by the aging version:

• Ability to consistently generate and import new versions, including Cloud KMS settings that restrict the key to import-only versions
• Secure storage or escrow of the original key material held outside Google Cloud
• Controls to prevent leakage of raw key material during the import process
• Risk that retained outside material could be used to re-import a previously destroyed key
• Whether the benefit of external control justifies the added operational overhead and risk

Choose Google-generated key material when possible to keep automatic rotation simple, and choose imported material only when external custody is required and the supporting automation is in place.

3.3Impact of Rotation on Dependent Resources

The impact of rotation on dependent resources depends on how each CMEK-integrated service uses key versions, because rotation changes only which version is primary for new encryptions. Existing data remains wrapped by the version that protected it at write time, so disabling or destroying old versions makes that data inaccessible even after successful rotation. Administrators must therefore evaluate per-service behavior before shortening rotation periods or cleaning up old versions.

3.4Managing Transition Between Key Versions to Maintain Accessibility

Managing the transition between key versions means keeping the full version history usable while new writes move to the primary version. Cloud KMS uses envelope encryption in which traffic flows from the service agent to Cloud KMS for KEK operations, and the service agent then uses the unwrapped DEK to protect resource data. If the KEK version needed for a resource is disabled or scheduled for destruction, requests to use that key fail and the dependent data cannot be decrypted until the version is restored to enabled.

The key usage dashboard and Cloud KMS Inventory API show which Google Cloud resources, projects, and products depend on each key and whether data is inaccessible due to a disabled or destroyed version. Centralized Admin Activity audit logs record creation, rotation configuration, disable, and destroy scheduling, while Cloud Monitoring can alert on sensitive operations such as scheduling destruction. An operational plan should pair frequent review of key usage with alerts and pre-destroy checks, so rotation improves security without causing loss of access during the transition.

Key Facts

• Disabling a Cloud KMS key version makes data temporarily inaccessible and is reversible, while destroying a key version makes data permanently irretrievable through crypto-shredding after the scheduled destruction period.
• A destroyed Cloud External Key Manager (Cloud EKM) key version cannot be recreated from the same external key URI or key path, and loss of access on either the Cloud KMS side or the external key manager side causes permanent data loss.
• Cloud KMS automatic rotation requires symmetric ENCRYPT_DECRYPT keys with Google-generated key material, and rotation changes only the primary version for new encryptions while prior versions remain required to decrypt existing data.
• Deletion in Cloud KMS only removes resources from listings and cannot substitute for destruction, and deleted CryptoKey names cannot be reused.