When should organisations prioritise access revocation over account deletion in offboarding?

Why revocation comes before deletion

Offboarding fails when teams treat directory closure as the finish line. The real question is whether the departing person, or anything they left behind, can still reach data, systems, or delegated access paths. If they can, access revocation is the control that removes the blast radius; deletion is only safe once those paths are gone.

That distinction matters because modern access is rarely held in one place. A person may leave while still retaining SaaS sessions, shared credentials, OAuth grants, API tokens, or other delegated permissions that outlive the account object itself. Revocation targets the active trust relationship, while deletion only removes one identity record.

For teams managing joiner-mover-leaver workflows, the practical goal is to remove old-role access and revoke the tokens, keys and agents that leavers leave behind before any final cleanup. The same principle applies whether the subject is a human account or a non-human access path embedded in workflows and integrations.

What must be revoked before an account can be deleted?

Start with every path that can still authenticate or authorize activity: SaaS application sessions, federated sign-on, delegated OAuth consent, service or shared credentials, API keys, long-lived tokens, and emergency or break-glass access if the departing person knew how to use it. If any of those survive, the directory entry is no longer the main security boundary.

In practice, deletion becomes safe only after the organisation has confirmed three things: no active sessions remain, no alternate credential can still act for the user, and no downstream system uses the deleted account as its source of trust. That last point is often missed in distributed environments, where apps cache permissions or trust external identity providers.

Offboarding therefore needs a full identity lifecycle view, not just a directory action. NHIMG’s lifecycle management guide captures the broader pattern: provision, rotate, revoke, and only then decommission. The same sequence is what makes offboarding reliable in environments where access is spread across multiple platforms.

When deletion can create gaps instead of reducing risk

Deleting an account too early can hide the problem rather than solve it. If a SaaS platform, shared mailbox, OAuth app, or third-party integration still trusts the account, deletion may break visibility while leaving access intact elsewhere. Teams then lose the ability to audit who or what still had authority after the person left.

There is also a governance risk. When the directory record disappears before access is actually removed, ownership questions become harder to answer and recertification evidence becomes weaker. That is why offboarding should be anchored in entitlement removal and credential invalidation first, with deletion treated as a final housekeeping step.

A useful way to think about this is through access governance rather than account lifecycle alone. IAM and IGA basics frame the underlying control correctly: identities are only cleanly offboarded when authorizations, entitlements and trusted connections are removed, not merely when the user object is closed.

Risk and Threat Considerations

Premature deletion can leave a live attack path in place while making it harder to see. If a former user still has a session, shared secret, or delegated grant, an attacker who steals that path can continue accessing company data even after the account object is gone.

Failure mechanism: The organisation deletes the directory account before revoking active access tokens, app consents, or shared credentials, so another trust path continues to function outside the deleted account record.

Impact: Data exposure can persist after offboarding, incident response can miss the remaining access path, and recovery becomes slower because the team has already removed the most obvious identity reference.

Practitioner Guidance

What to verify: Treat offboarding as complete only when you can prove that SaaS sessions, delegated app grants, shared credentials, and cached access paths have been invalidated. If a platform cannot show that revocation occurred, do not rely on account deletion as evidence of control.

Decision rule: If the person ever used SaaS, OAuth-connected apps, shared credentials, or privileged delegation, revoke first and delete later. If the environment is highly distributed, make revocation and confirmation the operational gate for closure, not an optional precursor.

Practitioner takeaway: Deletion is an administrative cleanup action; revocation is the security control. In offboarding, always remove the ability to act before you remove the record that proves who acted.

Related resources from NHI Mgmt Group

• When should organisations prioritise offboarding over new access features?
• When should organisations prioritise access governance over ad hoc account handling?
• When should organisations prioritise NHI revocation over employee account closure?
• When should organisations prioritise access revocation over broader IAM feature upgrades?