Google Cloud Encryption Key Management Choices

Key Access Justifications (KAJ) (opens in a new tab) together with external key custody provides outside-Google control and per-request governance for encryption keys. Cloud External Key Manager (EKM) keeps the root of trust in an external key manager outside Google Cloud, while KAJ requires Google systems to attach a justification code to every cryptographic operation that uses an enrolled Cloud Key Management Service (Cloud KMS) (opens in a new tab) key. Choose this combination when data sovereignty, jurisdictional isolation, or regulatory mandates require auditable customer control over decryption, even for operations initiated by Google.

1.1External Root of Trust with Cloud EKM

Cloud EKM is a Cloud KMS key type where key material lives and is managed in an external key manager outside Google Cloud rather than in Google software or hardware backends. The Cloud KMS API supports software-protected, hardware-protected, and external keys, and Cloud KMS-integrated services use the same API to request encryption and decryption. Because the data-holding service stores only encrypted data and the key lives outside that service, no decryption can succeed without a request flowing from the Google service to the external key manager. Choose Cloud EKM when stringent sovereignty or regulatory requirements demand that the customer or a designated external partner retain custody and the ability to deny access.

1.2How Encryption at Rest Uses External Keys

Encryption at rest with external keys separates stored ciphertext in Google Cloud from key material held outside the service where the data is stored. For example, data in Cloud Storage is stored encrypted, while the key is stored in Cloud KMS when using customer-managed encryption keys (CMEK) or in the external key manager when using Cloud EKM. When an application needs cleartext, traffic flows from the service to the key manager as a decryption request, and the decrypted result returns to the service; for example, data flows from BigQuery to Cloud KMS or to the external key manager, then back to BigQuery to service the query. Most key accesses come from automated systems servicing customer workloads, but Google personnel can also initiate operations that use keys for the following reasons:

• Back up data for disaster recovery.
• Resolve a customer support request that requires decrypting data to meet support obligations.
• Manage and troubleshoot systems, including technical debugging, remediation of storage failure, or data corruption.
• Ensure data integrity and compliance and protect against fraud and abuse, including safety, security, and Terms of Service reviews.

Because Cloud EKM moves the approval point outside Google, each of these request types must present its justification to the external manager before key material is used.

1.3Key Access Justifications Policy and Transparency

Key Access Justifications (KAJ) is the control that directs Google systems to generate a justification code for each cryptographic operation involving an enrolled Cloud KMS key. A key policy can view, approve, or deny key access requests depending on the provided code, and audit logs record the code for later review. For select external key management partners, the KAJ policy is configured outside Google Cloud and is exclusively enforced by the external key manager rather than by Cloud KMS, so denial happens at the external trust boundary. The available capability depends on the chosen Assured Workloads control package:

KAJ works alongside Access Approval, which lets customers authorize requests from Google personnel to access Customer Data, and Access Transparency, which provides discovery information about when Customer Data was accessed. Together, Access Approval governs human access, Access Transparency records it, and KAJ provides key-level access control for all interactions with at-rest data protected by a customer-managed key.

1.4Justification Codes for Auditing and Governance

Justification codes (opens in a new tab) are the granular access reasons that KAJ attaches to decryption requests initiated by Google services. Each code names the initiator and purpose, so a policy can allow routine customer-servicing operations while denying or flagging sensitive Google-initiated access. Common codes include:

• CUSTOMER_INITIATED_SUPPORT — customer-initiated support, for example a case number.
• GOOGLE_INITIATED_SERVICE — Google-initiated system management and troubleshooting, including technical debugging, remediation of failure or corruption, and proactive Technical Account Management support tagged as TAM Support.
• GOOGLE_RESPONSE_TO_PRODUCTION_ALERT — Google-initiated access to maintain reliability, including investigating a suspected outage and ensuring backup and recovery.
• GOOGLE_INITIATED_REVIEW — Google-initiated access for security, fraud, abuse, or compliance, including account safety, malware impact checks, Terms of Service compliance, abuse investigations, and regulatory checks such as anti-money laundering.
• THIRD_PARTY_DATA_REQUEST — Google-initiated access in response to a legal request or legal process, including a request that requires Google to access the customer's own data.
• REASON_NOT_EXPECTED — no reason is expected because at least one service in the request path has never integrated with KAJ or is still in Preview integration and cannot produce a justification.
• REASON_UNSPECIFIED — KAJ is enabled but no justification is available due to transient error, bug, or other circumstance; this code may appear as an empty string in some Google Cloud and EKM logging displays.

A governance rule should treat REASON_NOT_EXPECTED and REASON_UNSPECIFIED as distinct from explicit customer or Google-initiated reasons, because they signal incomplete integration or missing context rather than a verified purpose.

Google default encryption is automatic protection applied to customer data without customer key configuration or action. Data is protected with encryption in transit using Transport Layer Security before transmission, and with encryption at rest once stored in Google Cloud. Keys for this baseline are Google-owned and Google-managed encryption keys, which remain under Google control and operation.

2.1Default Protection for Data in Transit

Default protection for data in transit is encryption applied to requests before they travel over the network. Google Cloud encrypts requests before transmission and protects the raw data using Transport Layer Security (TLS). This protection applies by default, so data moving to Google Cloud for storage is protected during read and write operations without customer configuration. The trust boundary places the network path outside the trusted zone, and TLS provides the control that protects data as it crosses that boundary.

2.2Default Protection for Data at Rest

Default protection for data at rest is encryption automatically applied once data is transferred to Google Cloud for storage. Google Cloud applies encryption at rest by default to stored data, so no customer key selection is required for the baseline. The service that stores the data depends on Google-owned and Google-managed keys to encrypt and decrypt that data transparently. Because encryption is automatic, workloads receive baseline confidentiality without managing key creation, storage, or rotation.

2.3Key Ownership and Control Boundary

Google-owned and Google-managed encryption keys are keys that Google creates, stores, protects, and operates on behalf of the customer. The ownership boundary places both the data and the encryption keys on the Google side, with Google responsible for key operations and protection. These keys are FIPS-140-2 compliant, which allows them to support most control packages in Assured Workloads (opens in a new tab). Customers can delete the customer-managed encryption keys (CMEK) (opens in a new tab) project and rely solely on Google-owned and Google-managed keys when additional customer control is not required.

Customer control begins where default encryption ends. Cloud Key Management Service (Cloud KMS) provides customer-managed encryption keys (CMEK) for projects that need more control than default encryption provides:

• generate encryption keys according to customer policy
• use keys for encryption and decryption of data at rest
• rotate keys on a customer-defined schedule
• destroy keys to make associated data inaccessible

2.4Where Default Encryption Satisfies Baseline Requirements

Default encryption satisfies baseline requirements for workloads that need FIPS-140-2 compliant encryption at rest without customer key administration. General-purpose storage, processing, and application data in Google Cloud are protected by default, which reduces operational complexity because there is no key ring, key version, or rotation schedule to manage. Assured Workloads environments can also operate on default keys for most control packages, allowing teams to simplify deployment by removing the separate CMEK project. Choose default encryption when organizational or regulatory requirements accept Google key ownership and do not mandate customer-controlled rotation, destruction, or external key custody.

2.5Limitations in Visibility, Lifecycle, and Sovereignty

Limitations of default encryption center on visibility, lifecycle control, and sovereignty because the customer does not own the keys. Default encryption does not give customers direct control over key access visibility, lifecycle management decisions such as rotation and destruction timing, or key custody location outside Google. Customers who require administrative control over those decisions must use CMEK in Cloud KMS, where key policies, permissions, and destruction are customer-managed.

The choice between models can be summarized by ownership and operational responsibility:

This boundary creates a direct tradeoff: default encryption lowers operational complexity but retains Google custody, while CMEK increases control and sovereignty responsibility but adds key management work. The dependency is strict in one direction: stored data depends on continued availability of the keys that protect it.

Customer-managed encryption keys (CMEK) are encryption keys that a customer creates and controls in Cloud Key Management Service (Cloud KMS) to protect data at rest in Google Cloud services. Google Cloud encrypts traffic in transit with Transport Layer Security (TLS) and encrypts stored data at rest by default with Google-owned and Google-managed keys that are FIPS-140-2 compliant. CMEK replaces that default key control with customer control over generation, use, rotation, and destruction, at the cost of greater operational responsibility for availability and recovery.

3.1Google Default Encryption Compared with CMEK Control

Google default encryption and CMEK differ in who controls the key lifecycle and where access decisions are enforced. With default encryption, Google owns and manages the keys and no customer key configuration is required, which supports most control packages. With CMEK, the customer owns a CryptoKey in Cloud KMS, and the storage or compute service depends on that key for every encrypt and decrypt operation. For Assured Workloads (opens in a new tab), this separation can be physical: Assured Workloads can deploy a CMEK project alongside the resources project, so key administration lives outside the project that holds the data. Decide whether to use CMEK before creating the Assured Workloads folder, because deleting an in-use CMEK key can make data impossible to access or recover.

3.2Key Hierarchy, Protection Levels, and Service Dependencies

Cloud Key Management Service (Cloud KMS) organizes keys as a key ring that contains CryptoKeys, and each CryptoKey contains one or more key versions that perform the cryptographic operations. The key version template defines purpose, such as ENCRYPT_DECRYPT, algorithm, such as GOOGLE_SYMMETRIC_ENCRYPTION, and protection level, such as SOFTWARE or HSM. Cloud Hardware Security Module (Cloud HSM) keys keep key material in hardware, while Cloud External Key Manager (Cloud EKM) keys are pointers to key material that resides with a supported external key management partner outside Google Cloud. Availability of Cloud HSM and Cloud EKM keys varies by location, and cryptographic operations with those keys consume Cloud KMS quotas, for example on each change to repository contents in a CMEK-protected Dataform repository.

Data flows from the protected service to Cloud KMS for authorization on each data operation. After a repository is created, Dataform (opens in a new tab) calls Cloud KMS during each operation on encrypted repository data to verify that the key is still valid. If Cloud KMS reports the key as disabled or destroyed, the corresponding repository data becomes inaccessible. If a formerly disabled key is later re-enabled, Dataform restores access automatically without reconfiguration of the repository.

3.3Key Lifecycle Management and Automated Rotation

The Cloud KMS key-version lifecycle is an ordered set of states that controls whether data can be encrypted, decrypted, or recovered. A version moves through states in order, and restoration is possible only during a defined window:

1. ENABLED: The key version performs encrypt and decrypt operations and can serve as the primary version for new encryptions.
2. DISABLED: The key version temporarily cannot perform cryptographic operations, which makes dependent data inaccessible until the version is re-enabled.
3. Scheduled for destruction: A destruction request starts a configurable waiting period, defined by destroy_scheduled_duration, during which the version can still be restored.
4. DESTROYED: After the waiting period passes, logical deletion of the key material from active systems starts, the version cannot be used or recovered by the customer, and the version is no longer billed.
5. Deleted: After destruction, the version record can be permanently removed from Cloud KMS lists, but the CryptoKey name cannot be reused.

Automatic rotation creates new key versions on a schedule independently of destruction. Destroying all active key versions does not change the rotation schedule, so new versions continue to be created unless automatic rotation is explicitly disabled on the key.

3.4Cryptographic Shredding Through Destruction and Deletion

Cryptographic shredding (opens in a new tab) in Cloud KMS is the practice of destroying the key version that protects data so the ciphertext can never be decrypted again. Destruction and deletion are different operations with different effects on billing, listing, and recoverability.

Key material can remain in Google systems for up to 45 days after the scheduled destruction time while logical deletion completes. For Cloud EKM, destroying the key version permanently removes the association between the Cloud KMS key version and the external key, and a destroyed Cloud EKM version cannot be recreated even with the same external key URI or key path. Destroying a manually managed external version does not modify the key in the external manager, so destroy first in Google Cloud and then destroy externally; destroying a coordinated external version destroys first in Google Cloud and then sends a destruction request to the external manager.

3.5Enforcing CMEK with Defaults, IAM, and Separation of Duties

CMEK enforcement combines a separate key administration boundary with IAM permissions and service-level default keys. The predefined Cloud KMS administrator role, roles/cloudkms.admin, grants permission to delete and view Cloud KMS resources, including cloudkms.cryptoKeyVersions.delete, cloudkms.cryptoKeys.delete, cloudkms.keyRings.delete, cloudkms.retiredResources.get, and cloudkms.retiredResources.list. Keeping these permissions in a dedicated key project, separate from data projects and service agents that only receive encrypt and decrypt rights, creates separation of duties between key administrators and data users.

Service defaults enforce CMEK once they are set. A default Dataform CMEK key applies to a specific Google Cloud project location, with only one default key per location:

• After the default is set, all new repositories in that project location must use CMEK and cannot use default encryption at rest.
• A new repository can use the default key or a different CMEK key selected at creation.
• Changing the default affects only repositories created after the change; pre-existing repositories keep the previous value.

3.6Availability, Propagation, and Disaster Recovery Planning

CMEK availability planning must account for propagation delay, service dependency on Cloud KMS, and loss of external key control. Changes to key state, such as disabling or destroying a key, can take up to three hours to propagate from Cloud KMS to dependent services, while permission changes usually propagate much faster. During that window, Dataform cannot detect or act on the change until Cloud KMS propagates it. In the rare case that Cloud KMS itself is unavailable, Dataform may be unable to retrieve key status, and encrypted repository data becomes inaccessible even if the key is enabled at that time.

Disaster recovery for CMEK therefore depends on protecting the key with the same rigor as the data. Retain the ability to restore during the Scheduled for destruction period, monitor for scheduled-destruction events with Cloud Monitoring, and plan for the 45-day backend retention window after destruction. Treat external keys as the highest risk: Google does not control availability in the partner system, and if an external key is deleted or cannot be recovered, any data encrypted with that key becomes permanently inaccessible.

Key Facts

• Google default encryption uses Google-owned and Google-managed keys with no customer configuration, while customer-managed encryption keys (CMEK) in Cloud Key Management Service (Cloud KMS) give the customer control over generate, use, rotate, and destroy.
• Cloud External Key Manager (EKM) keeps key material in an external key manager outside Google Cloud, so decryption requires a request to flow from the Google service to the external manager.
• Key Access Justifications (KAJ) attaches a justification code to each operation on an enrolled key, and for select external partners the external key manager exclusively enforces the approve-or-deny policy.
• A Cloud KMS key version moves in order through ENABLED, DISABLED, Scheduled for destruction, DESTROYED, and Deleted, with restoration possible only before destruction completes.
• Destroying all active key versions does not stop automatic rotation, and changes to key disabled or destroyed state can take up to three hours to propagate to dependent services.