Who should be accountable for identities that sit outside traditional IGA coverage?

Accountability should sit with the business or technical owner who can authorize, review, and remove the identity in practice. If no such owner exists, the identity should be treated as unmanaged risk, not as an acceptable certification edge case. That principle applies equally to human, service, and application identities.

Why This Matters for Security Teams

When identities fall outside traditional IGA coverage, they often become everyone’s problem and no one’s responsibility. That gap matters because unmanaged service accounts, API keys, and agent identities can still approve access, call tools, and move laterally. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which means many “exceptions” are actually blind spots.

Security teams usually get this wrong by treating ownership as a paperwork exercise instead of an operating control. If an identity can be rotated, revoked, or approved only by a specific team, that team is the accountable owner even if the identity never appears in the IGA catalogue. That principle maps cleanly to the governance expectations in the NIST Cybersecurity Framework 2.0, where accountability and risk ownership must be explicit, not implied.

In practice, many security teams discover unmanaged identities only after a secrets leak, failed offboarding, or an audit finding forces the ownership question.

How It Works in Practice

The practical model is simple: every identity needs an accountable owner, even if it is not governed through the same workflow as a human user. For a service account, the owner is usually the platform, application, or infrastructure team that can approve its use and remove it safely. For an API key or integration token, the owner is the system or product team that depends on it. For agentic workloads, accountability should sit with the team that controls the agent’s tool access, runtime policy, and secret issuance.

This is where traditional IGA often stops too early. IGA can certify entitlements, but it cannot substitute for operational control over identities that are created in code, injected in CI/CD, or issued dynamically at runtime. Best practice is to connect ownership to a clear set of actions: approve, review, rotate, revoke, and document the identity’s business purpose. NHI Management Group’s JetBrains GitHub plugin token exposure is a useful reminder that exposed tokens are not abstract artifacts; they are live access paths that need a named owner and a removal path.

• Assign an accountable owner who can act, not just a system of record that can record.
• Define a fallback escalation path if the original owner leaves or the application is retired.
• Require rotation and revocation ownership to be explicit before granting production access.
• Use SPIFFE and related workload identity patterns where identity must be proven cryptographically at runtime.

For organisations aligning to CISA Zero Trust Maturity Model principles, the identity owner must also own the policy decisions that make access temporary, contextual, and reviewable. These controls tend to break down when identities are created by automation with no service owner because remediation then depends on tribal knowledge rather than a defined control path.

Common Variations and Edge Cases

Tighter ownership controls often increase operational overhead, requiring organisations to balance accountability with delivery speed. That tradeoff is real, especially in environments with ephemeral cloud resources, contractor-driven builds, or agentic AI systems that spin up short-lived credentials on demand. Current guidance suggests the answer is not to relax ownership, but to make it lighter weight and more automatic.

Edge cases usually fall into three buckets. First, legacy identities may have no obvious owner because the original application team no longer exists. In that case, the identity should be classified as unmanaged risk until a steward is assigned. Second, platform-managed identities may be centrally issued, but the consuming team still owns business justification and periodic review. Third, in multi-team or shared pipeline environments, there is no universal standard for this yet, so organisations should document joint ownership and name one operationally accountable party.

For autonomous agents, the question becomes even sharper because the actor may chain tools and request new credentials dynamically. In those environments, accountability should extend to the team responsible for the agent’s policy guardrails, not only the people who trained it or deployed it. NHI Management Group’s Ultimate Guide to NHIs is clear that excessive privilege and weak visibility are common failure modes, so ownership must be paired with least privilege and revocation readiness.

That is why governance should treat “no owner” as a control failure, not as an acceptable exception.

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?