HSM, EKM & key custody
FIPS hardware and keys Google cannot read.
CMEK is enough for most workloads. Regulated data or a "the cloud provider must not be able to read our data" requirement pushes you up the custody ladder to hardware-backed and externally-held keys — each rung buying more control and more operational weight.
Software CMEK vs Cloud HSM vs Cloud EKM
Software-backed CMEK keeps key material in Google’s software KMS. Cloud HSM stores it in FIPS 140-2 Level 3 hardware that never exports it in plaintext — the right choice when you need attestable, non-exportable keys for compliance. Cloud EKM (External Key Manager) goes furthest: the key material lives in a third-party key manager you control, and every cryptographic operation calls out to it, so revoking access in your external store makes the data unreadable even to Google. The tradeoff is a hard availability dependency on that external system.
# HSM-backed key: material never leaves FIPS 140-2 L3 hardware.gcloud kms keys create signing --location=europe-west1 --keyring=app \--purpose=asymmetric-signing --protection-level=hsm --default-algorithm=ec-sign-p256-sha256# EKM key: material lives in YOUR external key manager, reached over a# service connection; Google calls out for every crypto operation.gcloud kms keys create ekm-data --location=europe-west1 --keyring=app \--purpose=encryption --protection-level=external-vpc \--crypto-key-backend=projects/PROJ/locations/europe-west1/ekmConnections/ext
Choosing the rung, and key ceremonies
Climb only as high as the requirement demands — each level adds availability risk and operational ritual you must sustain. For top-level keys (a root of trust, a CA key) generate them in an HSM as a key ceremony: multiple custodians, dual control, split knowledge, and a witnessed, recorded procedure, so no single person can reconstruct or misuse the key and you can attest custody to an auditor. Assured Workloads can pin projects to specific regions, personnel, and key requirements for sovereignty regimes.