Accountability should sit with the team that owns the identity lifecycle, not only the team that stores the credential. If the underlying service account or agent was never assigned purpose, review, and offboarding responsibility, governance has failed before the incident begins. That is why IAM, PAM, and IGA ownership must be explicit.
Why This Matters for Security Teams
When an unmanaged identity shows up in a breach, the problem is usually not limited to stolen credentials. It is a governance failure across ownership, purpose, review, and revocation. Non-human identities often outnumber human identities by a wide margin, and NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That means the question is less “who clicked” and more “who allowed this identity to exist without lifecycle control?”
This distinction matters because unmanaged identities are often created by engineering teams, deployed by platform teams, and discovered only after security teams detect abuse. The right accountability model has to follow the identity lifecycle, not just the vault, ticket, or control plane where the secret happened to be stored. NIST’s Cybersecurity Framework 2.0 frames this as an enterprise governance issue, not a narrow tooling issue. In practice, many security teams encounter unmanaged identity abuse only after lateral movement or cloud access has already been established, rather than through intentional lifecycle ownership.
How It Works in Practice
Accountability should be assigned at two levels. First, the identity owner owns the business purpose of the service account, workload, or agent. Second, the platform or security owner owns the control plane that issues, stores, rotates, or revokes the credential. If the identity has no named owner, no review cadence, and no offboarding path, then there is no accountable party when it is abused.
Operationally, mature organisations tie unmanaged identity response to a documented lifecycle workflow: discover the identity, classify its purpose, map its dependencies, identify the owning team, and determine whether the credential should be revoked, rotated, or re-issued with narrower scope. The NHI Lifecycle Management Guide is useful here because it treats discovery and offboarding as governance controls, not optional hygiene. Where secrets are embedded in code or CI/CD, ownership usually belongs to the application or pipeline team; where a workload identity is issued through a cloud platform, shared responsibility with the platform team becomes explicit.
- Use a named business owner for every service account, API key, certificate, or agent identity.
- Require an operational owner for rotation, revocation, and exception handling.
- Record the intended purpose, system dependency, and expiry date at creation time.
- Escalate unmanaged identities as policy violations, not just hygiene issues.
Anthropic’s report on the first AI-orchestrated cyber espionage campaign shows how quickly automated abuse can scale once identities are available to an attacker, which is why unmanaged access cannot be left to ad hoc follow-up. Where teams lack a complete inventory, the control fails because no one can prove whether an identity is dormant, business-critical, or already being abused.
Common Variations and Edge Cases
Tighter ownership rules often increase coordination overhead, requiring organisations to balance faster delivery against stronger accountability. That tradeoff becomes visible in shared platforms, inherited cloud accounts, and legacy integrations where one team created the identity and another team now depends on it. Current guidance suggests that accountability should still be explicit, even when technical custody is shared.
One edge case is a contractor or temporary integration that outlives its original project. Another is an AI agent or automation workflow whose behaviour changes after deployment, making static ownership records stale unless they are reviewed continuously. In those cases, the accountable party is usually the team that can approve purpose changes, enforce revocation, and answer for residual access. NHIMG’s 52 NHI Breaches Analysis shows that failure patterns often repeat when identities are left without clear lifecycle control. Best practice is evolving, but the baseline is consistent: if no one owns the identity end to end, no one truly owns the breach response either.
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 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-01 | Unmanaged identities indicate missing ownership and lifecycle governance. |
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight define who is accountable for identity misuse. |
| NIST AI RMF | GOVERN | Accountability for autonomous or automated identities is a governance requirement. |
Establish accountable owners for agent and workload identities, including review and shutdown authority.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
