User offboarding removes the person from the directory or workforce system. Revoking delegated access removes the tokens, grants, sessions, and machine credentials that can keep working after the person is gone. In practice, both are required because a valid delegation can outlive the human identity that created it.
What changes when a person leaves versus when their delegated access must be cut off?
Offboarding is about removing the person from the workforce or directory lifecycle. Revoking delegated access is about removing the permissions, tokens, sessions, API grants, and machine credentials that still act on that person’s behalf. The difference matters because an account can be gone while delegation still works, which leaves an active path into systems, data, or automation.
In practice, offboarding answers “should this person still have an account?” while delegated-access revocation answers “can anything still authenticate or act because of that person’s prior approval?” Those are related, but not the same control. A clean personnel exit can still leave behind OAuth grants, long-lived tokens, shared sessions, app consents, service credentials, or agent access that outlives the human record.
Why delegated access survives the user record
Delegated access is a separate authority relationship, not just a user row in a directory. It is commonly expressed through token exchange, consent grants, refresh tokens, service principals, workload credentials, or other standing permissions that continue until they expire or are explicitly revoked. That is why a person can be fully offboarded and still indirectly retain access through a third-party app or automation path.
For that reason, the right mental model is to trace the authority chain, not only the identity record. NHIMG’s Joiner-Mover-Leaver (JML) Guide is useful here because it treats offboarding as lifecycle closure, including the tokens, keys, and agents that leavers leave behind. The same distinction appears in RFC 8693: OAuth 2.0 Token Exchange, which formalizes delegation and impersonation flows that can continue independently of the original user session.
In operational terms, offboarding usually removes interactive human access first, while delegated-access revocation removes non-interactive access paths that may never show up as a normal login. That includes consented app access, bearer tokens, refresh tokens, background integrations, and any machine credentials tied to the person’s approval history.
What practitioners should verify during a clean separation
Offboarding is complete only when the person is gone and the access they enabled is also gone. IAM and IGA Basics is a good reference for the control boundary between identity lifecycle, authorization, and entitlement cleanup, while the Guide to the Secret Sprawl Challenge is relevant when delegated access is carried by exposed secrets rather than an interactive account.
Practitioners should verify four things: the directory record is disabled or removed, all active sessions are invalidated, every delegation grant has been reviewed, and any machine credential or secret that could still authorize action has been rotated or revoked. If a token, API key, certificate, or app consent can still work after the person exits, the offboarding task is not finished.
This is why lifecycle and rotation controls matter together. NHI Lifecycle Management Guide and OAuth 2.0 Token Exchange both reinforce the same practitioner lesson: removal of the human record does not automatically invalidate the authority that the human delegated earlier.
Risk and Threat Considerations
The main risk is residual access. If delegated authority is not revoked, a departed user can still be represented by tokens, sessions, app grants, or service credentials long after the offboarding ticket closes. That creates a hidden persistence path for unauthorized access, abuse, or lateral movement.
Failure mechanism: Offboarding terminates the human account, but the delegated credential, consent, or session remains valid and continues to authorize requests. An attacker, former employee, or compromised integration can keep using that standing authority until it expires or is revoked.
Impact: Data access, transactions, automation, or administrative actions can continue under an apparently closed user lifecycle. In some environments, this produces a delayed compromise signal because the access looks legitimate even after the person has left.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address 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 | Covers lifecycle revocation and rotation of credentials and tokens. |
| AC-2 — Account Management | Offboarding is account termination and disabling of access. | |
| AC-6 — Least Privilege | Delegated access should be limited and removed when no longer needed. | |
| Recommendation — Revoke, rotate, and expire authenticators when access ends. Disable and remove accounts through controlled lifecycle steps. Limit delegated rights to the minimum necessary and remove stale grants. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Delegated tokens and sessions can remain valid after user departure. |
| Recommendation — Invalidate tokens and sessions when the delegating user leaves. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Directly covers leaving behind non-human access after offboarding. |
| Recommendation — Remove all standing non-human access when the owner departs. | ||
Practitioner Guidance
What to prioritise: Treat delegated-access revocation as a mandatory offboarding workstream, not a follow-up task. The first priority is to inventory every place the departing person could have granted authority, including SSO consents, OAuth grants, API tokens, shared sessions, and machine credentials.
What to verify: Confirm that revocation actually breaks access, not just the directory record. If the person’s exit process does not produce evidence of token invalidation, session termination, and secret rotation, assume some access path may still exist.
Common mistake: Teams often equate deprovisioning with complete removal. That is safe only for direct interactive access; delegated and non-human access frequently needs separate cleanup and sometimes separate ownership.
Practitioner takeaway: Offboarding ends the person’s identity lifecycle, but delegated-access revocation ends the authority they left behind, and both must be validated before the exit is considered secure.
Related resources from NHI Mgmt Group
- What is the difference between rotating a secret and revoking access?
- What is the difference between offboarding a user and revoking NHI access?
- What is the difference between disabling a user in the IdP and fully offboarding access?
- What is the difference between delegated user access and machine authority for AI agents?