By continuing to baseline and monitor the disabled identity instead of stopping at status change. Look for token use from new locations, delegate paths that were dormant before offboarding, and API activity from credentials that should have been retired. Detection has to follow behaviour, not just account state.
Why phantom access persists after offboarding
Offboarding removes the account record, but it does not automatically remove every usable path that was associated with that person. Phantom access usually appears when a token, delegated approval path, cached session, API credential, or downstream entitlement survives the status change. The practical test is whether activity still occurs through the old trust path, even when the user is marked disabled.
That is why detection needs to look for behaviour that no longer matches the expected lifecycle of the identity. If the old identity still triggers logins, API calls, approvals, or delegated actions after departure, the issue is not just an inactive account, it is an access path that was not fully retired. Teams that watch only for account state will miss that residual reach.
Signals that point to dormant access being used
The strongest indicators are activity patterns that should have stopped at offboarding: token use from a new device or location, API calls from credentials tied to the departed user, or delegated access chains that suddenly reappear after being idle. Those signals matter because they show that the trust relationship is still live somewhere in the stack, even if the human account is gone.
Useful hunting usually starts with the highest-value artefacts first. Review identity provider logs, API gateway logs, privileged approval trails, and any record of persistent tokens or refresh tokens that could outlive a password reset. When the user is gone but the behaviour remains, you are looking at a control gap in revocation, not a simple login anomaly.
How to confirm it is phantom access, not normal residual noise
Confirmation comes from correlation, not from a single alert. Compare the post-offboarding activity with the pre-offboarding baseline for the same identity, then ask whether the actions are consistent with any current business process. If a disabled identity is still initiating access to production, using an old API scope, or exercising a delegate path that no current owner should need, treat that as active residual access until disproven.
The most reliable checks are lifecycle checks: was the credential actually retired, was the token family invalidated, was delegation removed, and were downstream entitlements revoked everywhere they were copied? If the answer is uncertain in any of those places, the monitoring hypothesis should stay open. The right question is not “is the account disabled?” but “can anything still act as that identity?”
Risk and Threat Considerations
Phantom access is risky because it creates a false sense of closure after offboarding. A departed user may still be able to reach systems through surviving tokens, delegated access, or unreleased API credentials, which means the environment can remain exposed long after the HR record says otherwise.
Failure mechanism: The revocation event only updates the primary account state, while secondary trust artefacts, such as long-lived tokens, cached sessions, delegated permissions, or copied API credentials, remain valid and continue to authenticate or authorize actions.
Impact: An attacker or former insider can continue accessing data and systems through an apparently closed identity path, which extends exposure windows, weakens audit confidence, and can enable persistence, misuse, or lateral movement without obvious account reactivation.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Disabled accounts can still leave residual access paths that AC-2 must govern. |
| IA-5 — Authenticator Management | Phantom access often persists through surviving tokens or credentials covered by IA-5. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Detecting residual access depends on reviewing post-offboarding log activity and anomalies. | |
| Recommendation — Ensure account termination removes or invalidates all associated access paths and follow up on residual activity. Revoke, rotate, or expire authenticators and tokens at offboarding, then verify no reuse remains. Correlate offboarding events with logs to flag any continued use of the retired identity. | ||
| CIS Controls v8 | 5 — Account Management | CIS account management directly addresses removal of access after departure and dormant account exposure. |
| Recommendation — Disable and remove accounts promptly, then verify no dependent access paths remain. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Residual access after a user leaves is the core offboarding failure this control targets. |
| Recommendation — Revoke all non-human access paths during offboarding and confirm the identity cannot act. | ||
Practitioner Guidance
What to verify: Make sure offboarding closes every path that could still act for the departed user, not just the directory object. The practical check is whether tokens, sessions, delegated grants, and downstream API credentials were individually invalidated or expired.
What to measure: Track post-offboarding activity by identity, token family, and delegation path. A useful signal is any successful action after the account disable event, especially from new geographies, new devices, or service endpoints that were not part of the user’s normal pattern.
Common mistake: Teams often declare success once the account is disabled and access review is closed. That approach misses the real failure mode, which is residual behaviour surviving in systems that authenticate or authorize independently of the directory record.
Practitioner takeaway: Treat offboarding as a behaviour-revocation problem, not a status-change problem, and keep monitoring until you can prove that no usable path remains.
Related resources from NHI Mgmt Group
- How should security teams enforce entitlements when user context changes after access is granted?
- What should security teams do after a third-party partner leaves or no longer needs access?
- How should security teams govern SaaS access after login?
- How should security teams handle guest user access in SaaS platforms?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org