Access that continues after an identity has been marked inactive in the directory or IdP. It often survives through OAuth grants, refresh tokens, delegated sessions, or cached SaaS state, creating a mismatch between governance records and actual ability to act.
Expanded Definition
Phantom Access describes a post-offboarding condition in which an identity appears inactive in the directory or IdP but still retains usable access in downstream systems. In NHI programs, this usually shows up through OAuth grants, refresh tokens, delegated sessions, service-to-service trust, or cached SaaS authorisations that were never invalidated. The term is operational rather than formal: definitions vary across vendors, and no single standard governs this yet, but the security concern is consistent. A correct reading of Phantom Access focuses on effective privilege, not just account status, because governance records can say “disabled” while the runtime reality still allows action.
That distinction matters in identity operations, where access control must be evaluated across the full trust chain, including token lifetime, session persistence, and app-specific revocation behaviour. The OWASP OWASP Non-Human Identity Top 10 frames these conditions as a governance and exposure problem, especially when service accounts or application grants outlive their intended lifecycle. The most common misapplication is treating directory deactivation as equivalent to access removal, which occurs when downstream tokens and SaaS permissions are not separately revoked.
Examples and Use Cases
Implementing Phantom Access detection rigorously often introduces more revocation coordination and telemetry dependency, requiring organisations to weigh faster shutdown of access against the operational cost of tracing every downstream grant.
- A service account is disabled in the IdP after a role change, but its OAuth refresh token still lets a SaaS integration continue reading mail or files.
- An engineer leaves a team, the directory entry is marked inactive, yet a delegated session in a workflow platform remains valid until its natural expiration.
- A CI/CD bot is removed from the IAM roster, but cached API credentials in the pipeline keep deploying because the secret was not rotated.
- A SaaS app retains tenant-side consent after offboarding, so the app can still act on behalf of the former identity even though the central record is closed.
These patterns align with NHIMG guidance on lifecycle visibility in the Ultimate Guide to NHIs and with broader identity assurance concepts in OWASP Non-Human Identity Top 10. They often surface after a ticket closes, not when the identity is first disabled. The practical test is simple: if the actor can still complete a privileged transaction, access was never fully removed.
Why It Matters in NHI Security
Phantom Access is a classic control gap because it breaks the assumption that governance state and enforcement state are the same. When that assumption fails, offboarding, incident response, and access reviews become unreliable, especially in environments with many service accounts, app tokens, and federated SaaS permissions. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which makes lingering access a common and persistent exposure. The risk is not limited to compromise; it also creates audit failure, privilege creep, and difficult-to-explain access paths after an identity has supposedly been removed.
For practitioners, the issue is not merely whether an account is disabled, but whether every bearer token, delegated grant, cached session, and application-side trust relationship has been invalidated. That is why the Ultimate Guide to NHIs — Key Challenges and Risks is relevant here, alongside incident pattern analysis in 52 NHI Breaches Analysis. Organisations typically encounter Phantom Access only after a suspected breach, failed audit, or account clean-up reveals that a “disabled” identity could still act, at which point the term becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle and revocation gaps that leave inactive identities still usable. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must be removed across systems, not only in the directory. |
| NIST Zero Trust (SP 800-207) | SCM-3 | Zero Trust requires continuous validation, not trust based on prior identity state. |
Treat inactive-directory identities as untrusted until all sessions and grants are confirmed dead.
