Google Cloud Platform (GCP) – Introduction to Google Cloud HSM

Google Cloud HSM is a managed service on Google Cloud Platform (GCP) that provides FIPS 140-2 Level 3 validated Hardware Security Modules (HSMs) as the cryptographic backend for Google Cloud KMS (Key Management Service). It matters because FIPS 140-2 Level 3 hardware validation is a mandatory requirement for FedRAMP High, PCI DSS, and eIDAS qualified signature workloads, and standard Cloud KMS software-protected keys do not meet that threshold. The recommended action is to create Cloud KMS keys with the HSM protection level for all regulated workloads, enable automatic key rotation, and configure Cloud Audit Logs to capture every cryptographic operation against an authenticated identity.

Quick Answer: What Is Google Cloud HSM and When Do You Need It?

Google Cloud HSM is the HSM-backed key protection tier within Cloud KMS. When you create a Cloud KMS key with protection level HSM, the key is generated inside FIPS 140-2 Level 3 validated hardware, cryptographic operations are performed inside the HSM boundary, and the key material never leaves the HSM in plaintext. You need Cloud HSM when your compliance framework requires FIPS 140-2 Level 3 key protection (FedRAMP High, PCI DSS for high-value keys, eIDAS), when you need hardware attestation proving key material was generated in a tamper-resistant device, or when your organization’s security policy requires dedicated hardware for encryption key custody on GCP. For workloads that do not require Level 3 hardware validation, Cloud KMS software-protected keys at FIPS 140-2 Level 1 are simpler and significantly cheaper.

Key Takeaways

• Cloud HSM uses FIPS 140-2 Level 3 validated HSMs: Keys created with the HSM protection level in Cloud KMS are generated and used exclusively inside the HSM cluster. Key material never leaves the HSM in plaintext. The HSM cluster is regionally bound; keys cannot be moved outside the GCP region in which they were created.
• Cloud HSM is accessed through the same Cloud KMS API as software-protected keys: No application changes are required to switch from software-level to HSM-level key protection. The protection level is set at key creation and cannot be changed afterward.
• HSM firmware is vendor-controlled and Google cannot modify it: All HSM firmware is digitally signed by the hardware vendor. This vendor control over firmware is a key security invariant that prevents Google from introducing unauthorized code changes to the HSM environment.
• Cloud HSM supports BYOK via Cloud KMS Import Jobs: You can generate key material in your own HSM or key management system, wrap it, and import it into Cloud KMS with the HSM protection level. Cloud External Key Manager (Cloud EKM) supports HYOK, where the key never enters GCP at all.
• Cloud HSM key versions cost $2.50 per month per active version: This is significantly higher than software-protected key versions ($0.06 per month). Use HSM protection only where required by regulation or policy to avoid unnecessary cost.

What Is Google Cloud HSM?

Google Cloud HSM is a managed cloud service within Google Cloud Platform that provides hardware security module (HSM) infrastructure as the cryptographic key storage and operation backend for Google Cloud KMS. An HSM (Hardware Security Module) is a dedicated physical computing device designed to protect cryptographic keys inside a tamper-resistant hardware boundary, generate keys using hardware random number generators, and perform cryptographic operations (encryption, decryption, signing, verification) inside that boundary so key material never has to leave in plaintext.

When you create a key in Cloud KMS and specify the HSM protection level, you are directing Cloud KMS to generate and store the key inside the Cloud HSM cluster rather than in software-based cryptographic modules. The Cloud HSM service is accessed through the same Cloud KMS API and client libraries as software-protected keys. Existing applications that use Cloud KMS require no code changes to use Cloud HSM; only the protection level parameter at key creation changes.

Cloud HSM is fully managed by Google: the physical HSM hardware, firmware, networking, and high availability are Google’s operational responsibility. Google provisions HSMs with multi-party authorization controls, logical and physical safeguards, and separation of duties between Cloud HSM administrators and logging administrators. The customer’s responsibility is key policy configuration, IAM access control, key rotation scheduling, and audit log monitoring.

FIPS 140-2 Level 3 Validation and What It Means

FIPS 140-2 (Federal Information Processing Standard 140-2) is the NIST standard that defines security requirements for cryptographic modules. It specifies four security levels:

Level 1 requires basic software cryptographic algorithms. Level 2 adds tamper-evident physical security (seals or coatings that show evidence of tampering). Level 3 adds tamper-resistant physical security that actively destroys sensitive security parameters when tampering is detected, and requires identity-based authentication before performing cryptographic operations. Level 4 provides a complete physical security envelope protecting against environmental attacks.

Standard Cloud KMS software-protected keys are validated at FIPS 140-2 Level 1. Cloud HSM-protected keys are validated at FIPS 140-2 Level 3. This is the distinction that matters for regulated workloads: FedRAMP High, PCI DSS high-assurance deployments, and eIDAS qualified signature creation devices (QSCDs) require Level 3, not Level 1.

A critical security property of Cloud HSM is that the HSM firmware is digitally signed by the hardware vendor and Google cannot create or modify it. This vendor control over firmware prevents Google from introducing code changes that could weaken the HSM’s security boundary, export key material, or bypass the tamper-resistance mechanisms. All firmware updates from the vendor are signed, including development firmware used for testing. This property is what allows customers to cryptographically attest that their keys were generated and remain exclusively within the hardware boundary.

Cloud HSM Key Hierarchy and Storage Architecture

Google Cloud HSM uses a multi-layer key hierarchy to protect customer key material across the Cloud KMS infrastructure.

Root key: A root key is generated on the HSM and, throughout its lifespan, never leaves the well-defined boundaries of the HSM cluster. Cloning of the root key across HSMs within the same region cluster is permitted for high availability; the root key is never exported outside the regional HSM cluster.

Customer key wrapping: The root key is used to wrap (encrypt) customer keys at rest. Customer keys are stored in wrapped form in Cloud KMS’s key datastore. When a customer key is needed for a cryptographic operation, it is loaded into the HSM, unwrapped by the root key inside the HSM boundary, used for the operation, and then the plaintext key material is discarded from HSM memory. The HSM never returns an unwrapped customer key to any caller. HSMs can only use customer keys for operational purposes.

Cloud KMS key datastore: HSMs are not used as permanent key storage (HSM storage capacity is constrained). Customer keys are encrypted by the HSM root key and stored in Cloud KMS’s key datastore, which provides availability, durability, residency, and protection properties. The datastore uses authenticated encryption to store customer key material, and all metadata is authenticated using HMAC to detect corruption. Every hour, a batch job scans all key material and verifies HMAC validity and successful decryption. The datastore maintains hourly snapshots retained for four days, daily full backups to disk and tape, and a row-level change history for emergency recovery. Datastore backups reside within the associated GCP region and are encrypted at rest. Datastore engineers have no access to plaintext customer key material.

Cloud HSM Provisioning and System-Level Security Invariants

Google provisions Cloud HSMs in a lab equipped with physical and logical safeguards, including multi-party authorization controls that prevent any single administrator from compromising the HSM configuration. The following system-level invariants apply to every Cloud HSM cluster:

• Customer keys cannot be extracted as plaintext: No Cloud HSM operation returns plaintext customer key material to any caller, including Google employees.
• Customer keys cannot be moved outside the region of origin: Keys created in a Cloud KMS keyring are bound to the GCP region of that keyring and cannot be migrated to another region.
• All configuration changes are guarded through multiple security safeguards: Changes to HSM configuration require multi-party authorization, preventing single-actor compromise.
• Administrative operations are logged with separation of duties: Cloud HSM administrators and logging administrators are separate roles. Administrators cannot modify or delete their own audit logs.
• HSMs are protected from tampering throughout their operational lifecycle: Physical tamper-resistance mechanisms are active from provisioning through decommissioning, detecting and responding to attempts to insert malicious hardware or software or extract secrets.

Key Control Models: Native Cloud HSM, BYOK, and HYOK

Cloud HSM supports three key control models with meaningfully different security and sovereignty properties.

Native Cloud HSM (Google-Generated Key Material)

In the default Cloud HSM model, Google generates the key material inside the HSM cluster. You create a Cloud KMS key with protection level HSM, and Cloud KMS generates the key inside the HSM, wrapped by the HSM root key, and stores it in the Cloud KMS datastore. You control who can use the key (via IAM and key policy), when it rotates, and whether it is disabled or destroyed. Google manages the HSM hardware and the key material generation, but cannot use the key on your behalf without an authenticated API call under your IAM policy.

This model is appropriate for most regulated GCP workloads. You get FIPS 140-2 Level 3 hardware protection, regional key residency, hardware attestation, and per-operation Cloud Audit Logs, with no operational burden for HSM hardware management.

BYOK (Bring Your Own Key) via Cloud KMS Import Jobs

Cloud KMS Import Jobs support importing externally generated key material into Cloud KMS with HSM as the target protection level. You generate 256-bit AES key material (or RSA/ECC key material for asymmetric keys) in your own HSM or key management system, wrap it using the import job’s wrapping key (an RSA-OAEP or AES-KWP wrapped key downloaded from the import job), and upload the wrapped material to Cloud KMS. When the import job receives the wrapped material, it unwraps it inside the Cloud HSM cluster using the import job’s private key and stores the customer-provided key material under HSM protection.

BYOK satisfies compliance requirements that mandate customer-generated key material. You retain the original key material in your own HSM and can delete the imported copy from Cloud KMS to immediately revoke GCP’s ability to use the key. Note that GCP has operational access to the key material during use (it must be loaded into the HSM for cryptographic operations); BYOK provides provenance control and revocation capability, but not zero-GCP-access.

HYOK (Hold Your Own Key) via Cloud External Key Manager

Cloud External Key Manager (Cloud EKM) is the GCP service that implements HYOK for Cloud KMS. With Cloud EKM, the encryption key never enters GCP infrastructure. When a Cloud KMS operation requires the key (for example, encrypting a BigQuery column or a Cloud Storage object), Cloud KMS calls your external key management system over a TLS-authenticated connection, performs the key operation in your external KMS, and returns only the result to GCP. GCP stores only ciphertext; it cannot decrypt your data without a live connection to your external key management system.

Cloud EKM is appropriate for data subject to sovereignty requirements where GCP infrastructure itself is outside your trust boundary, or for workloads where your threat model includes Google as a potential access point. The operational cost is that every encrypt and decrypt operation requires a low-latency, highly available connection to your external key management system; any outage in your external KMS renders GCP resources using that key inaccessible. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 key management infrastructure needed for Cloud EKM-based HYOK implementations.

Dimension	Native Cloud HSM (Google-generated)	BYOK (Import Job)	HYOK (Cloud EKM)
Key generated by	Cloud HSM cluster	Customer HSM (imported into Cloud HSM)	Customer (never enters GCP)
FIPS 140-2 Level 3	Yes	Yes (imported material stored in HSM)	Depends on external KMS
GCP access to key during use	Yes (in HSM boundary)	Yes (in HSM boundary)	No
GCP can decrypt data if compelled	Yes	Yes (while key is in Cloud KMS)	No
Independent revocation	Disable or destroy key via API	Delete imported material immediately	Revoke at external KMS
Automatic key rotation	Yes	No (manual re-import required)	Managed by external KMS
Operational complexity	Low	Medium	High
Additional cost	$2.50/key version/month	$2.50/key version/month + HSM cost	$0.04/10k ops + external KMS cost
Best for	Most regulated GCP workloads	Workloads requiring customer key provenance	Sovereignty-mandated, zero-trust environments

IAM Model for Google Cloud HSM Access Control

Access control for Cloud HSM operations is managed through Google Cloud IAM, Cloud KMS key resource policies, and organizational policy constraints. The IAM model for Cloud HSM separates three operational roles that must not overlap.

Key administrator (cloudkms.admin): Creates keyrings and keys, manages key versions, configures key rotation schedules, enables and disables key versions, and schedules key versions for destruction. The key administrator role must not be granted to any application service account or automated pipeline. Key administrator actions are logged in Cloud Audit Logs as Admin Activity events, which cannot be disabled.

Key operator or crypto user (cloudkms.cryptoKeyEncrypterDecrypter): Uses the Cloud HSM-protected key to perform encrypt and decrypt operations. This is the role granted to application service accounts that need to encrypt or decrypt data using the HSM key. More granular split: cloudkms.cryptoKeyEncrypter grants encryption-only, and cloudkms.cryptoKeyDecrypter grants decryption-only. Always apply least privilege: a service that writes encrypted data needs Encrypter; a service that reads encrypted data needs Decrypter; only services that do both need EncrypterDecrypter.

Key viewer (cloudkms.viewer): Can view key metadata (protection level, rotation schedule, key state, creation date) but cannot use the key for cryptographic operations or manage its lifecycle. Appropriate for security audit, monitoring, and compliance roles that need visibility into key configuration without operational access.

Organization policy constraints: GCP Organization Policy Service allows you to enforce constraints at the organization, folder, or project level that apply to all Cloud KMS keys in scope. Key constraints include constraints/cloudkms.allowedProtectionLevels (enforce that all keys must use HSM protection level in specific projects), constraints/gcp.resourceLocations (enforce that keyrings can only be created in specified regions for data residency), and disabling key material import or export at the organization level. These constraints provide a policy guardrail layer above individual IAM permissions, similar to AWS Service Control Policies.

Key Rotation for Cloud HSM Keys

Cloud KMS supports automatic key rotation for HSM-protected keys. When you enable automatic rotation on a Cloud KMS key, Cloud KMS generates a new HSM-backed key version on the configured schedule. The new version becomes the primary version and is used for all new encrypt operations. Previous versions are retained in the Enabled state and continue to be used for decryption of data encrypted with those versions. The key’s resource name remains unchanged; rotation is transparent to applications.

Key rotation periods are configurable with a minimum of 24 hours for most symmetric key purposes. The recommended rotation period for symmetric HSM keys is 90 days for high-compliance environments (aligned with PCI DSS Requirement 3.7.4 guidance on cryptoperiods) or annually for standard regulated workloads. Each rotation event generates a new FIPS 140-2 Level 3 HSM-generated key version and logs a key version creation event in Cloud Audit Logs.

For imported BYOK key material, automatic rotation is not available because Cloud KMS cannot generate new versions of an externally originated key. You must manage BYOK rotation manually: generate new key material in your external HSM, create a new import job for the key, import the new material as a new key version, and set the new version as the primary. This manual process must be planned and executed within your defined cryptoperiod to maintain compliance.

Key version destruction has a mandatory 24-hour scheduled deletion period (configurable up to 120 days). During this window, destruction can be cancelled. Once the scheduled time passes, the key version and all key material are permanently destroyed and cannot be recovered. Scheduling destruction of an HSM key version generates a Cloud Audit Log Admin Activity event immediately, enabling security teams to detect and potentially cancel accidental or unauthorized destruction.

Cloud Audit Logs for Cloud HSM Operations

Every Cloud KMS and Cloud HSM operation generates a Cloud Audit Log entry. GCP Cloud Audit Logs are the primary audit trail for all key management and cryptographic operations on GCP, and they are a compliance requirement under PCI DSS Requirement 10, HIPAA’s Audit Control standard (45 CFR 164.312(b)), and FedRAMP AU controls.

Admin Activity logs (always enabled, cannot be disabled): Capture key creation, key version creation, key version state changes (enable, disable, schedule destruction, restore), key policy updates (IAM binding changes), and import job creation and completion. These logs are always written and cannot be turned off by any user, including project owners.

Data Access logs (enabled explicitly): Capture cryptographic operations: Encrypt, Decrypt, AsymmetricSign, AsymmetricDecrypt, MacSign, MacVerify. Data Access logs must be enabled explicitly at the project or organization level for Cloud KMS. Once enabled, every encrypt and decrypt call records the requesting service account, the key version ARN, the timestamp, and the calling IP address or service network. For regulated workloads, enabling Data Access audit logs for Cloud KMS is mandatory.

Route Cloud Audit Logs to Cloud Logging (the default) and additionally export them to Cloud Storage 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 the following events: any key version destruction scheduling for production keys (alert immediately); any IAM binding change on a Cloud KMS keyring or key; any Decrypt operation from a service account not in the approved list for that key; and any Encrypt or Decrypt operation originating from an unexpected source network.

Google Cloud HSM Pricing

Cloud HSM pricing has two components: key version storage and cryptographic operation calls.

Key version storage: HSM-protected key versions cost $2.50 per active key version per month. Software-protected key versions cost $0.06 per active key version per month. The price difference reflects the cost of dedicated HSM hardware infrastructure. Key versions in the Scheduled for Destruction or Destroyed state are not billed.

Cryptographic operations: Symmetric encrypt and decrypt operations using HSM-protected keys cost $0.03 per 10,000 operations, the same as software-protected keys. Asymmetric signing and decryption operations cost between $0.03 and $0.15 per 10,000 operations depending on the key type and algorithm. Cloud EKM operations (for HYOK) incur an additional $0.04 per 10,000 operations on top of the external KMS’s own charges.

Cost optimization: Cloud KMS does not have an equivalent to AWS KMS’s S3 Bucket Key feature for reducing API call costs. For high-volume GCP workloads using Cloud Storage, BigQuery, or other services with per-object KMS calls, use data encryption key (DEK) caching at the application layer where your security policy permits it. DEK caching means the application retrieves the plaintext DEK from Cloud KMS once per session or time window and uses it locally for multiple encrypt/decrypt operations, significantly reducing Cloud KMS API call volume. The risk trade-off is that the plaintext DEK is held in application memory for the cache window duration.

Cloud HSM in Multi-Cloud and Hybrid Architectures

Cloud HSM is a GCP-native service scoped to GCP infrastructure. Organizations operating across GCP and other cloud providers or on-premises environments need an explicit strategy for consistent key governance across the full estate. Three patterns address this:

• Per-cloud native HSM with unified governance: Use Cloud HSM for GCP workloads, AWS CloudHSM for AWS workloads, and Azure Dedicated HSM for Azure workloads, but deploy a centralized key lifecycle management platform that aggregates key inventory, rotation status, compliance posture, and audit logs across all three. This preserves native cloud performance and FIPS Level 3 validation in each cloud while providing cross-cloud visibility for compliance evidence collection.
• Centralized BYOK from an external HSM: Generate all key material from a single external HSM or HSM as a Service that is independent of all cloud providers. Import derived keys into Cloud KMS as BYOK keys (with HSM protection level) for GCP workloads, into AWS KMS for AWS workloads, and into Azure Key Vault for Azure workloads. All encryption across all clouds traces back to a single authoritative key source with a single revocation point. 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.
• Cloud EKM with a shared external key (HYOK across all clouds): Use GCP Cloud EKM for GCP workloads and equivalent external key references in AWS and Azure, with all clouds pointing to the same external key management system. GCP, AWS, and Azure each store only ciphertext; the external KMS holds the keys and services all decrypt operations. This is the strongest cross-cloud sovereignty model but requires the external KMS to be highly available for all cloud workloads.

Compliance: PCI DSS, FedRAMP, HIPAA, and eIDAS

PCI DSS v4.0.1 (mandatory since March 31, 2025): Cloud HSM satisfies Requirement 3.7.1 (key generation using HSM or other industry-accepted technology) when keys protecting cardholder data are created with HSM protection level. Cloud Audit Logs for Cloud KMS Data Access events satisfy Requirement 10 (logging and monitoring). Cloud KMS key rotation schedules support Requirement 3.7.4 (periodic key rotation). GCP’s PCI DSS certified infrastructure (Google Cloud is listed on the PCI SSC website as a Level 1 service provider) covers the Cloud HSM infrastructure layer; the customer remains responsible for IAM configuration, key policy, and application-layer controls.

FedRAMP: Cloud HSM-protected keys satisfy FedRAMP High’s requirement for FIPS 140-2 Level 3 validated cryptographic modules under SC-12 (Cryptographic Key Establishment and Management) and SC-28 (Protection of Information at Rest). Google Cloud services including Cloud KMS and Cloud HSM are authorized under FedRAMP High. Standard Cloud KMS software-protected keys (Level 1) do not satisfy FedRAMP High’s Level 3 requirement; HSM protection is required for FedRAMP High data.

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

eIDAS (EU): Qualified electronic signatures under eIDAS require qualified signature creation devices (QSCDs) meeting at least FIPS 140-2 Level 3 or Common Criteria EAL4+. Cloud HSM’s FIPS 140-2 Level 3 validation is compatible with this requirement for the HSM protection boundary. EU organizations implementing qualified signatures or qualified seals on GCP should verify that the specific GCP region used has Cloud HSM availability and that the overall architecture satisfies their national supervisory body’s requirements for QSCD classification.

Cloud HSM vs. Cloud KMS Software Protection: Decision Guide

Use the following criteria to decide whether a key should use HSM or software protection level in Cloud KMS.

Criterion	Use Cloud HSM (HSM Protection Level)	Use Cloud KMS Software (Software Protection Level)
FIPS 140-2 Level 3 required	Yes (FedRAMP High, some PCI DSS, eIDAS)	No (Level 1 sufficient)
Hardware attestation required	Yes	No
Key material must be in dedicated hardware	Yes	No
Data type	ePHI, PAN, classified, regulated	General workloads, internal data
Cost sensitivity	Higher ($2.50/key version/month)	Lower ($0.06/key version/month)
BYOK requirement	Supported (via Cloud KMS Import Jobs)	Supported (via Cloud KMS Import Jobs)
HYOK requirement	Use Cloud EKM (key never enters GCP)	Use Cloud EKM (key never enters GCP)

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, implement, and audit Google Cloud HSM configurations for GCP workloads from initial architecture through ongoing compliance evidence generation.

• GCP Key Management Architecture: We design your Cloud KMS and Cloud HSM architecture, including protection level selection per key type, keyring and key ring location strategy for data residency, IAM role structure with separation of duties, Organization Policy constraints for enforcing HSM protection requirements, BYOK import job workflows, and Cloud EKM integration for HYOK workloads. See our cloud data protection services.
• HSM as a Service for Cloud EKM and BYOK: For HYOK implementations using Cloud EKM, or BYOK implementations requiring FIPS 140-2 Level 3 key generation outside GCP, Encryption Consulting’s HSM as a Service provides the external HSM infrastructure. Keys generated in the HSM as a Service can be imported into Cloud KMS via Import Jobs for BYOK, or serve as the external key referenced by Cloud EKM for HYOK, maintaining the FIPS 140-2 Level 3 protection boundary outside GCP.
• CBOM Secure for GCP Key Discovery: GCP environments with many projects often have inconsistent key protection levels across Cloud Storage buckets, BigQuery datasets, GKE clusters, and Compute Engine disks. Encryption Consulting’s CBOM Secure discovers and inventories all Cloud KMS key configurations, protection levels, rotation statuses, and IAM policy bindings across GCP projects, generating a Cryptographic Bill of Materials (CBOM) in CycloneDX format that identifies keys using software protection where HSM is required, keys without rotation schedules, and over-permissive IAM bindings.
• PCI DSS and FedRAMP Compliance Advisory: We map your Cloud HSM configuration to the specific requirements of PCI DSS v4.0.1 (Requirements 3.7.1, 3.7.4, and 10), FedRAMP High (SC-12, SC-28), HIPAA Technical Safeguards, and eIDAS QSCD requirements. We identify gaps, produce the compliance evidence package, and support QSA and FedRAMP assessor inquiries. See our Compliance Advisory Services.
• PQC Readiness for Cloud HSM: 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. GCP Cloud HSM currently supports RSA and ECDSA asymmetric keys that will need migration to post-quantum algorithms before that timeline. Google Cloud’s post-quantum readiness roadmap for Cloud HSM and Cloud KMS is evolving. Encryption Consulting’s PQC Readiness service maps your GCP key estate against the post-quantum migration timeline and designs the key rotation and algorithm transition sequence.

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

Conclusion

Google Cloud HSM provides FIPS 140-2 Level 3 hardware-backed key protection for GCP workloads through the Cloud KMS API, with no application changes required for existing Cloud KMS customers. The HSM protection level is the right choice for regulated workloads requiring Level 3 hardware validation: FedRAMP High, PCI DSS cardholder data, HIPAA ePHI, and eIDAS qualified signature use cases. For workloads where Level 3 is not required, software-protected Cloud KMS keys provide equivalent API experience at significantly lower cost.

The key operational decisions for Cloud HSM are protection level selection at key creation (cannot be changed afterward), IAM role design with separation of key administrator from key operator, enabling Cloud Audit Logs Data Access events for Cloud KMS (not enabled by default), rotation schedule configuration, and BYOK or Cloud EKM integration if regulatory requirements mandate customer key provenance or zero-GCP-access sovereignty. Getting these right at architecture time is significantly easier than retrofitting them into a deployed GCP environment when a compliance audit identifies gaps.

Frequently Asked Questions

What is Google Cloud HSM?

Google Cloud HSM is a managed cloud service that provides FIPS 140-2 Level 3 validated hardware security modules as the key storage and cryptographic operation backend for Google Cloud KMS. Keys created with the HSM protection level are generated inside the HSM cluster, all cryptographic operations are performed inside the HSM, and key material never leaves the HSM boundary in plaintext. Cloud HSM is accessed through the same Cloud KMS API as software-protected keys; no application changes are required.

What FIPS validation level does Google Cloud HSM use?

Google Cloud HSM uses HSMs validated to FIPS 140-2 Level 3, which adds tamper-resistant physical security and identity-based authentication requirements beyond Level 2. HSM firmware is digitally signed by the hardware vendor; Google cannot create or modify HSM firmware. Standard Cloud KMS software-protected keys are validated at FIPS 140-2 Level 1. For FedRAMP High, PCI DSS high-assurance requirements, and eIDAS qualified signatures, Level 3 is required, making Cloud HSM the correct protection level.

What is the difference between Cloud KMS software-protected keys and Cloud HSM keys?

Software-protected keys are validated at FIPS 140-2 Level 1 and generated in Cloud KMS’s software cryptographic modules. HSM-protected keys are validated at FIPS 140-2 Level 3 and generated inside the HSM hardware cluster, with all operations performed inside the HSM boundary. The Cloud KMS API is identical for both; only the protection_level parameter set at key creation differs. HSM protection costs $2.50 per key version per month vs $0.06 for software protection.

Does Google Cloud HSM support BYOK?

Yes. Cloud KMS Import Jobs allow you to generate key material in your own HSM and import it into Cloud KMS with HSM as the target protection level. The imported material is stored and used in the Cloud HSM cluster. Cloud External Key Manager (Cloud EKM) supports HYOK, where the key never enters GCP and all cryptographic operations call your external key management system at runtime.

How does key rotation work in Google Cloud HSM?

Cloud KMS supports automatic key rotation for HSM-protected keys. A new HSM-generated key version is created on the configured schedule (minimum 24 hours; 90 days recommended for compliance workloads). The new version becomes primary for new encryptions; previous versions are retained for decryption. The key’s resource name stays the same; rotation is transparent to applications. For BYOK keys with imported material, automatic rotation is not available; you must manually import new key material as a new version.

What does Google Cloud HSM cost?

HSM-protected key versions cost $2.50 per active key version per month. Software-protected key versions cost $0.06 per month. Symmetric cryptographic operations cost $0.03 per 10,000 operations for both protection levels. Asymmetric operations cost $0.03 to $0.15 per 10,000 operations depending on key type. Cloud EKM (HYOK) adds $0.04 per 10,000 operations. Key versions in the Destroyed state are not billed.