Who is accountable when access outlives the role that created it?

Why This Matters for Security Teams

When access outlives the role that created it, the issue is not just stale entitlement. It is a broken accountability chain. The access tool may have provisioned correctly, but tools do not own business risk, approve exceptions, or decide when a role no longer justifies access. That responsibility sits with the business owner and the identity governance function, with security enforcing policy and evidence.

NHIs make this failure easier to miss because their access is often machine-speed, embedded in workflows, and assumed to be “temporary” even when it is not. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which broadens the attack surface when ownership is unclear in the lifecycle. See the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the current risk framing.

In practice, many security teams encounter this only after a role change, incident review, or audit finding has already exposed the entitlement drift.

How It Works in Practice

Accountability should be assigned at the point where access is approved, not where it is technically enforced. For human users, that usually means the line manager or application owner. For NHIs, it is the service or product owner, with identity governance maintaining the rules, evidence, and periodic review. The access platform can automate provisioning and deprovisioning, but it cannot decide whether the role still exists, whether the task is still legitimate, or whether an exception should be renewed.

A practical model separates three layers:

• Business ownership: validates why the access exists and whether the role still needs it.
• Identity governance: defines review cadence, approval paths, and revocation criteria.
• Security operations: monitors for stale grants, excessive privilege, and incomplete removal.

This aligns with the control logic described in the Ultimate Guide to NHIs — Key Challenges and Risks, and with OWASP guidance that governance must track the full NHI lifecycle, not only credential issuance. Where possible, pair ownership records with OWASP Non-Human Identity Top 10 style controls such as expiry, rotation, and offboarding evidence.

For high-risk workloads, current guidance suggests tying access to explicit business events such as job change, service retirement, or environment decommissioning, rather than relying on annual review alone. These controls tend to break down when ownership is split across platform, app, and data teams because no single party is clearly accountable for revocation.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, requiring organisations to balance faster provisioning against stronger review and revocation discipline. That tradeoff is especially visible where access is granted through shared service accounts, inherited group membership, or automated pipelines that outlive the original request.

One common edge case is “approved once, reused forever.” That is not governance, and current guidance suggests it should be treated as an exception with an expiry date, not as a standing entitlement. Another is vendor-managed tooling: even if the vendor operates the platform, the consuming organisation still owns the business risk created by the access. There is no universal standard for this yet, but best practice is evolving toward explicit named ownership, documented review intervals, and evidence that stale access is removed when the role changes.

For organisations with weak visibility into service accounts, the first step is not perfect policy design. It is to identify who can answer three questions for every entitlement: why it exists, who can renew it, and who must revoke it when the role ends. That is where accountability becomes operational instead of theoretical.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when cloud access expires on paper but persists in practice?