Who is accountable when identity lifecycle controls fail during termination or role changes?

Why This Matters for Security Teams

Accountability for failed termination and role-change controls is not a single-owner problem because access removal depends on a chain of handoffs. HR, IAM or IGA, application owners, and platform teams each control a different failure point, and attackers only need one missed revocation to retain access. That is why lifecycle control is a core governance issue, not just an admin task. NHI Mgmt Group notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which is a useful proxy for how often lifecycle discipline breaks down in practice. The control baseline is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls and the lifecycle emphasis in the Ultimate Guide to NHIs.

What security teams often get wrong is assuming the issue is solved once the HR event is entered into a system. In reality, entitlement removal must propagate across directories, SaaS apps, secrets stores, SSH keys, service accounts, and CI/CD integrations. If any downstream system lacks automation or an owner who is accountable for enforcement, access lingers long after employment changes or role transitions. In practice, many security teams encounter stale access only after an incident, not through intentional offboarding testing.

How It Works in Practice

The cleanest operating model assigns accountability by control point. HR owns the authoritative employment or role-change event, identity governance owns orchestration, and each application or platform owner owns enforcement in their system. That means the question is not only “who approved the change,” but “who verified the removal succeeded everywhere?” The NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10 both point toward the same practical reality: lifecycle failure is usually caused by weak coordination, not a single bad actor.

• HR must generate the authoritative termination or transfer event promptly and consistently.
• IGA or IAM must translate that event into deprovisioning tasks, not just notifications.
• Application owners must ensure local permissions, tokens, and shared secrets are revoked.
• Security teams must test for orphaned access and review exceptions until closure.

For non-human identities, the same model applies, but the blast radius is often larger because service accounts, API keys, and automation tokens can survive personnel changes unnoticed. Strong programs treat termination as a revocation workflow that includes short-lived credentials, secret rotation, and verification logs rather than a simple disablement request. Best practice is evolving toward continuous control evidence, because point-in-time approval does not prove downstream removal.

These controls tend to break down in highly federated environments with unmanaged SaaS, embedded service accounts, or CI/CD systems that cannot enforce revocation centrally because ownership and technical control are fragmented.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance fast employee changes against verification and exception handling. That tradeoff is especially visible when contractors, temporary staff, and application service accounts share similar access paths. Current guidance suggests the accountable owner should still be unambiguous, but there is no universal standard for exactly how far that ownership extends across shared platforms and outsourced systems.

One edge case is indirect ownership. A manager may initiate a role change, but the real enforcement owner may be a platform team that controls secrets rotation or an app team that maintains entitlements. Another is privileged automation: if a user leaves but their scripts, scheduled jobs, or delegated tokens remain active, accountability must include whoever owns the workload, not just the departed individual. That is why lifecycle reviews should include The State of Secrets in AppSec when credentials are embedded in pipelines or code repositories.

For shared service accounts, the accountable party is usually the system owner or product team, because no human offboarding event will clean up access automatically. For regulated environments, audit teams often expect documented evidence of revocation, not just a ticket closure. The practical standard is simple: if the owner cannot prove removal, accountability has not been fulfilled, even if the HR record is correct.

Related resources from NHI Mgmt Group

• Who is accountable when AI security controls fail during a live event or proof of concept?
• Why do workforce identity changes need strong privilege controls during SSO modernisation?
• Who is accountable for enforcing lifecycle controls across apps that lack native identity standards?
• Who should be accountable for access governance when enterprises use a partner to implement identity controls?