Choosing Software and Hardware Backed Keys

Key management architecture in Google Cloud is the balance between security strength, cost, performance, and availability when choosing how keys are protected. Cloud Key Management Service (Cloud KMS) (opens in a new tab) stores each CryptoKey with a versionTemplate.protectionLevel that fixes where cryptographic operations run. That choice cannot be changed after the customer-managed encryption key (CMEK) is created, so it locks in security properties, service dependencies, and regional constraints for every service that uses the key.

1.1Where Each Protection Level Performs Cryptographic Operations

Protection level is the setting that controls where Cloud KMS performs encrypt, decrypt, and signing operations for a CryptoKey version. Hardware Security Module (HSM) protection means operations occur inside a hardware security module and provides a higher level of security, while SOFTWARE protection means operations occur in software and is acceptable for some lower-risk use cases. The level is set in versionTemplate.protectionLevel or primary.protectionLevel at creation time, so designs for BigQuery, Cloud SQL, and Looker must choose correctly before data is encrypted.

The four levels differ by trust boundary, connectivity, and capability:

Choosing HSM over SOFTWARE increases assurance but depends on hardware capacity, while choosing EXTERNAL or EXTERNAL_VPC adds an external dependency where Google lacks control over key availability. If an external key is deleted or cannot be recovered, Cloud SQL (opens in a new tab) instances encrypted with that key become permanently inaccessible.

1.2KeyRing Location, Region Matching, and Resilience

Availability in Cloud KMS starts with KeyRing location, which controls replication and failure isolation. A multiregion or global KeyRing replicates key metadata across geographic areas and avoids a single-region point of failure during a regional outage, while a single-region KeyRing keeps keys local to one region. That resilience tradeoff directly affects CMEK integration because not every service can use a multiregion key.

Cloud SQL requires the Cloud KMS key version and the instance to be in the same region, and a multiregion or global key causes the instance create request to fail. The key can live in the same project or a separate user project as long as the location matches. For External Key Manager (EKM) keys, resilience depends on the EkmConnection, which should have redundant service resolvers so operations do not fail during a single endpoint outage. An unreachable EKM key can suspend a Cloud SQL instance for hours, with internal validation taking up to 10 minutes to restore access after the key returns.

1.3CMEK Permissions, Quota, Rotation, and Monitoring Flow

CMEK integration connects a Google Cloud service, its per-product service account, and a specific Cloud KMS key version through Identity and Access Management (IAM). The service account for the project that contains the instance must hold the cloudkms.cryptoKeyEncrypterDecrypter role on the key, and operations fail when that grant is missing. When the key lives in a different project and Virtual Private Cloud Service Controls (VPC-SC) is enabled, the KMS key hosting project must also be added to the security perimeter.

Every cryptographic call flows from the using service to the Cloud KMS API, so quota and key state directly affect performance and uptime. Cloud KMS usage is subject to quota, and services such as Google Kubernetes Engine (GKE) call the Cloud KMS API on every cryptographic operation for application-layer secrets encryption, which requires confirming enough quota before enabling the feature. Administrator operations commonly fail for four related reasons:

• The Cloud KMS key version is missing, disabled, or destroyed
• The service account lacks the cloudkms.cryptoKeyEncrypterDecrypter role
• The key version is in a different region than the workload
• The EKM connection or authentication is unreachable

Cloud KMS integrates with Cloud Monitoring for dashboards and alerts on operations, quota thresholds, and keys scheduled for destruction, while Security Command Center provides built-in Cloud KMS vulnerability detectors. Regular rotation with rotationPeriod or nextRotationTime limits exposure if a symmetric GOOGLE_SYMMETRIC_ENCRYPTION key is compromised, and Google recommends keeping the previous enabled version for at least 45 days so existing data remains decryptable.

Isolation models for software and HSM keys describe where Cloud KMS executes cryptography and how strongly key material is separated from general software. Cloud Key Management Service (Cloud KMS) (opens in a new tab) binds each cloudkms.googleapis.com/CryptoKey to an execution environment through versionTemplate.protectionLevel, observed on the active version as primary.protectionLevel. After a customer-managed encryption key (CMEK) is created, its protection level cannot be changed, so isolation must be selected before the key protects data.

2.1How Protection Level Binds a Key to Its Execution Environment

Protection level in Cloud KMS is the architectural control that fixes where plaintext key material exists and where operations execute. A request that uses the key flows to the environment defined by the level, and the encrypt, decrypt, signing, or key-generation operation executes inside that boundary. This binding persists across the key lifecycle because the level is defined in the version template and carried by new versions. Changing isolation therefore requires creating a new key with a different level, not updating the existing key.

2.2Software-Backed Execution in the Cloud KMS Service Environment

Software-backed keys use SOFTWARE protection, which means cryptographic operations occur in software in the Cloud KMS service environment. The key material and cryptographic operations share the general software execution boundary rather than a dedicated hardware boundary. SOFTWARE protection is acceptable for some use cases where baseline protection is sufficient and hardware isolation is not required by policy.

Software-backed keys trade hardware isolation for simpler adoption without a dependency on a Hardware Security Module (HSM) (opens in a new tab) allocation. They fit workloads without heightened compliance or threat-model requirements that demand proven hardware containment. When higher assurance is later required, the same logical CryptoKey abstraction must be recreated with HSM protection rather than converted in place.

2.3Hardware-Backed Execution Inside Cloud HSM

Hardware-backed keys use HSM protection, which means cryptographic operations occur within a Hardware Security Module. The HSM forms a dedicated hardware boundary, so key material use and cryptographic computation remain isolated from the general software environment. This hardware isolation provides a higher level of security than software execution.

Cloud HSM keys are generally recommended for higher security requirements, including regulated data and compliance-driven architectures. The operational interface remains Cloud KMS, so applications still call the same CryptoKey resource, but the trust boundary shifts from software to hardware. That shift is why posture checks flag SOFTWARE when HSM is expected and flag HSM when hardware-only policy is being audited.

2.4Side-by-Side Comparison of SOFTWARE and HSM Isolation

The SOFTWARE and HSM models differ in where work executes and in the assurance that follows from that placement. External models extend the same pattern further by performing operations with keys stored in an external key manager over the internet or over a Virtual Private Cloud (VPC) network.

The table shows a one-way escalation in isolation from software execution to hardware-contained execution. Because protection level is immutable after creation, the choice among SOFTWARE, HSM, and external operation must align with compliance, performance, and operational requirements before deployment.

Regulatory mandates for hardware-backed protection decide when a Cloud KMS key must use hardware isolation instead of software. Cloud Key Management Service (Cloud KMS) (opens in a new tab) carries this decision on the CryptoKey resource cloudkms.googleapis.com/CryptoKey in its versionTemplate.protectionLevel field, which determines where cryptographic operations are performed. Cloud HSM protection means operations occur within a Hardware Security Module, while SOFTWARE protection means operations occur in software, and HSM provides a higher level of security for regulated data.

3.1Trust Boundaries Created by SOFTWARE Versus HSM Protection

Protection level in Cloud KMS defines the trust boundary for key use because it fixes where plaintext key material exists and where encrypt and decrypt operations execute. With SOFTWARE protection, the service performs cryptographic operations in software inside the Google software boundary. With HSM protection, the service sends cryptographic operations into a Hardware Security Module boundary, so key material never leaves the module in plaintext during use. This boundary difference is why SOFTWARE protection is acceptable for some use cases, while HSM protection is generally recommended for higher security requirements tied to compliance.

3.2Protection Level Options for Compliance-Driven Designs

Cloud KMS protection levels split by where the key lives and where cryptographic operations run, and the level cannot be changed after a customer-managed encryption key (CMEK) is created. The choice must be made at key creation because the primary protection level is immutable, which means a compliance-driven design must select HSM before data is encrypted.

For Cloud SQL (opens in a new tab), the key location also matters because the instance and the Cloud KMS key version must be in the same region, and a global or multiregion key will not work. For AlloyDB and BigQuery data warehouses, the same principle applies where the CMEK protection level controls whether regulated warehouse data depends on software, on Cloud HSM in a chosen region, or on an external manager.

3.3Evidence and Controls That Require Hardware-Backed Keys

Regulated workloads require hardware-backed keys when organizational policy, customer contracts, or assessors demand stronger isolation than software protection can prove. Cloud KMS maps its key-protection controls to NIST SP 800-53 controls SC-12 and SC-13 and to related CRI profile controls for data protection, which auditors use to trace encryption decisions to cryptographic key establishment and use. The FedRAMP Moderate Data Boundary lists cloudkms.googleapis.com v1 as SUPPORTED, so Cloud KMS operations can remain inside that compliance boundary when configured correctly. In this context, selecting HSM over SOFTWARE is the architectural evidence that cryptographic operations run inside hardware, not in general-purpose software memory.

3.4Continuous Detection and Audit Trail for HSM Compliance

Continuous compliance for hardware-backed protection depends on detecting any CryptoKey whose versionTemplate.protectionLevel or primary.protectionLevel is not HSM. Security Command Center includes built-in Cloud KMS vulnerability detectors that flag projects whose keys do not follow recommended practices, and Cloud KMS integrates with Cloud Monitoring to alert on key lifecycle events such as keys scheduled for destruction. Human access to request logs that return customer data requires a valid and documented business justification, and qualifying access is visible in Access Transparency logs. Together, the protection-level field, the detector findings, and the audit trail let a security engineer prove that regulated data flows only from authorized services to HSM-backed key versions and that no SOFTWARE key was substituted.

Key Facts

• Cloud Key Management Service (Cloud KMS) fixes a CryptoKey protection level in versionTemplate.protectionLevel at creation, and the level cannot be changed afterward.
• SOFTWARE protection runs cryptographic operations in software, while Hardware Security Module (HSM) protection runs operations inside a hardware security module with a higher level of security.
• Cloud SQL requires the Cloud KMS key version and the instance to be in the same region, and a multiregion or global key causes instance creation to fail.
• The service account using a customer-managed encryption key (CMEK) must hold the cloudkms.cryptoKeyEncrypterDecrypter role on the key or operations fail.
• An unreachable or destroyed external key manager (EKM) key can suspend a Cloud SQL instance, with restoration taking up to 10 minutes after the key returns.