Google Cloud Security – Data Encryption

Google Cloud data encryption is the set of options GCP provides to protect data at rest across Cloud Storage, BigQuery, Compute Engine, and over 100 other services. It matters because the default Google-managed encryption gives you no independent key control, no per-operation audit trail, and no ability to revoke GCP’s access to your data. The recommended action for regulated workloads is to use Customer-Managed Encryption Keys (CMEK) via Cloud KMS, enable Data Access audit logs, and configure automatic key rotation on a compliance-aligned schedule.

Quick Answer: Which Google Cloud Encryption Option Should You Use?

For regulated workloads (HIPAA, PCI DSS, FedRAMP, GDPR): use CMEK (Customer-Managed Encryption Keys) via Cloud KMS. CMEK gives you a key policy you control, per-operation Cloud Audit Logs, the ability to disable or destroy the key independently of Google, automatic key rotation, and optional FIPS 140-2 Level 3 hardware protection via Cloud HSM. For non-regulated workloads where simplicity is the priority: GMEK (Google-managed encryption) is sufficient and costs nothing extra. For workloads requiring the key to never enter GCP’s infrastructure: use client-side encryption (HYOK) or Cloud External Key Manager (Cloud EKM). CSEK (Customer-Supplied Encryption Keys) is a legacy option that works per-API-call but is operationally complex; CMEK is the better choice for most use cases where you want customer key control.

Key Takeaways

• Google Cloud encrypts all data at rest by default: Every object uploaded to Cloud Storage is encrypted using AES-256 before being written to disk, at no additional charge. Default encryption uses Google-managed keys (GMEK).
• Envelope encryption is the underlying mechanism for all GCP encryption options: Data is split into chunks, each encrypted with a unique Data Encryption Key (DEK). The DEK is then encrypted by a Key Encryption Key (KEK), which is either managed by Google, supplied by the customer, or managed in Cloud KMS. Plaintext DEKs are never stored.
• CMEK is the compliance-grade option: Customer-Managed Encryption Keys in Cloud KMS provide per-operation Cloud Audit Logs, independent key disable and destroy capability, automatic rotation, and BYOK via Import Jobs. GMEK provides none of these.
• CSEK puts key management burden entirely on the caller: You must supply your AES-256 key with every API request. Google never stores it permanently. Losing your CSEK means losing access to all data encrypted with it, with no recovery option from Google.
• Client-side encryption (HYOK) is the only option that excludes Google entirely: When you encrypt data before uploading, Google stores only ciphertext and cannot decrypt your data under any operational circumstance, including a legal demand directed at Google.

How Google Cloud Envelope Encryption Works

All Google Cloud data encryption options are built on the same underlying mechanism: envelope encryption. Understanding envelope encryption is essential to understanding why the four GCP encryption options differ in their security and compliance properties.

When data is uploaded to Cloud Storage, GCP splits it into chunks (up to several GB each). For each chunk, Google’s internal cryptographic library (CrunchyCrypt) generates a unique, one-time Data Encryption Key (DEK). The DEK encrypts the chunk using AES-256-GCM (Authenticated Encryption with Associated Data). The DEK is then encrypted by a Key Encryption Key (KEK), producing an encrypted DEK. The encrypted DEK is stored alongside the encrypted chunk in Google’s distributed storage systems. The plaintext DEK is discarded from memory immediately after encryption; it is never persisted anywhere.

To decrypt: the KEK decrypts the encrypted DEK to recover the plaintext DEK. The plaintext DEK decrypts the data chunk. The plaintext DEK is again discarded from memory immediately. The key question across all four GCP encryption options is: who controls the KEK? That control determines your audit capabilities, your revocation capability, and your sovereignty over the data.

The Four Google Cloud Data Encryption Options

Option 1: Google-Managed Encryption Keys (GMEK)

GMEK is the default. When you upload data to Cloud Storage without specifying any other encryption option, Google generates, manages, and rotates the KEK automatically. The encryption happens at the storage layer before data is written to disk. There is no charge for GMEK, no configuration required, and no application changes needed.

What GMEK does not give you: an independent audit trail for individual decrypt operations, the ability to disable Google’s access to the KEK, customer control over the key lifecycle, or proof that key material was generated in FIPS-validated hardware. GMEK protects against physical storage media theft and Google’s internal access controls govern who can use the KEK. GMEK is appropriate for non-regulated, internal data where Google’s own security posture is within your trust boundary.

Option 2: Customer-Supplied Encryption Keys (CSEK)

With CSEK, you generate your own AES-256 symmetric key and supply it as a header in every Cloud Storage API request. Google uses your key as the KEK to encrypt the DEK for that operation. After the operation completes, Google hashes your key (the hash is used to validate future requests using the same key) and purges the plaintext key from its systems. Google never permanently stores your CSEK.

The CSEK encryption workflow for a write operation is:

1. Your CSEK is provided to Cloud Storage in the API request header alongside the data upload.
2. Cloud Storage splits the data into sub-file chunks.
3. CrunchyCrypt generates a unique one-time DEK for each chunk.
4. Each chunk is encrypted using its DEK (AES-256-GCM).
5. Cloud Storage uses your CSEK as the KEK and encrypts each DEK with it.
6. The encrypted DEK is stored alongside its encrypted chunk in Cloud Storage.
7. The plaintext DEK is deleted from memory.
8. Your CSEK is hashed and the plaintext CSEK is purged from Google’s systems. The hash validates future requests but cannot decrypt data or reconstruct the key.

The CSEK decryption workflow for a read operation is:

1. The client or application requests data from Cloud Storage and supplies the CSEK in the request header.
2. Cloud Storage identifies the chunks and retrieves them.
3. For each chunk, Cloud Storage retrieves the encrypted DEK and decrypts it using the supplied CSEK.
4. The plaintext DEK decrypts the data chunk.
5. The plaintext DEK is discarded and the decrypted data is returned to the client.

CSEK applies to: the object data, the object’s checksum, and the object’s hash. Cloud Storage uses standard server-side keys to encrypt the remaining object metadata, including the object’s name.

CSEK operational risks: You are entirely responsible for generating, storing, and supplying your CSEK for every read and write request. If you lose your CSEK, Google cannot recover it and all data encrypted with it is permanently inaccessible. CSEK is not stored in Cloud KMS and does not generate Cloud KMS audit log entries. You must build your own key management and backup infrastructure for CSEKs.

Option 3: Customer-Managed Encryption Keys (CMEK) via Cloud KMS

CMEK is the compliance-grade encryption option for GCP. You create and manage an encryption key in Cloud KMS (Key Management Service), and you configure the GCP service (a Cloud Storage bucket, a BigQuery dataset, a Compute Engine disk, a Cloud Pub/Sub topic) to use that Cloud KMS key as the KEK. When data is written to the service, it calls Cloud KMS to encrypt the DEK. When data is read, it calls Cloud KMS to decrypt the DEK.

The CMEK encryption workflow for a write operation is:

1. Data is uploaded to the GCP service (Cloud Storage bucket, BigQuery table, etc.).
2. The service splits the data into sub-file chunks.
3. CrunchyCrypt generates a unique one-time DEK for each chunk.
4. Each chunk is encrypted using its DEK.
5. The service sends each DEK to Cloud KMS, specifying the CMEK key resource to use as the KEK.
6. Cloud KMS encrypts the DEK using the specified CMEK key and returns the encrypted DEK.
7. The encrypted DEK is stored alongside its encrypted chunk.
8. The plaintext DEK is deleted from memory.

The CMEK decryption workflow for a read operation is:

1. A read request arrives for the encrypted data.
2. The service retrieves the encrypted chunks and their encrypted DEKs.
3. The service sends each encrypted DEK to Cloud KMS for decryption, specifying the CMEK key.
4. Cloud KMS decrypts each DEK using the CMEK key and returns the plaintext DEK.
5. The service uses each plaintext DEK to decrypt its corresponding chunk.
6. The plaintext DEK is discarded and the decrypted data is returned to the client.

What CMEK gives you that GMEK and CSEK do not: Every Cloud KMS Encrypt and Decrypt call generates a Cloud Audit Log entry (when Data Access logging is enabled) recording the requesting service, the key version used, the timestamp, and the originating identity. You can disable the CMEK key in Cloud KMS to immediately prevent any further encryption or decryption operations on all data protected by that key, across all GCP services using it. You can configure automatic key rotation on a schedule (minimum 24 hours; annually is the common compliance baseline). You can use Cloud HSM-backed keys for FIPS 140-2 Level 3 hardware protection of the KEK. You can import your own key material (BYOK) via Cloud KMS Import Jobs. All of these capabilities are absent from GMEK and CSEK.

CMEK pricing: Cloud KMS keys cost $0.06 per active key version per month for software-protected keys and $2.50 per active key version per month for HSM-protected keys. Cryptographic operations (Encrypt, Decrypt calls from GCP services) cost $0.03 per 10,000 operations. High-volume workloads with frequent object reads and writes can accumulate significant KMS API call costs; see the cost optimization section below.

Option 4: Client-Side Encryption (HYOK)

Client-side encryption, also called HYOK (Hold Your Own Key), means your application or data pipeline encrypts data before it is sent to any GCP service. What arrives at Cloud Storage or any other GCP service is already ciphertext. Google stores only encrypted data and never has access to the plaintext or the encryption key under any circumstance, including a legal demand directed at Google.

When cloud storage receives client-side encrypted data, the server-side encryption layer is still applied on top of it (Google’s GMEK layer). When retrieving, Cloud Storage removes its server-side layer, but the client-side layer remains in place. Your application must decrypt the client-side layer using the key it manages externally.

Client-side encryption is appropriate for classified data, data subject to data sovereignty requirements where GCP’s infrastructure is outside your trust boundary, or workloads where your threat model includes Google as a potential access point. The operational cost: every read and write requires a call to your external key management system, which must be highly available. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 key management infrastructure needed for client-side encryption implementations on GCP.

GCP also supports Cloud External Key Manager (Cloud EKM) as a HYOK option for CMEK-integrated services. With Cloud EKM, the CMEK key is held in your external key management system. When GCP needs to encrypt or decrypt a DEK, it calls your external KMS over a TLS-authenticated connection rather than using a key stored in Cloud KMS. This allows HYOK sovereignty while still using the CMEK integration points of GCP services such as BigQuery and Cloud Spanner.

Comparing the Four GCP Encryption Options

Dimension	GMEK (Google-Managed)	CSEK (Customer-Supplied)	CMEK (Customer-Managed via Cloud KMS)	Client-Side / HYOK
Who controls the KEK	Google	Customer (per request)	Customer (via Cloud KMS)	Customer (outside GCP)
Key stored in GCP	Yes (Google-managed)	No (hash only, no plaintext)	Yes (in Cloud KMS)	No
Google access to KEK during use	Yes	Yes (during operation only)	Yes (in HSM boundary)	No
Per-operation Cloud Audit Logs	No	No	Yes (when Data Access logging enabled)	Only from external KMS
Independent key disable/revoke	No	No (delete your own copy)	Yes (disable in Cloud KMS)	Yes (revoke at external KMS)
Automatic key rotation	Yes (Google schedule)	No (fully manual)	Yes (configurable schedule)	Customer-managed
BYOK support	No	Yes (you supply the key)	Yes (via Cloud KMS Import Jobs)	Yes (your own key throughout)
FIPS 140-2 Level 3 hardware	No	No	Yes (with Cloud HSM protection level)	Depends on external KMS
Additional cost	None	None (key management is yours)	$0.06 to $2.50/key version/month + $0.03/10k ops	External KMS cost
Best for	Non-regulated, internal data	Legacy per-object key control	Regulated workloads: HIPAA, PCI DSS, FedRAMP, GDPR	Classified, sovereignty-mandated, zero-trust

BYOK in Google Cloud: Cloud KMS Import Jobs

BYOK (Bring Your Own Key) in Google Cloud means generating AES-256 key material outside GCP and importing it into Cloud KMS as a customer-managed key. Once imported, the key functions identically to a Cloud KMS-generated CMEK: GCP services can use it as the KEK, it generates Cloud Audit Log entries, it supports automatic rotation scheduling, and it can be disabled or destroyed independently.

The Cloud KMS Import Job process works as follows. Create a Cloud KMS Import Job for the target key ring and specify the wrapping algorithm (RSA_OAEP_3072_SHA256 or AES_256_KWP). Download the wrapping key from the import job. Generate your 256-bit AES key material in your own HSM or key management system. Wrap your key material using the downloaded wrapping key. Upload the wrapped key material to the import job via the Cloud KMS API. Cloud KMS unwraps your key material inside the HSM cluster (if the target protection level is HSM) and stores it as a Cloud KMS key version.

Important constraints for BYOK keys in Cloud KMS: automatic rotation is not available for keys with imported material (Cloud KMS cannot generate new versions of externally originated key material). You must manage rotation manually by generating new key material externally, creating a new import job, importing the new material as a new key version, and designating it as the primary version. You can set an expiration date on imported key material, after which Cloud KMS automatically deletes it and the key becomes unusable for new operations.

IAM Model for Google Cloud Encryption Access Control

Access control for GCP encryption operations operates through Google Cloud IAM applied at both the GCP service level (who can read or write objects in Cloud Storage) and the Cloud KMS key level (who can use the CMEK key to encrypt or decrypt). These are separate permission boundaries that must both be configured correctly.

Cloud Storage IAM (service level): Controls who can read, write, list, and delete objects in a Cloud Storage bucket. The standard roles are Storage Admin (full control), Storage Object Admin (object CRUD), Storage Object Creator (write only), and Storage Object Viewer (read only). Apply least privilege: analytics service accounts need Storage Object Viewer, not Storage Object Admin. Ingestion pipelines need Storage Object Creator, not Storage Admin.

Cloud KMS IAM (key level): Controls who can manage and use the CMEK key. Three distinct roles: Cloud KMS Admin (roles/cloudkms.admin) can create, delete, and manage key policies but cannot use keys for cryptographic operations. Cloud KMS Crypto Key Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) can encrypt and decrypt using the key but cannot manage it. Cloud KMS Viewer (roles/cloudkms.viewer) can view key metadata. The service account used by Cloud Storage to call KMS must have the Encrypter/Decrypter role on the specific CMEK key; this is separate from any human or application identity that reads data.

Key principle: the service account that reads data from Cloud Storage should not also have Cloud KMS admin rights. An analyst service account with Storage Object Viewer rights can read objects from a CMEK-encrypted bucket, but it does not need (and should not have) Cloud KMS Crypto Key management permissions. The Cloud KMS Encrypter/Decrypter call is made automatically by the Cloud Storage service on behalf of the read operation using a Google-managed service agent, not by the user’s identity.

Organization Policy constraints: Use constraints/gcp.restrictCloudKmsKeyLocations to enforce that CMEK keys can only be created in approved GCP regions (for data residency requirements). Use constraints/gcp.restrictNonCmekServices to require that specific GCP services always use CMEK and cannot fall back to GMEK. These organization-level constraints provide a policy guardrail that applies across all projects within the scope, supplementing per-project IAM configurations.

Key Rotation for GCP CMEK Keys

Automatic key rotation for CMEK keys in Cloud KMS generates a new key version on the configured schedule without requiring any changes to the GCP services using the key. The new version becomes the primary version for all new encryption operations. Previous versions remain in the Enabled state and continue to decrypt data encrypted with those versions. The key resource name (key ring path, key name) stays the same; the rotation is transparent to applications and data pipelines.

Rotation periods are configurable with a minimum of 24 hours. For most compliance frameworks the recommended rotation period is 90 days (aligned with PCI DSS Requirement 3.7.4 guidance on symmetric key cryptoperiods for high-value keys) or annually for standard regulated workloads. Each rotation generates a key version creation event in Cloud Audit Logs.

Key version destruction in Cloud KMS has a mandatory minimum scheduled deletion period of 24 hours (configurable up to 120 days). During this window, destruction can be cancelled. Once the scheduled time passes, the key version and its material are permanently destroyed. Scheduling destruction of a CMEK key version immediately generates a Cloud Audit Log Admin Activity event, giving security teams the window to detect and cancel accidental or unauthorized destruction before it is irreversible.

Cloud Audit Logs for GCP Data Encryption

Google Cloud Audit Logs capture the security-relevant events for both Cloud Storage and Cloud KMS. Enabling and correctly routing these logs is a compliance requirement under PCI DSS Requirement 10, HIPAA’s Audit Control standard (45 CFR 164.312(b)), and FedRAMP AU controls.

Cloud Storage audit logs: Data Access logs for Cloud Storage capture object read (storage.objects.get) and write (storage.objects.create, storage.objects.update, storage.objects.delete) operations. These logs must be enabled explicitly at the project or organization level; they are not on by default. Once enabled, every object-level operation records the requesting identity, the bucket and object name, the timestamp, and the source IP.

Cloud KMS audit logs: Admin Activity logs (always on, cannot be disabled) capture key creation, key version creation and destruction scheduling, key policy updates, and Import Job events. Data Access logs for Cloud KMS (must be enabled explicitly) capture every Encrypt and Decrypt call made by GCP services using your CMEK key, including the requesting service account, the key version ARN, and the timestamp. These per-operation KMS logs are the audit trail that demonstrates who accessed what data at what time, which is the evidence required by HIPAA, PCI DSS, and FedRAMP auditors.

Route Cloud Audit Logs to Cloud Logging (default) and additionally export them to a Cloud Storage bucket in a separate, write-protected project for long-term retention. PCI DSS requires 12 months of log retention with 3 months immediately available. Configure log-based alerts in Cloud Monitoring for: any CMEK key version destruction scheduling on a production key; any IAM binding change on a CMEK key ring or key; any Decrypt operation from a service account not in the approved role list for that key; and any Cloud Storage Data Access operation from an unexpected principal or geographic location.

Cost Optimization for GCP Data Encryption

GMEK has no additional cost. CSEK has no Cloud KMS cost (the key management burden falls on you). CMEK has two cost components: key version storage and cryptographic operation calls.

Software-protected CMEK key versions cost $0.06 per active version per month. HSM-protected key versions cost $2.50 per active version per month. Cryptographic operations (Encrypt and Decrypt calls from GCP services to Cloud KMS) cost $0.03 per 10,000 operations for symmetric keys. At high request volumes, the per-operation cost accumulates quickly. A Cloud Storage bucket receiving 10 million object writes and reads per month generates 20 million Cloud KMS API calls, approximately $60 per month in KMS API fees for that bucket alone.

Cloud KMS does not have an equivalent to AWS KMS’s S3 Bucket Key feature. For high-volume GCP workloads where per-object KMS calls are expensive, consider DEK caching at the application layer: retrieve the plaintext DEK from Cloud KMS once per session or time window and use it locally for multiple encrypt and decrypt operations. The trade-off is that the plaintext DEK is held in application memory for the cache duration. For workloads using BigQuery, Cloud Storage with Autoclass, or Cloud Spanner, the per-operation KMS call volume depends on the access pattern and can be modeled before deployment to estimate monthly costs.

GCP Encryption in Multi-Cloud and Hybrid Architectures

Cloud KMS is a GCP-native service. CMEK keys created in Cloud KMS cannot be natively used to protect data stored in AWS S3 or Azure Blob Storage. Organizations operating multi-cloud architectures need an explicit strategy for consistent key governance across providers. Three patterns are common:

• Per-cloud native KMS with centralized governance: Use Cloud KMS CMEK for GCP workloads, AWS KMS for AWS workloads, and Azure Key Vault for Azure workloads. Deploy a centralized key lifecycle management platform that aggregates key inventory, rotation status, and audit logs from all three providers. Each cloud’s data is protected by that cloud’s native KMS; the governance layer provides cross-cloud visibility and compliance evidence collection without introducing cross-cloud latency for cryptographic operations.
• Centralized BYOK from an external HSM: Generate all key material from a single external HSM or third-party HSM as a Service that is independent of all cloud providers. Import derived keys into Cloud KMS as BYOK keys for GCP workloads, into AWS KMS for AWS workloads, and into Azure Key Vault for Azure workloads. All encryption traces back to a single authoritative key source. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 HSM infrastructure for this model, accessible from GCP, AWS, and Azure simultaneously.
• Client-side encryption with a shared key (HYOK across all clouds): Encrypt data at the application or pipeline layer before it reaches any cloud provider. The same client-side encryption library and master key are used regardless of the destination cloud. GCP, AWS, and Azure each store only ciphertext. This provides the strongest cross-cloud sovereignty but requires applications to handle all cryptographic operations and your external key management system to be highly available for all cloud workloads. See our guide on Cloud Data Lake Security for how this pattern applies to multi-cloud data lake architectures.

Compliance: PCI DSS, HIPAA, FedRAMP, and GDPR

PCI DSS v4.0.1 (mandatory since March 31, 2025): CMEK with Cloud KMS satisfies Requirement 3.5.1 (protection of stored cardholder data using strong cryptography) for GCP services storing PANs. When Cloud HSM protection level is used for the CMEK key, Requirement 3.7.1 (key generation using an HSM or industry-accepted technology) is also satisfied. Cloud Audit Logs Data Access events for Cloud KMS satisfy Requirement 10 (logging and monitoring of access to cardholder data). GMEK alone does not satisfy PCI DSS because it provides no per-operation audit trail and no customer key control.

HIPAA: CMEK with Cloud KMS satisfies the HIPAA Technical Safeguard for Encryption and Decryption (45 CFR 164.312(a)(2)(iv)) for ePHI at rest in GCP services. Google’s Business Associate Agreement (BAA) covers Cloud KMS and Cloud Storage, making them eligible for ePHI workloads. Cloud Audit Logs Data Access events for Cloud KMS and Cloud Storage satisfy the HIPAA Audit Control standard (45 CFR 164.312(b)).

FedRAMP: Google Cloud services including Cloud KMS and Cloud Storage are authorized under FedRAMP High. Cloud KMS with Cloud HSM protection level (FIPS 140-2 Level 3) satisfies FedRAMP High’s requirement for validated cryptographic modules under NIST SP 800-53 Rev. 5 SC-12 (Cryptographic Key Establishment and Management) and SC-28 (Protection of Information at Rest). GMEK (without HSM-backed CMEK) does not satisfy FedRAMP High’s FIPS 140-2 Level 3 requirement. See our dedicated guide on Google Cloud HSM for the full FIPS 140-2 Level 3 architecture.

GDPR: CMEK supports GDPR data subject rights compliance by enabling key-based data access revocation. Disabling a CMEK key makes all data encrypted with it inaccessible to any party, including Google, which can serve as a technical implementation of the right to erasure for data that cannot otherwise be selectively deleted (for example, in immutable log stores). GDPR’s requirement for appropriate technical and organizational measures (Article 32) is satisfied by CMEK with access controls, audit logging, and rotation. CSEK can also satisfy GDPR’s technical measures requirement but lacks the audit trail and governance properties of CMEK.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations select, design, and implement the right Google Cloud encryption architecture for their compliance requirements, from initial option selection through audit evidence generation.

• GCP Encryption Architecture Design: We map your GCP workloads to the right encryption option (GMEK, CMEK, CSEK, or client-side), design the CMEK key hierarchy per service and data classification zone, configure IAM with separation of key administrator from key user, enforce CMEK via Organization Policy constraints, and design Cloud Audit Log routing for compliance evidence. See our cloud data protection services.
• HSM as a Service for BYOK and HYOK: For BYOK implementations requiring FIPS 140-2 Level 3 key generation outside GCP, or for client-side encryption architectures requiring an external key management system, Encryption Consulting’s HSM as a Service provides dedicated HSM infrastructure accessible from GCP workloads. BYOK keys generated in the HSM as a Service can be imported into Cloud KMS via Import Jobs; HYOK keys remain in the HSM as a Service and are called by your application or by Cloud EKM for each operation.
• CBOM Secure for GCP Encryption Discovery: GCP environments with many projects often accumulate inconsistent encryption configurations: some Cloud Storage buckets using GMEK, others using CMEK, some without Data Access logging enabled. Encryption Consulting’s CBOM Secure discovers and inventories all Cloud KMS key configurations, Cloud Storage encryption settings, and IAM policy bindings across GCP projects, generating a Cryptographic Bill of Materials (CBOM) in CycloneDX format identifying buckets not using CMEK, keys without rotation schedules, and over-permissive IAM bindings on key rings.
• PCI DSS and HIPAA Compliance Advisory: We map your GCP encryption configuration to the specific requirements of PCI DSS v4.0.1, HIPAA Technical Safeguards, FedRAMP, and GDPR. We identify control gaps, produce the compliance evidence package, and assist with QSA and auditor inquiries. See our Compliance Advisory Services.
• PQC Readiness for GCP Workloads: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 points toward deprecating RSA and ECC for new uses around 2030. Google Cloud’s post-quantum roadmap for Cloud KMS asymmetric key types is evolving. Encryption Consulting’s PQC Readiness service maps your GCP encryption key estate against the post-quantum migration timeline and designs the transition sequence for asymmetric keys used for signing and key exchange in GCP workloads.

To discuss your GCP encryption architecture or compliance requirements, contact Encryption Consulting.

Conclusion

Google Cloud encrypts all data at rest by default, but default GMEK encryption is not the same as compliant encryption. The compliance-grade option is CMEK via Cloud KMS, which adds the audit trail, independent key control, rotation schedule, and FIPS 140-2 Level 3 hardware option that regulated workloads require. CSEK is a per-request option that keeps the key entirely out of GCP but places the full key management burden on the caller. Client-side encryption and Cloud EKM are the options for workloads where Google must have zero access to the encryption key.

The most common GCP encryption misconfiguration is using GMEK for data that regulatory requirements specify must be under customer key control, without realizing that GMEK provides no per-operation audit trail and no independent key revocation capability. Getting the encryption option selection right at the point of service configuration is significantly easier than retrofitting CMEK onto a deployed environment where hundreds of buckets, datasets, and disks are already using GMEK.

Frequently Asked Questions

What are the data encryption options in Google Cloud?

Google Cloud offers four options: Google-managed encryption keys (GMEK, the default at no extra charge), customer-supplied encryption keys (CSEK, where you supply your AES-256 key per API request and Google never stores it permanently), customer-managed encryption keys (CMEK via Cloud KMS, where you manage the key in Cloud KMS and configure GCP services to use it), and client-side encryption (HYOK, where you encrypt data before uploading so Google stores only ciphertext). CMEK is the right choice for regulated workloads requiring an audit trail and independent key control.

What is envelope encryption in Google Cloud?

Envelope encryption is the key hierarchy GCP uses for all encryption options. Data is split into chunks; each chunk is encrypted with a unique Data Encryption Key (DEK) generated by Google’s CrunchyCrypt library. The DEK is then encrypted by a Key Encryption Key (KEK), which is either Google-managed (GMEK), customer-supplied (CSEK), or customer-managed in Cloud KMS (CMEK). The encrypted DEK is stored alongside the encrypted chunk. The plaintext DEK is discarded from memory immediately after use and never persisted.

What is the difference between CSEK and CMEK in Google Cloud?

CSEK requires you to supply your AES-256 key in every API request; Google uses it only for that operation, hashes it, and purges it. CMEK means you create and manage a key in Cloud KMS and configure GCP services to use it as the KEK. CMEK gives you automatic rotation, per-operation Cloud Audit Logs (when Data Access logging is enabled), the ability to disable the key instantly, and Cloud HSM integration for FIPS 140-2 Level 3 hardware protection. CSEK provides none of these capabilities and places the entire key management burden on your infrastructure.

How do I implement BYOK in Google Cloud?

BYOK in Google Cloud uses Cloud KMS Import Jobs. Create an Import Job for your target key ring and download the wrapping key. Generate your AES-256 key material in your own HSM. Wrap your key material with the downloaded wrapping key. Upload the wrapped material to Cloud KMS via the Import Job. The imported key becomes a CMEK key that GCP services use. You retain the original key material in your HSM and can delete the imported copy from Cloud KMS to immediately revoke GCP’s ability to use it.

Does Google Cloud encryption meet HIPAA and PCI DSS requirements?

CMEK via Cloud KMS meets both requirements when configured correctly. For HIPAA, CMEK satisfies the encryption at rest requirement (45 CFR 164.312(a)(2)(iv)) and Cloud Audit Logs satisfy the Audit Control standard (164.312(b)). Google’s BAA must be in place. For PCI DSS v4.0.1, CMEK with Cloud HSM protection satisfies Requirement 3.5.1 (strong cryptography for stored PANs) and Requirement 3.7.1 (HSM key generation). Cloud Audit Logs satisfy Requirement 10. GMEK alone satisfies neither framework’s compliance requirements.

How does key rotation work in Google Cloud KMS for encrypted data?

Automatic rotation on a Cloud KMS CMEK key generates a new key version on the configured schedule (minimum 24 hours; annually is the common compliance baseline). The new version becomes primary for new encryption operations. Previous versions remain enabled for decrypting older data. You do not need to re-encrypt existing Cloud Storage objects or BigQuery data to complete the rotation. For BYOK keys with imported material, automatic rotation is not available; you must manually generate new key material, import it as a new key version, and designate it as the primary version.