What breaks is the boundary between platform administration and security governance. Once teams use customer managed keys, cross-account grants, and custom rotation functions, key usage becomes an entitlement problem as much as a cryptography problem. Without clear ownership, audits miss who can encrypt, decrypt, or rotate protected assets.
Why This Matters for Security Teams
Customer managed keys turn encryption into a governance boundary, not just a technical control. The moment a team can define key policies, create grants, or automate rotation, the question becomes who owns the decision to decrypt data, not just who holds the material. That is why identity reviews, audit trails, and separation of duties matter as much as key length or algorithm choice. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for the ownership problem behind key sprawl.
When ownership is unclear, teams often assume the cloud platform, the application owner, and security all share responsibility. In practice, that usually means nobody is accountable for risky grants, stale key policies, or emergency overrides. The result is a control gap that can survive audits because the artefact exists, but the entitlement model around it is undocumented. Current guidance from the NIST Cybersecurity Framework 2.0 and NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives both point to the same issue: governance failures become security failures once cryptographic control is treated as shared ownership.
In practice, many security teams discover this only after a key grant, rotation job, or cross-account policy has already been abused rather than through intentional access review.
How It Works in Practice
Clear ownership for customer managed keys needs to be defined at three layers: administrative control, operational control, and security accountability. Administrative control covers who can create or edit keys, policies, aliases, and grants. Operational control covers who runs rotation jobs, break-glass procedures, and backup restoration. Security accountability covers who approves the intended use of the key, reviews exceptions, and signs off on changes that affect data exposure.
In mature environments, teams map each key to a named business service and a named control owner. That owner does not need to perform every action, but they must approve the entitlement model and review it continuously. This is where shared responsibility often fails. A platform team may manage the KMS service, while an application team requests grants, and a security team only sees periodic audit evidence. Without a single accountable owner, drift becomes invisible.
- Define one owner for each key, alias, and key policy.
- Treat grants and cross-account access as privileged entitlements.
- Require approval for rotation exceptions and policy changes.
- Log decrypt, re-encrypt, and grant creation events to a central review path.
- Reconcile key inventories against service ownership on a fixed cadence.
NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NHI Lifecycle Management Guide are useful because they frame keys, service accounts, and automation tokens as managed identities with lifecycles, not static assets. That aligns with lifecycle thinking in the NIST Cybersecurity Framework 2.0: identify ownership, protect usage paths, and continuously monitor entitlement drift. These controls tend to break down when keys are reused across multiple applications because no single team can prove which workload should retain decrypt rights.
Common Variations and Edge Cases
Tighter key governance often increases operational overhead, requiring organisations to balance auditability against deployment speed. That tradeoff becomes sharper in multi-account cloud estates, merger environments, and platform engineering teams that rely on automated pipelines.
There is no universal standard for this yet, but current guidance suggests that shared keys should be the exception rather than the norm. Shared ownership is most dangerous when rotation is delegated to code but approval remains informal. In those cases, the automation may succeed technically while silently bypassing the real control owner. A similar issue appears with break-glass access: if emergency grants are not tied to named approvers and time limits, the exception becomes a standing privilege.
Another edge case is application teams using customer managed keys for data classification, while the security team owns only the underlying KMS policy. That split can work if responsibilities are explicit, but it fails when cross-account grants are inherited by new workloads without re-approval. NHI Mgmt Group’s breach research on Coupang Signing Key Breach shows how signing and encryption trust can be lost when governance does not keep pace with key usage. The practical rule is simple: if no one can answer who is allowed to decrypt, rotate, or delegate the key today, the control is already failing.
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 AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers weak lifecycle control over non-human credentials and keys. |
| NIST CSF 2.0 | PR.AC-4 | Access control governance applies to key grants and decrypt permissions. |
| NIST AI RMF | AI governance framing helps when automated policies manage sensitive key access. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires explicit enforcement of who can use protected resources. |
Treat decrypt rights as explicit, context-bound policy decisions with continuous verification.
