A key that an organisation creates and controls rather than using the cloud provider's default managed key. It gives the organisation more policy, audit, and custody control, but it also shifts responsibility for grants, rotation, and lifecycle governance onto the team that owns it.
Expanded Definition
A Customer Managed Key, often abbreviated as CMK, is a cryptographic key whose creation, access policy, rotation schedule, and revocation are controlled by the customer rather than left to a cloud provider’s default key management. In NHI security, the term matters because CMKs frequently protect secrets, service-to-service traffic, and data associated with non-human identities. Compared with provider-managed encryption, CMKs give organisations stronger custody, auditability, and separation of duties, but they also create a governance burden that must be actively managed across the full lifecycle.
Definitions vary across vendors, because some platforms use CMK to mean a customer-owned key in a hardware security module, while others apply it to customer-administered keys in cloud KMS services. The security value is not the label itself, but the degree of control over grants, rotation, deletion, and emergency disablement. That control should be evaluated alongside NIST Cybersecurity Framework 2.0 and aligned with Ultimate Guide to NHIs — Regulatory and Audit Perspectives when the key secures NHI workloads or audit-sensitive data.
The most common misapplication is treating a CMK as a “set and forget” control, which occurs when teams enable customer ownership but do not own grants, rotation, or offboarding.
Examples and Use Cases
Implementing CMKs rigorously often introduces operational overhead, requiring organisations to weigh stronger custody and auditability against slower change management and more complex incident response.
- Encrypting a database that stores API tokens with a CMK so security teams can revoke access rapidly if a service account is compromised.
- Using a CMK for object storage that holds machine-generated logs, with explicit key rotation aligned to internal control windows and external audit requirements.
- Separating duties so the platform team can use encrypted workloads while the security team controls key policy in line with the NHI Lifecycle Management Guide.
- Protecting signing operations for automation pipelines, where a CMK limits blast radius if build infrastructure is exposed, as illustrated by the Coupang Signing Key Breach.
- Mapping key custody controls to cloud guidance such as the NIST Cybersecurity Framework 2.0 to support asset protection and recovery planning.
CMKs are especially useful when the organisation needs to prove who can disable encryption, who can rotate it, and who can recover from accidental deletion.
Why It Matters in NHI Security
CMKs are a governance control as much as a cryptographic control, because they determine whether an organisation can actually contain exposure when a service account, pipeline secret, or agent credential is misused. In NHI environments, that matters because encryption frequently protects the very assets that enable machine identities to operate: tokens, certificates, configuration stores, and signing material. If the wrong team controls the key, or if no team clearly owns revocation, the organisation may have visible encryption but no practical containment.
NHI Mgmt Group research shows that 71% of NHIs are not rotated within recommended time frames, and 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes disciplined key custody even more important. The same lifecycle gap that affects secrets also affects CMKs, especially when grants are left active after project completion or environment decommissioning. That is why Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Top 10 NHI Issues are useful reference points for understanding how key governance and identity governance intersect.
Organisations typically encounter CMK risk only after a key is lost, over-permissioned, or used to secure a compromised automation path, at which point customer control becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | CMKs affect secret custody, grants, and rotation for non-human identities. |
| NIST CSF 2.0 | PR.AA-01 | Key custody and access policy map to identity and access control outcomes. |
| NIST Zero Trust (SP 800-207) | PA-5 | Zero Trust requires explicit policy control over cryptographic trust anchors. |
| NIST SP 800-63 | Digital identity assurance informs how strongly CMKs should be protected and administered. | |
| NIST AI RMF | AI risk governance covers managed keys used to secure agentic systems and model services. |
Govern CMKs used by AI systems with explicit accountability, monitoring, and incident response.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
