Who is accountable when centralized IAM still leaves access gaps?

Why This Matters for Security Teams

When centralized IAM still leaves access gaps, the issue is not simply missing approvals. It means the organisation has no single accountable control plane for non-human identities, so access can be granted in one system, expanded in another, and never fully revoked. That creates hidden privilege, audit drift, and unclear ownership across the access lifecycle. The OWASP Non-Human Identity Top 10 treats this as a core governance problem, not an edge case.

NHIs are often overrepresented in incident paths because they are numerous, interconnected, and easy to overlook. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges. Those numbers show why accountability cannot be pushed down to individual tool owners after the fact. In practice, many security teams encounter the failure only after a secret leak, privilege escalation, or offboarding miss has already widened access beyond what anyone intended.

How It Works in Practice

Accountability should sit with the identity governance owner because that function is the only place where approval, provisioning, rotation, review, and revocation can be measured as one lifecycle. Individual platform teams can own their systems, but they should not be allowed to fragment the control model. NIST SP 800-53 Rev. 5 emphasises access control, account management, and auditability as integrated controls, which is the operational baseline for closing these gaps.

In practice, the governance owner needs to define one authoritative policy for who can create access, under what conditions, how long it lasts, and how it is removed. That usually means:

• central policy for entitlement approval and periodic review
• central evidence for who provisioned, changed, and revoked access
• clear ownership for exceptions, including time-bounded approvals
• measurable SLAs for deprovisioning and credential rotation
• single reporting for orphaned, overprivileged, and stale identities

This is also where NHI-specific governance matters. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how quickly secrets, service accounts, and API keys become control gaps when they are managed inconsistently. The right model is not just “centralised IAM” in name. It is central decisioning with distributed execution, backed by consistent controls for revocation, rotation, and monitoring. Current guidance suggests that if the governance layer cannot show a complete access trail, then accountability has already been split across teams in a way that makes failure inevitable. These controls tend to break down in fast-moving DevOps environments because teams can bypass central review by embedding credentials directly into pipelines, code, or ad hoc automation.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations must balance speed against control coverage. That tradeoff is real, especially where engineering teams need rapid service creation or where legacy systems cannot be centrally administered.

There is no universal standard for this yet, but the best practice is evolving toward a clear split: platform teams own technical implementation, while identity governance owns policy, assurance, and final accountability. In hybrid and multi-cloud environments, central IAM may still leave gaps because some systems expose their own local roles, secrets stores, or service principals. In those cases, the governance owner must require compensating controls rather than assuming central policy will propagate everywhere.

NHIMG research shows that only 19.6% of security professionals express strong confidence in securely managing non-human workload identities, which helps explain why “shared responsibility” often becomes “no responsibility.” The practical fix is to define one owner for the full access lifecycle, then force every exception into that model. If a tool team can approve access but cannot revoke it, that team is not the accountable owner of the control. It is only an operator within a governance structure.

Related resources from NHI Mgmt Group

• Who is accountable when tool sprawl leaves major gaps in containment?
• Who is accountable when IAM control gaps appear in cloud or on-premises models?
• What breaks when cloud IAM still leaves old access in place after role changes?
• Who is accountable when phishing-resistant authentication still leaves recovery gaps?