The assumption that account disablement equals access removal breaks down. The user can no longer sign in through the IdP, but the downstream app may still trust existing OAuth grants, refresh tokens, or cached sessions. That creates phantom access, where the identity looks gone in the directory but still has usable access in the application layer.
Why this creates phantom access
Disabling the IdP account only removes one path to authentication. If the application still accepts previously issued OAuth grants, refresh tokens, or cached sessions, access can continue until those artefacts expire or are revoked. The real control boundary is therefore not “directory status” alone, but the full token and session lifecycle across the IdP, authorization server, and relying application.
That is why this failure often surprises teams: the directory looks clean, but the app layer still treats the principal as trusted. In practice, the leftover grant becomes a standing exception unless the downstream system actively rechecks account state or receives a revocation signal.
Where revocation breaks down in OAuth flows
The gap usually appears in long-lived delegated access paths. A refresh token can mint new access tokens without the user reauthenticating, and an active browser session can keep working even after the directory account is disabled. OAuth itself defines the grant and token model in RFC 6749: The OAuth 2.0 Authorization Framework, but whether disablement immediately ends access depends on how the app and authorization server implement revocation, session invalidation, and token introspection.
When that lifecycle is weak, the app is effectively making an authorization decision on stale trust. The user is no longer an active signer-in through the IdP, yet the previously delegated permission remains usable until something else tears it down. That is the exact condition that creates phantom access.
What security teams should treat as the failure point
The control failure is not just missing account disablement, it is missing propagation of disablement into every downstream trust artefact. Teams need to think in terms of token revocation, session invalidation, consent removal, and scope reduction, not only account lockout. The strongest practical reference point is the OAuth security guidance in RFC 9700: Best Current Practice for OAuth 2.0 Security, which emphasises limiting token abuse and tightening token handling.
For practitioner context, SaaS-to-SaaS and OAuth App Governance Guide is useful because it addresses consent, scopes, refresh tokens, and revocation runbooks. If your operational model only retires the directory account, you have not actually retired the access path that matters.
Risk and Threat Considerations
This creates a real exposure window because access can outlive the account that supposedly owned it. An attacker, insider, or simply a stale integration can continue using the still-valid grant to read data, call APIs, or perform actions after disablement has occurred in the IdP.
Failure mechanism: downstream applications trust previously issued OAuth artefacts more than current directory state, so disablement does not immediately invalidate refresh tokens, active sessions, or consented scopes.
Impact: access persists after offboarding or account disablement, which can produce unauthorized data access, delayed containment, and misleading assurance during incident response.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Refresh tokens and session artefacts are authenticator material that must be revoked or expired. |
| IA-9 — Service Identification and Authentication | OAuth grants and token-based app access depend on service-to-service authentication trust. | |
| AC-2 — Account Management | Account disablement must propagate to dependent access paths and lifecycle events. | |
| Recommendation — Revoke or expire refresh tokens and related authenticators when the account is disabled. Enforce token revocation and revalidation for authenticated app-to-app access paths. Tie account disablement to downstream access removal and periodic access review. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Disabled identities can retain access when grants and secrets are not removed. |
| NHI-07 — Long-Lived Secrets | Refresh tokens and similar artefacts can preserve access long after disablement. | |
| NHI-05 — Overprivileged NHI | Residual grants often keep more access than the disabled account should retain. | |
| Recommendation — Build offboarding steps that remove grants, sessions, and credentials together. Shorten token lifetimes and rotate or revoke long-lived credentials promptly. Review scopes and reduce residual privilege before relying on disablement. | ||
Practitioner Guidance
What to verify: Confirm whether the application, authorization server, and directory are coupled through a real revocation path, not just through initial login. If disablement does not revoke refresh tokens and sessions, treat the control as incomplete.
Decision rule: If the user can still act through a live grant after IdP disablement, prioritise consent revocation, token invalidation, and session termination before assuming the offboarding is complete.
What good looks like: A disabled account should lose both interactive sign-in and previously delegated app access within a defined and tested time window, with evidence of revocation available for review.
Practitioner takeaway: Identity disablement is only half the job; access is not really removed until the application stops trusting the old grant.
Related resources from NHI Mgmt Group
- What breaks when an acquired vendor’s OAuth tokens remain active?
- How should security teams respond when a connected vendor or SaaS integration is breached and OAuth grants may still be active?
- What breaks when OAuth 2.0 still depends on implicit or password grants?
- What are the implications of using OAuth tokens in third-party integrations?
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