Different system roles
A key management service manages key metadata, policy, versions, lifecycle, audit, and cryptographic operations through an API. A hardware security module is a protected cryptographic boundary that can generate, store, and use keys with physical and logical safeguards. A KMS can use an HSM, and an HSM can exist without a full lifecycle service.
Neither component decides which application record a user may access. The application and its authorization layer still own business data policy.
Operation and authorization
Prefer an API that performs encrypt, decrypt, sign, verify, wrap, unwrap, or derive without exporting the root key. Authenticate the workload with short-lived identity. Authorize each operation by key, purpose, environment, and service. Separate key administrators from application invokers and audit readers.
Bind ciphertext or signatures to tenant, object, purpose, and version through associated data or signed context. A service allowed to call decrypt on any ciphertext under a broad key can become a universal data bypass.
Availability and recovery
Model KMS and HSM as critical dependencies. Define regional, network, quota, latency, maintenance, and disaster behavior. Keep recovery keys and administrative paths separately protected. Test loss of one region, policy corruption, key disablement, rate limiting, and operator lockout.
Use envelope encryption to keep high-volume data operations local while the KMS protects smaller data keys. Cache only what the threat and availability model permits, with clear memory lifetime and revocation limits.
Failure and residual risk
Non-exportable does not mean non-usable by a compromised authorized workload. A broad KMS role can decrypt every tenant. An audit log cannot prevent a malicious operation. Provider-managed keys can simplify operations while leaving provider and control-plane trust in scope. Customer-managed keys increase control and recovery burden.
Pomerium boundary
Pomerium can protect human access to KMS administration interfaces and can provide workload access patterns around internal services. The KMS or HSM still requires its native workload identity and operation policy. Pomerium does not turn an application route decision into permission to invoke a data key or decrypt an object.
Evaluation checklist
- Which lifecycle functions belong to the KMS, HSM, application, and operators?
- Can root keys remain non-exportable while applications invoke only required operations?
- Is workload authorization narrow by key, operation, purpose, tenant, and environment?
- Can a compromised authorized service use the API to decrypt unrelated data?
- What happens during region loss, quota exhaustion, policy corruption, key disablement, and recovery?
- Are administrative, invocation, recovery, and audit roles separated and tested?
