Who should be accountable for non-human identities in an enterprise?

Why This Matters for Security Teams

Accountability for non-human identities only works when it is assigned to a named human who understands the business function, the data exposure, and the revocation path. NHI Management Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which means “shared ownership” quickly turns into no ownership at all. That gap matters because orphaned service accounts, API keys, and automation credentials often persist long after the workload changes.

Security teams usually miss this until a credential leak, failed offboarding, or unexpected privilege escalation forces the issue. The operational lesson is simple: the person who can explain why the identity exists must also be accountable for when it should be removed. Governance then provides the control layer that makes that accountability auditable and repeatable. The broader risk profile is consistent with guidance in the NIST Cybersecurity Framework 2.0 and with NHIMG research such as Ultimate Guide to NHIs — Why NHI Security Matters Now, which highlights how quickly NHI sprawl outpaces human oversight. In practice, many security teams encounter NHI accountability failures only after a stale key or service account has already been abused, rather than through intentional ownership design.

How It Works in Practice

The cleanest accountability model separates ownership from administration. A named business or technical owner is accountable for the NHI’s purpose, scope, and retirement. A governance team enforces policy, verifies evidence, and escalates exceptions. This split avoids the common failure mode where platform teams create identities and nobody is later responsible for them.

For most enterprises, the owner should be able to answer four questions: What workload uses this identity? What systems can it reach? What is the expiry or review date? What event triggers removal? That is where lifecycle controls matter most. Current guidance suggests pairing ownership records with inventory, rotation, and offboarding controls, because accountability without operational revocation is only a paper control. NHIMG’s data shows that only 20% of organisations have formal offboarding processes for API keys, which makes removal one of the weakest links in practice. The JetBrains GitHub plugin token exposure is a reminder that a credential can remain trusted even after the original use case has shifted.

• Assign one human owner per NHI, even if multiple teams touch the workload.
• Record business purpose, system dependencies, and a mandatory review cadence.
• Require governance approval for exceptions, long-lived credentials, and privilege changes.
• Link ownership to offboarding so decommissioning is a required step, not an optional cleanup task.
• Use a central inventory so ownership can be audited against actual runtime usage.

Best practice is evolving toward evidence-backed ownership, where the owner must validate continued need and the control team must confirm the identity is still scoped correctly. These controls tend to break down when identities are created automatically by CI/CD pipelines without a corresponding ownership record, because no one is accountable for the resulting sprawl.

Common Variations and Edge Cases

Tighter ownership rules often increase operational overhead, requiring organisations to balance accountability against deployment speed. That tradeoff is real, especially in engineering-heavy environments where thousands of ephemeral identities may be created and destroyed every day.

There is no universal standard for this yet, but current guidance suggests different treatment for different NHI classes. Long-lived service accounts and shared automation credentials need explicit named ownership and periodic review. Short-lived workload identities may be governed by a platform owner, provided the platform enforces issuance, expiry, and revocation automatically. In highly automated environments, accountability can sit with the product or service owner while a platform team operates the controls. The key is that someone must be able to answer for exposure, not just for configuration.

This becomes harder in third-party integrations, inherited cloud subscriptions, and legacy systems where identities were created before modern governance existed. In those cases, the first step is not perfection but attribution: identify the owner, define the retirement criteria, and make exceptions visible. NHIMG research shows that secrets often linger in vulnerable locations, so accountability must include not only the identity itself but also where its credentials are stored and who can revoke them. The strongest programs align that ownership model with identity governance and Zero Trust principles, then use review cycles to keep the record current.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities in Salesforce?