Accountability should sit with the identity owner, the application owner, and the business approver chain that failed to remove or revalidate access. Governance frameworks such as NIST Cybersecurity Framework 2.0 and internal access review processes assume responsibility is explicit. If it is not, risk persists after the person leaves.
Why This Matters for Security Teams
Access that remains active after a role change or departure is not just an HR cleanup issue. It is a control failure across identity lifecycle, approvals, and application ownership. When accountability is unclear, stale access tends to survive longer than anyone expects, especially in shared admin paths, service desks, and low-visibility applications. That is why NHI Management Group treats lifecycle discipline as a governance control, not a back-office task.
For non-human access patterns, the blast radius is often larger than the departed user. The Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification. That gap shows why ownership must be explicit from the start. The OWASP Non-Human Identity Top 10 also reinforces that weak lifecycle governance creates persistent exposure, even when the original assignment looked legitimate.
In practice, many security teams discover stale access only after a joiner-mover-leaver review, an incident, or an audit finding rather than through intentional preventive controls.
How It Works in Practice
Accountability should be distributed, but not diluted. The identity owner is responsible for lifecycle accuracy, the application owner is responsible for access enforcement inside the system, and the business approver chain is responsible for confirming that access still matches the role. If any one of those parties assumes another will remove access, the control breaks. Mature programs tie this responsibility to HR events, access review attestations, and ticketed deprovisioning workflows.
Operationally, this means the workflow should answer three questions at departure or role change: who approved the original access, who confirmed the new role, and who verified removal. Best practice is to use explicit ownership records, time-bound review SLAs, and evidence captured in the ticket or identity governance platform. NHI Management Group’s 52 NHI Breaches Analysis shows how often control gaps persist because no one can point to a named owner when access lingers.
- Identity owners should maintain authoritative records for accounts, secrets, and assigned privileges.
- Application owners should confirm revocation actually occurred in the target system, not just in the ticket.
- Business approvers should revalidate whether access is still needed after any role change.
- Security teams should audit for orphaned access, shared credentials, and stale entitlements on a fixed cadence.
NIST guidance on access control and continuous review supports this shared accountability model, but the implementation burden remains local to the organisation. These controls tend to break down when applications lack central ownership, because revocation becomes dependent on manual follow-up and undocumented tribal knowledge.
Common Variations and Edge Cases
Tighter access governance often increases operational overhead, requiring organisations to balance faster workforce changes against stronger removal discipline. That tradeoff is real, especially where contractors, temporary staff, and cross-functional teams move quickly between roles. Best practice is evolving for these edge cases, and there is no universal standard for this yet, but current guidance suggests that accountability should still be explicit even when approval paths differ.
For third-party users, shared admin accounts, and service accounts, responsibility may sit with a vendor manager, platform owner, or system custodian rather than a direct line manager. That is where NHI governance becomes critical. The same Ultimate Guide to NHIs — Key Challenges and Risks highlights how often excessive privileges and weak visibility make offboarding incomplete. In these cases, the right question is not only who had the authority to approve access, but who had the duty to prove it was removed.
For agentic or automated access, account ownership should also include the system that issued the token, the workflow that requested it, and the team that can revoke it. If that chain is unclear, the organisation has a governance gap, not just an access gap. In practice, accountability breaks down fastest where legacy apps, outsourced operations, and informal approval paths intersect.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Defines who can access assets and who must manage that access. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege and timely review of entitlements. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle ownership and revocation for non-human identities. |
Assign clear access owners and require documented removal approval for every role change or departure.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What breaks when movers keep inherited access after a role change?
- Who is accountable when vendor access remains active after a banking engagement ends?
- What breaks when access reviews do not keep pace with role changes?
