Who is accountable when an application keeps access after a user leaves the directory?

Why This Matters for Security Teams

When an application keeps access after a user leaves the directory, the failure is usually not in the directory itself. It is in the identity lifecycle integration that should have propagated the offboarding event into every connected application, API, and service. That makes this a governance and control-ownership problem, not a ticketing problem.

In practice, orphaned access becomes dangerous because directory disablement is often treated as the finish line. It is not. Applications with local accounts, cached tokens, delegated access, or embedded secrets can continue operating long after a human identity is removed. The risk is especially high in systems that also carry non-human identities, where persistent credentials and service accounts can outlive the user who created them. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why leaver controls fail so often in real environments. See the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10 for the wider identity risk pattern.

In practice, many security teams discover this only after a former employee still has usable access during an audit, incident, or post-termination review, rather than through intentional control testing.

How It Works in Practice

The accountable party is typically the team that owns identity lifecycle integration across the directory, SSO, provisioning layer, and application onboarding process. That team is responsible for ensuring the leaver event reaches every downstream system that grants or caches access. The directory can disable the user correctly and still leave access intact if the app is not integrated for deprovisioning, token revocation, or local account suspension.

Operationally, strong leaver control requires more than account disablement. It requires policy, workflow, and technical enforcement across all identity types. For human users, that means terminating sessions, revoking refresh tokens, removing group membership, and closing app-local accounts. For services and automation, it also means validating whether the application uses NHI controls such as short-lived credentials, rotation, and explicit ownership. Guidance from the OWASP Non-Human Identity Top 10 aligns with this by treating stale credentials and weak lifecycle controls as a primary exposure path.

A practical control model usually includes:

• authoritative source mapping so each app has a named owner and a deprovisioning path
• event-driven offboarding that triggers revocation when directory status changes
• periodic access recertification to catch applications that do not support automated termination
• token and secret revocation for any application that uses cached or embedded credentials

For broader lifecycle and offboarding context, the 52 NHI Breaches Analysis shows how frequently stale identity paths become exploitable, especially when access is not tied to a clean owner and revocation workflow. These controls tend to break down when applications are unmanaged, acquired through shadow IT, or built without SCIM, API-based deprovisioning, or a reliable session revocation mechanism because directory changes never reach the application.

Common Variations and Edge Cases

Tighter offboarding control often increases operational overhead, requiring organisations to balance fast termination against legacy application constraints and business continuity. Not every application supports real-time deprovisioning, and current guidance suggests treating those systems as exceptions that need compensating controls rather than as proof that leaver control is complete.

There are a few common edge cases. Shared accounts blur accountability because no single user lifecycle event maps cleanly to the access that remains. Service accounts are even trickier, because a departing user may not own the account anymore, but may still know the secret or control the automation that uses it. In those cases, the accountability shifts to the application owner, IAM team, and platform owner together, with the business system owner responsible for ensuring the access path is closed. That is why NHI governance and human offboarding must be evaluated together, not as separate programs. The Ultimate Guide to NHIs, Key Challenges and Risks is useful for understanding why lifecycle failures persist even when directory controls look sound.

There is no universal standard for this yet, but best practice is evolving toward explicit ownership, automated revocation, and exception tracking for apps that cannot consume lifecycle events. Where that is missing, the answer is usually not “the directory team failed” or “the app team failed” alone. It is that the organisation failed to assign and verify end-to-end accountability for access removal.

Related resources from NHI Mgmt Group

• Who is accountable when access is left active after a role change or departure?
• Who is accountable when access remains active after a mass exodus?
• What should organisations do after a user access review finds exceptions?
• Who is accountable when revoked sessions keep working after access should end?