Accountability sits with the identity governance owner, the business approver, and the system owner that failed to enforce lifecycle offboarding. In practice, frameworks expect shared responsibility, but the control failure is usually the absence of a clear revocation owner.
Why This Matters for Security Teams
When an employee changes roles, stale access rarely looks like a single policy failure. It usually reflects a broken handoff across identity governance, business approval, and the system owner who should have enforced revocation. NIST’s NIST Cybersecurity Framework 2.0 treats access governance as an ongoing operational discipline, not a one-time provisioning event, and that framing matters because role changes are a common point where orphaned entitlements persist.
The practical risk is simple: a user can keep access that no longer matches their job, expanding blast radius after transfers, promotions, or contractor transitions. In NHI environments, the same weakness shows up with dormant service accounts, shared admin IDs, and API credentials that outlive the person or process that created them. NHIMG research on the LLMjacking: How Attackers Hijack AI Using Compromised NHIs report shows how quickly exposed credentials are operationalised once they are accessible, which makes delayed revocation especially dangerous. In practice, many security teams discover stale access only after an audit exception, a failed offboarding review, or an incident has already forced the question.
How It Works in Practice
Accountability for stale accounts is shared, but the effective control owner should be explicit. Identity governance teams typically run the lifecycle process, business approvers confirm whether access is still needed, and the system owner or application owner must ensure the revocation actually takes effect in the target system. If one of those parties assumes another will close the loop, accounts remain active after the role change.
A workable operating model usually includes:
- Role-change triggers from HR or workflow systems that start access review automatically.
- System-specific deprovisioning checks that verify access removal, not just ticket closure.
- Periodic reconciliation between authoritative identity records and live entitlements.
- Escalation paths for exceptions, especially where shared accounts, legacy apps, or manual admin steps exist.
This is also where naming the owner matters. If a business approver approves the new role but nobody owns the revocation of old access, the control is incomplete. NIST guidance supports continuous governance, while NHIMG analysis in the DeepSeek breach context underscores how exposed secrets and lingering access can become active attack paths when lifecycle controls lag. For organisations operating under NIST Cybersecurity Framework 2.0, the key is to map each entitlement to a named revocation owner and verify removal at the system layer, not just in the IAM console. These controls tend to break down when legacy applications lack automated deprovisioning interfaces because manual removal depends on informal follow-through.
Common Variations and Edge Cases
Tighter revocation controls often increase operational overhead, so organisations need to balance speed of access changes against the cost of proving every removal. That tradeoff becomes more visible in mixed environments where cloud IAM is automated but on-premises or SaaS systems still require manual action.
There is no universal standard for this yet, but current guidance suggests treating different account types differently. Human user accounts should be tied to HR-driven lifecycle events, while privileged, shared, and non-human accounts need separate ownership and validation. For contractors and temporary staff, the business approver may be the most important accountability point because they are best positioned to confirm when work ends. For service accounts, accountability usually shifts toward the system owner and platform team, since those identities often outlive any single employee role.
The biggest edge case is when stale access is technically “known” but not removed because the application cannot enforce revocation cleanly. In that situation, compensating controls such as stronger monitoring, session limits, and scheduled recertification are necessary, but they are not a substitute for a named revocation owner. That is why shared responsibility must still end in one accountable party for each system and each entitlement.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed through the full lifecycle, including role changes. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Stale non-human or privileged accounts are a common credential lifecycle failure. |
| NIST AI RMF | AI RMF governance applies when account sprawl affects autonomous or AI-operated systems. |
Define accountable owners for lifecycle controls and continuously monitor entitlement drift.
