This chapter covers Cloud HSM for hardware security, a critical component for meeting compliance and regulatory requirements in Google Cloud. For the ACE exam, understanding Cloud HSM's role in key management, its integration with Cloud KMS, and its operational characteristics is essential. Approximately 5–8% of exam questions touch on security compliance topics, with Cloud HSM being a key differentiator for enterprises requiring FIPS 140-2 Level 3 certification. You will learn the architecture, key operations, pricing model, and how to verify HSM-protected keys.
Jump to a section
Imagine a bank vault that can only be opened by a physical key held by a trusted custodian. The vault itself is made of tamper-resistant steel, with alarms and self-destruct mechanisms if anyone tries to break in. The custodian does not own the contents—they only hold the key and perform operations like locking or unlocking under strict protocols. In Cloud HSM, the HSM appliance is the vault, and customer-managed keys (CMKs) are the physical keys. The custodian is the HSM firmware that enforces access policies via IAM. When you ask the HSM to sign a document, the key never leaves the vault—the HSM performs the cryptographic operation internally and returns the result. Just as the bank logs every key use with timestamps and identities, Cloud HSM provides audit logs via Cloud Audit Logs. If someone tries to extract the key material, the HSM zeroizes itself, similar to a vault's self-destruct. The analogy extends to key hierarchy: a master key (like a master key to the bank) encrypts other keys (like individual safe-deposit keys), and the master key never leaves the HSM. This mirrors how Cloud HSM uses a root of trust that never leaves the hardware boundary.
What is Cloud HSM?
Cloud HSM (Hardware Security Module) is a Google Cloud service that provides dedicated HSM appliances to generate, store, and manage cryptographic keys in hardware. It is fully managed by Google, meaning you do not have direct access to the HSM hardware; instead, you interact via Cloud KMS APIs. Cloud HSM is designed for customers who require FIPS 140-2 Level 3 certification for key storage, which is a higher security level than software-backed keys (FIPS 140-2 Level 1). The service is available in multiple regions and uses a cluster of HSMs for high availability. Each HSM is a tamper-resistant device that performs cryptographic operations without exposing the key material.
Why Cloud HSM Exists
Many compliance frameworks—such as PCI DSS, HIPAA, and SOC 2—require that encryption keys be protected by hardware security modules. Software-based key storage is vulnerable to memory dumps and OS-level attacks. Cloud HSM addresses this by keeping keys within the HSM boundary, which has physical and logical protections. It also allows customers to retain control over key material in a multi-tenant cloud environment, as Google cannot access the keys (the HSM is designed so that even Google administrators cannot extract key material).
How Cloud HSM Works Internally
Cloud HSM integrates with Cloud KMS. When you create a key ring and a key, you specify the protection level as "HSM" (or "software" or "external"). The key material is generated inside an HSM device. The HSM uses a master key (a dedicated hardware key) to wrap (encrypt) the customer key material when it is stored outside the HSM. This wrapped key is stored in Cloud KMS's database. When a cryptographic operation is requested, Cloud KMS sends the wrapped key to the HSM, which unwraps it using the master key, performs the operation, and discards the unwrapped key from memory. The master key never leaves the HSM.
Key Components and Values
Protection Level: HSM is one of three options: software, HSM, or external. Default is software.
Key Types: Symmetric (AES-256), asymmetric (RSA-2048, RSA-3072, RSA-4096, EC P-256, EC P-384).
Key Purpose: SYMMETRIC_ENCRYPT_DECRYPT, ASYMMETRIC_SIGN_VERIFY, ASYMMETRIC_DECRYPT.
Import: You can import key material to an HSM key, but it must be encrypted with a wrapping key that is itself HSM-protected.
Pricing: Per key version per month, plus per operation (e.g., $0.001 per 10,000 symmetric operations).
Regions: Available in many regions; check the Google Cloud location list for HSM availability.
FIPS 140-2 Level 3: The HSM devices are certified at this level. Google Cloud publishes the certification documentation.
Configuration and Verification Commands
To create an HSM key using gcloud:
gcloud kms keyrings create my-keyring --location global
gcloud kms keys create my-hsm-key --keyring my-keyring --location global --purpose encryption --protection-level hsmTo list keys and verify protection level:
gcloud kms keys list --keyring my-keyring --location globalOutput shows protectionLevel: HSM.
To view details:
gcloud kms keys describe my-hsm-key --keyring my-keyring --location globalInteraction with Related Technologies
Cloud KMS: Cloud HSM is an option within Cloud KMS. All HSM operations go through Cloud KMS APIs.
Cloud Audit Logs: All HSM key usage is logged (Admin and Data Access). These logs are immutable and can be exported.
IAM: Permissions are managed via Cloud KMS roles (e.g., roles/cloudkms.cryptoKeyEncrypterDecrypter).
Cloud External Key Manager (EKM): An alternative for using keys stored in an external HSM (on-premises or third-party). Cloud HSM is Google-managed; Cloud EKM is customer-managed.
VPC Service Controls: You can restrict access to HSM keys within a VPC perimeter.
Operational Considerations
Key Rotation: You can rotate HSM keys; old key versions remain usable for decryption. Rotation creates a new key version inside the HSM.
Key Deletion: Deleting a key version is irreversible after a 24-hour (or 30-day for scheduled deletion) waiting period. The key material is zeroized.
Disaster Recovery: Keys are replicated across zones within a region. For cross-region replication, you must manually create copies using Cloud KMS key import/export.
Performance: HSM operations have higher latency than software keys due to hardware round-trips. Typical symmetric encrypt/decrypt latency is under 10 ms.
Quotas: Default quota is 1000 key versions per region, but can be increased.
Security Model
Google Cloud does not have access to the HSM master keys. The HSM firmware is designed to prevent extraction. However, Google manages the HSM hardware and firmware updates. For customers requiring complete separation, Cloud EKM allows you to use your own HSM outside Google's control.
Create a Key Ring
A key ring is a logical grouping of keys in a specific location. It is not a security boundary but helps organize keys. The location (e.g., global, us-central1) determines where the HSM resources reside. For HSM keys, the location must be a region that supports Cloud HSM. Use gcloud kms keyrings create command. Key rings have no cost.
Create an HSM Key
Use gcloud kms keys create with --protection-level=hsm. The key material is generated inside the HSM. You specify purpose (encryption, signing) and algorithm. For symmetric keys, the algorithm is automatically set to AES-256-GCM. The key version is created immediately. You can also import existing key material, but it must be wrapped with an HSM-protected key.
Grant IAM Permissions
Use gcloud kms keys add-iam-policy-binding to grant roles like cloudkms.cryptoKeyEncrypterDecrypter to service accounts or users. The IAM binding is at the key or key ring level. The principal must have the permission to use the key for the intended operation. For example, a service account encrypting data needs the encrypterDecrypter role.
Encrypt Data Using HSM Key
Use gcloud kms encrypt command with the HSM key. The plaintext is sent to Cloud KMS, which forwards it to the HSM. The HSM encrypts using the key material inside it. The ciphertext is returned. The key never leaves the HSM. The operation is logged in Cloud Audit Logs with the key version used.
Rotate the Key
Rotation creates a new key version. Use gcloud kms keys versions create. The new version becomes primary. Old versions remain active for decryption. Rotation can be automatic (set rotation period) or manual. The HSM generates new key material. The old key material remains in the HSM until deleted.
Delete a Key Version
Scheduling destruction: gcloud kms keys versions destroy. The key version enters DESTROY_SCHEDULED state for 24 hours (default). You can cancel during this period. After that, the key material is zeroized in the HSM and the version is removed. For asymmetric keys, the private key is destroyed; the public key can still be retrieved.
Scenario 1: Payment Card Industry (PCI) Compliance
A financial services company processes credit card transactions and must store encryption keys in a FIPS 140-2 Level 3 HSM. They use Cloud HSM with Cloud KMS to encrypt cardholder data at rest in Cloud Storage. They create a key ring in us-east1 with an HSM key for encryption. They configure IAM to allow only a specific service account used by their application to encrypt/decrypt. They enable key rotation every 90 days to meet PCI DSS requirement 3.6. The security team monitors Cloud Audit Logs for all key usage. A common misconfiguration is granting the cloudkms.admin role to the application service account, which allows key deletion—this is avoided by granting only the encrypterDecrypter role.
Scenario 2: Signing Digital Documents
A healthcare organization needs to digitally sign patient consent forms using asymmetric keys stored in an HSM for non-repudiation. They create an HSM key with purpose ASYMMETRIC_SIGN_VERIFY and algorithm EC P-256. The signing operation is performed by a backend service that receives the document hash. The HSM signs it and returns the signature. The public key is stored in a public repository for verification. The organization must ensure the private key never leaves the HSM. They use Cloud HSM because it provides FIPS 140-2 Level 3 and audit logging. A challenge is latency: each signing operation takes ~5 ms, which is acceptable for their volume of ~1000 signatures per hour. They also set up a disaster recovery plan by exporting the public key and backing up the key material (via import/export) to another region.
Scenario 3: Multi-Region Encryption with Key Material Import
A global e-commerce company wants to use the same encryption key across multiple regions to allow data to be encrypted in one region and decrypted in another. They generate key material on-premises using their own HSM, wrap it with a Cloud HSM key (the wrapping key), and import it into Cloud HSM in us-central1. They then export the key material (still wrapped) and import it into Cloud HSM in europe-west1. This creates two key versions with the same key material. They must manage the key material lifecycle carefully. A common pitfall is forgetting to wrap the key with a key that exists in the target region; they must first create a wrapping key in the target region and use it to re-wrap before import.
The ACE exam tests Cloud HSM under Objective 5.2 (Security Compliance) and also under Objective 5.3 (Managing Encryption Keys). Expect 1-3 questions that differentiate between software, HSM, and external protection levels. The most common wrong answer is choosing "Cloud KMS" as the answer when the question specifies "hardware security" or "FIPS 140-2 Level 3"—candidates often forget that Cloud KMS is the service, while Cloud HSM is the protection level within it. Another trap: candidates select "Cloud EKM" when the question says "Google-managed HSM." Remember: Cloud EKM is for external keys; Cloud HSM is Google-managed. Key numbers: FIPS 140-2 Level 3, AES-256, RSA-2048/4096, EC P-256/P-384. The exam loves to ask about key deletion: the default waiting period is 24 hours, not 7 or 30 days. Also, key material cannot be exported from Cloud HSM in plaintext—only wrapped. For asymmetric keys, the private key cannot be exported; the public key can. Edge case: If a question asks about creating an HSM key in a region that does not support HSM, the command will fail. Know which regions support HSM (check documentation, but for exam, assume global and major regions like us-central1, europe-west1). Another edge case: When importing key material, the wrapping key must be HSM-protected. The exam may present a scenario where a software key is used as wrapping key—this is incorrect. Also, understand that Cloud HSM does not support key generation outside the HSM—if you need to use your own key material, you must import it wrapped. Finally, know that Cloud HSM keys can be used with Cloud Storage (CSEK) and Compute Engine (CSEK) for customer-supplied encryption keys, but the key must be an HSM key. The exam may ask: "Which service allows you to use your own HSM for key management?" Answer: Cloud EKM, not Cloud HSM.
Cloud HSM is a protection level for Cloud KMS keys, providing FIPS 140-2 Level 3 hardware security.
HSM key material is generated inside the HSM and never leaves in plaintext.
Key deletion has a 24-hour default waiting period (DESTROY_SCHEDULED state).
Asymmetric private keys cannot be exported; public keys can.
Cloud HSM supports symmetric (AES-256) and asymmetric (RSA, EC) algorithms.
IAM roles for HSM keys are the same as Cloud KMS roles (e.g., cloudkms.cryptoKeyEncrypterDecrypter).
Cloud HSM is not available in all regions; check documentation.
Importing key material requires wrapping with an HSM-protected key.
Cloud Audit Logs record all HSM key operations.
Cloud HSM is distinct from Cloud EKM: HSM is Google-managed, EKM is customer-managed.
These come up on the exam all the time. Here's how to tell them apart.
Cloud HSM (Google-managed)
HSM hardware is managed by Google; no customer access.
Key material is generated and stored inside Google's HSMs.
FIPS 140-2 Level 3 certification.
Lower latency because HSM is in Google's network.
Simpler to set up; no need to manage external HSM.
Cloud EKM (External Key Manager)
Customer manages their own HSM (on-premises or third-party cloud).
Key material never leaves customer's HSM; Google only has a handle.
Customer must ensure their HSM meets compliance requirements.
Higher latency due to network round-trip to external HSM.
More complex setup; requires VPC and firewall rules.
Mistake
Cloud HSM is a separate service from Cloud KMS.
Correct
Cloud HSM is not a standalone service; it is a protection level option within Cloud KMS. You use Cloud KMS APIs and gcloud commands to create and manage HSM keys.
Mistake
You can directly access the HSM hardware in Google Cloud.
Correct
Cloud HSM is fully managed; customers have no direct access to the HSM. All interactions are via Cloud KMS APIs. Google manages the hardware.
Mistake
HSM keys are more expensive than software keys for all operations.
Correct
HSM keys have higher per-key-month costs but lower per-operation costs for symmetric operations. For high-volume encryption, HSM can be cost-effective.
Mistake
You can export the private key from Cloud HSM in plaintext.
Correct
Private key material cannot be exported in plaintext. You can export it wrapped (encrypted) using a wrapping key. The public key can be exported in plaintext.
Mistake
Cloud HSM provides FIPS 140-2 Level 4 security.
Correct
Cloud HSM is certified at FIPS 140-2 Level 3, which includes tamper-evident and tamper-resistant features. Level 4 is not currently offered by Cloud HSM.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud KMS is the key management service that provides APIs for creating, using, and managing keys. Cloud HSM is a protection level within Cloud KMS that stores keys in a hardware security module. When you create a key in Cloud KMS, you can choose protection level 'software' (default), 'hsm', or 'external'. Cloud HSM is not a separate service.
Yes, through Cloud External Key Manager (EKM). Cloud EKM allows you to use keys stored in a supported external HSM (e.g., on-premises or third-party). This is different from Cloud HSM, where Google manages the HSM. For ACE exam, remember that Cloud EKM is for external keys, Cloud HSM is Google-managed.
Use the gcloud command: gcloud kms keys create KEY_NAME --keyring KEY_RING --location LOCATION --purpose encryption --protection-level hsm. You can also do this via the Console under Security > Key Management > Create Key, selecting 'HSM' as the protection level.
Cloud HSM has a per-key version monthly cost (around $1 per key version per month, but varies by region) plus per-operation costs (e.g., $0.001 per 10,000 symmetric operations). There is no upfront cost. Check the official pricing page for current rates.
You can export the key material wrapped (encrypted) using a wrapping key. The wrapped key can be imported into another Cloud HSM instance or an on-premises HSM. The private key of an asymmetric key cannot be exported in plaintext. The public key can be exported in plaintext.
When you schedule destruction of a key version, it enters DESTROY_SCHEDULED state for 24 hours by default (configurable up to 30 days). During this period, you can cancel. After the waiting period, the key material is zeroized in the HSM and cannot be recovered. The key version is removed.
Yes. You can rotate HSM keys manually by creating a new key version, or set automatic rotation with a period (e.g., 90 days). The old key version remains available for decryption. Rotation generates new key material inside the HSM.
You've just covered Cloud HSM for Hardware Security — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?