Google Cloud Platform’s Data Encryption Tools – KMS, HSMs, and PKIs

Google Cloud Platform protects data through three linked layers: Cloud KMS for key management, Cloud HSM/Cloud EKM for key custody, and Certificate Authority Service for PKI. It matters because picking the wrong layer (software key where a compliance mandate needs hardware custody, for example) creates an audit gap later. Recommended action: default to Cloud KMS with software-backed keys, escalate to Cloud HSM or Cloud EKM only where a specific requirement demands it.

Published: November 2020. Updated: August 2026. Reviewed by Encryption Consulting’s Cloud Key Management Team.

This post is the overview of how GCP’s encryption tools fit together. For the internal mechanics of Cloud KMS specifically (key hierarchy, keyrings, protection levels), see our deep dive Google Cloud Security – Key Management Services. For how GCP’s KMS compares to AWS and Azure, see AWS KMS Vs Azure Key Vault Vs GCP KMS.

How Does Data Encryption Work on Google Cloud?

Cloud data exists in two states that each need distinct protection: data-in-transit and data-at-rest. Data-in-transit encryption uses TLS to wrap data as it moves between systems, so an intercepted packet is unreadable even if captured. Data-at-rest encryption protects data sitting on disk or in object storage, turning plaintext into ciphertext that is meaningless without the key. GCP encrypts both by default: AES-256 for data-at-rest in Google Cloud Storage, and TLS for data-in-transit, with no configuration required to enable either baseline.

That default encryption uses envelope encryption: a data encryption key (DEK) encrypts the data itself, and a key encryption key (KEK) encrypts the DEK for an extra layer of protection. Both are managed through Google’s Cloud Key Management Service (Cloud KMS) API, which integrates with the rest of Google Cloud (Cloud Storage, Cloud Functions, BigQuery, Compute Engine) so services can request encryption operations without handling raw key material directly.

How Does Native vs. External Key Control Work on GCP?

Cloud KMS gives four distinct ways to source a key, each with a different custody model:

Key-control model	How it works	Best fit
Cloud KMS software-backed (native)	Symmetric or asymmetric keys generated and used entirely within Google’s software cryptographic module.	The default for most workloads; lowest cost, no hardware dependency.
Cloud HSM (native, hardware-backed)	Keys generated and used only inside FIPS 140-2 Level 3 validated Hardware Security Modules that Google operates.	Workloads with a hardware-custody compliance requirement (PCI DSS HSM mandates, some government contracts).
BYOK (imported key material)	An organization generates key material outside GCP and imports it into Cloud KMS, which then manages its lifecycle going forward.	Organizations that need to prove key provenance or that already generate keys through an existing on-prem HSM.
Cloud EKM (external/HYOK-equivalent)	Cloud KMS references a key that physically resides with an external key manager (Thales, Fortanix, and others); Google never holds usable key material.	Regulated data where a contract or regulator requires that Google itself never possess the key.

Default to Cloud KMS software-backed keys unless a specific requirement says otherwise. Cloud HSM and Cloud EKM both add cost and latency, and are worth it only when a named compliance obligation or contractual clause actually requires that level of custody.

How Does IAM Govern Access to KMS, HSM, and PKI Resources?

Identity and Access Management (IAM) is the permissions layer sitting on top of every key operation on GCP. Any service or user attempting to use a DEK or KEK first needs an IAM role granting that specific permission; IAM roles can be scoped at the keyring level (covering every key in the group) or the individual key level for finer control. This directly supports the best practice of separating key administrators from data administrators: a person managing encryption keys does not need, and should not have, direct access to the data those keys protect.

1. Grant cloudkms.admin only to the identities responsible for key lifecycle management, never to application service accounts.
2. Grant cloudkms.cryptoKeyEncrypterDecrypter narrowly, scoped to the specific service account that needs to encrypt/decrypt with that key.
3. Keep Cloud KMS resources in a project separate from the data they protect, so a compromise of the data project does not automatically grant key access.
4. Review IAM bindings on keyrings on the same cadence as production access reviews, since a stale KMS grant is equivalent to standing decrypt access.

How Should You Handle Key Rotation on GCP?

Cloud KMS supports automatic rotation on a defined schedule, but rotation only creates a new active key version; it does not re-encrypt existing data or delete the previous version. Data encrypted under an older key version stays dependent on that version until an explicit re-encryption pass runs. Google does not publish a fixed technical minimum or maximum for the rotation period itself, but a 90-day cadence for symmetric keys is a common baseline aligned with broader industry recommendations (including NIST’s general cryptoperiod guidance).

Certificate rotation on the PKI side is a separate concern from key rotation: TLS certificates issued through Certificate Authority Service follow their own validity period, decoupled from the Cloud KMS keys that may back the issuing CA’s private key. Track these two rotation cycles independently rather than assuming one schedule covers both.

What Should You Log Across KMS, HSM, and PKI?

• Cloud Audit Logs for every KMS operation: who called encrypt/decrypt/sign, on which key, and from which project, automatically captured without extra configuration.
• Key lifecycle events: creation, rotation, scheduled destruction, and IAM binding changes on keyrings and keys.
• Certificate issuance and revocation events from Certificate Authority Service, tied to the CA that issued each certificate.
• Cloud EKM round-trip calls, if in use, since a failure to reach the external key manager is itself a security-relevant availability event, not just an application error.

What Do GCP’s Encryption Tools Cost?

Cloud KMS software-backed keys are billed per active key version per month plus per-operation charges; Cloud HSM keys carry a materially higher per-key-version rate to cover dedicated hardware capacity; Cloud EKM adds the cost of the external key manager itself on top of Cloud KMS’s own charges. Certificate Authority Service bills separately, based on the CA tier (DevOps vs. Enterprise) and certificates issued, independent of KMS pricing. Confirm current per-unit rates against Google’s own pricing pages before budgeting a migration, since Cloud KMS, Cloud HSM, and Certificate Authority Service are billed on three separate schedules.

What Does Multi-Cloud Encryption Architecture Look Like Across GCP, AWS, and Azure?

Each major cloud implements the same conceptual layers (managed KMS, hardware-backed HSM tier, external key manager option, and a PKI/certificate service) with different names and different FIPS postures. GCP’s Cloud HSM tier is currently FIPS 140-2 Level 3, while AWS KMS and Azure Managed HSM have both moved their HSM tiers to FIPS 140-3 Level 3 – a gap worth flagging in any GCP-inclusive compliance review that specifically requires FIPS 140-3 hardware validation. A consistent multi-cloud architecture standardizes the access-control and rotation policy across all three native KMS products rather than trying to run one KMS across clouds, since none of the three natively manages another’s keys.

See our comparison of AWS KMS, Azure Key Vault, and GCP KMS for the full breakdown of how these three differ on rotation, IAM, and cost.

What Are the Limitations of GCP’s Native Encryption Tools?

• Cloud HSM’s current FIPS 140-2 Level 3 validation is a step behind AWS’s and Azure’s FIPS 140-3 Level 3 hardware tiers, which matters for a compliance mandate that specifically names 140-3.
• Rotation does not re-encrypt data automatically; re-encryption and old-version cleanup are the customer’s responsibility.
• Cloud EKM adds latency and an external dependency to every cryptographic operation, which is a real availability trade-off, not just a security upside.
• KMS, HSM, and Certificate Authority Service are billed and administered separately, so a unified view of “encryption spend” requires pulling data from multiple GCP billing line items.

Decision Checklist: Choosing GCP’s Encryption Tools

1. Default to Cloud KMS software-backed keys; escalate to Cloud HSM only for a named hardware-custody requirement.
2. Reserve Cloud EKM for cases where a regulator or contract requires that Google never hold usable key material.
3. Scope IAM roles at the keyring or key level, separating key administrators from data administrators.
4. Define a rotation-plus-re-encryption runbook, not just a rotation schedule.
5. Budget Cloud KMS, Cloud HSM, and Certificate Authority Service costs separately before a large migration.

What Would Encryption Consulting Recommend?

Most GCP customers we work with default to software-backed Cloud KMS keys without ever revisiting whether a compliance requirement actually calls for HSM or external custody, then discover the gap during an audit. Encryption Consulting’s Cloud Key Management services map your actual compliance obligations to the right GCP key-control tier, design the IAM and separation-of-duties model, and our HSM-as-a-Service offering gives you hardware-backed custody without operating HSMs directly.

Frequently Asked Questions

What is the difference between Cloud KMS and Cloud HSM?

Cloud KMS is the API and management layer for cryptographic keys generally; Cloud HSM is one specific protection level within Cloud KMS where keys are generated and used only inside FIPS 140-2 Level 3 validated hardware, rather than Google’s software cryptographic module.

Does GCP support BYOK and HYOK?

Yes to both. BYOK is supported by importing customer-generated key material into Cloud KMS. HYOK-equivalent custody is supported through Cloud External Key Manager (Cloud EKM), which lets an external key manager hold the actual key material while Cloud KMS references it.

Is GCP’s Cloud HSM FIPS 140-3 validated?

Not yet at the hardware protection level; Cloud HSM is currently FIPS 140-2 Level 3 validated. GCP’s software protection level does use FIPS 140-3 Level 1-validated cryptographic primitives (BoringCrypto), which is a different claim than hardware-level 140-3 validation.

Does rotating a Cloud KMS key automatically protect old data with the new key?

No. Rotation only creates a new active key version for future operations; data already encrypted under the previous version stays dependent on it until an explicit re-encryption process runs.

How does GCP’s PKI (Certificate Authority Service) relate to Cloud KMS?

Certificate Authority Service can use Cloud KMS or Cloud HSM to protect a CA’s private signing key, but certificate issuance, validity periods, and revocation are managed independently of the Cloud KMS key rotation schedule.

Need help mapping your compliance requirements to the right GCP key-control tier? Talk to Encryption Consulting’s Cloud Key Management team.