Disabling a leaver's directory account does not end their access: sessions, refresh tokens, app passwords, local SaaS accounts, personal access tokens and the keys they created or saw keep working until someone revokes each one. CISA defines an insider as anyone who has or had authorised access to an organisation's resources, so former staff stay in scope. This guide sets out a complete, ordered offboarding for employees and contractors: the trigger from HR, what to revoke and in what order, platform specifics for Entra ID, Active Directory, Google Workspace and Okta, the accounts and NHIs that sit outside the identity provider, and how to measure offboarding lag. It is written for IAM, IT operations and security teams, and for the HR and line managers whose timing decides whether the process works. The machine identities a leaver owns are retired using the NHI Offboarding and Decommissioning Guide.
Key takeaways
- Revoke sessions, not just the account. In Entra ID an access token stays valid for up to an hour by default after the account is disabled, and app session cookies are controlled by each application.
- The identity provider only covers what is federated. Local SaaS accounts, code platforms, package registries, cloud root users and shared admin credentials need their own steps.
- A leaver's NHIs are part of their offboarding. API keys, PATs, OAuth apps and signing keys the person created, owned or could read must be transferred and rotated, or retired.
- Timing is set by HR, not IT. An automated feed from the HR system with a defined SLA (for example, access removed by the end of the last working day, immediately for hostile exits) matters more than any tool.
- Measure lag and parity. Track time from HR termination to last credential revoked, and compare contractor and vendor offboarding against employees.
Why offboarding fails
Offboarding gaps come from the same few causes in almost every organisation.
| Gap | What is left behind | Root cause |
|---|---|---|
| Late trigger | Full access for days or weeks after leaving | HR record updated after the last day; manual ticket |
| Session survival | Browser sessions, refresh tokens, mobile app sessions | Account disabled but sessions not revoked; apps that keep their own cookies |
| Non-federated accounts | Local logins in SaaS, GitHub personal accounts in the organisation, npm maintainers, cloud IAM users | Applications not behind SSO or SCIM |
| Personal credentials | PATs, SSH keys, API keys, app passwords, OAuth consents to third-party apps | Created by the user, invisible to the IdP |
| Shared and exposed secrets | Admin passwords, break-glass credentials, signing keys the leaver could read | No record of who saw what |
| Data and mail paths | Mail forwarding rules, delegated mailboxes, shared drive links, private repository forks | Data access not treated as access |
| Contractor and vendor parity | Accounts of agency staff and supplier engineers | No HR record; sponsor not notified |
The Coupang breach is the costliest recent example of the "exposed secrets" gap. A developer who had worked on the authentication system left at the end of 2024 with a token signing key that was never revoked or rotated, and used it to forge access tokens; the Korean government confirmed 33.67 million records exposed and the PIPC fined Coupang 624.7 billion won. See the Coupang Breach 2025.
The trigger: HR, sponsors and SLAs
- Authoritative source: drive leavers from the HR system into the identity provider or IGA platform automatically. NIST SP 800-53 PS-4 Personnel Termination requires disabling system access within an organisation-defined time, revoking authenticators and credentials associated with the individual, and retrieving organisational property. See the Joiner-Mover-Leaver Guide.
- Exit categories: define at least two. A standard exit removes access at the end of the last working day. A high-risk or hostile exit (dismissal, privileged administrator, access to signing keys or production) removes access before or during the conversation that informs the person.
- Movers count: PS-5 Personnel Transfer covers people who change role. Removing old access on transfer prevents the accumulation that makes a later leaver dangerous.
- Contractors and suppliers: PS-7 External Personnel Security expects providers to notify you of transfers and terminations. Every non-employee account needs a sponsor and an end date, enforced by expiry. See the Third-Party Access Guide.
- SLA: publish one per exit category and per system tier, and measure against it.
The revocation sequence
Order matters: block new sign-ins first, then kill existing sessions, then deal with credentials the person holds outside the IdP, then data and devices.
- Disable the primary account. In hybrid environments disable in Active Directory first, then act in Entra ID, as Microsoft advises, because changes must sync.
- Reset the password. Microsoft suggests resetting an AD password twice with random values when compromise is suspected, to reduce pass-the-hash risk if replication is delayed.
- Revoke sessions and refresh tokens at the IdP and in each major application that keeps its own sessions.
- Remove MFA methods and recovery options (authenticator registrations, security keys, recovery email and phone) so the account cannot be recovered by the leaver.
- Revoke personal credentials: app passwords, PATs, SSH keys, API keys and OAuth grants to third-party apps.
- Rotate shared and exposed secrets the person could read: shared admin accounts, break-glass passwords, vault paths they had access to, signing keys. See the Break-Glass Account Guide.
- Transfer or retire owned NHIs and reassign ownership of applications, groups and service principals.
- Handle mail and data: remove forwarding rules and delegations, transfer files, revoke external sharing links, set an auto-reply or convert the mailbox under the retention policy.
- Devices: recover, wipe or selectively wipe managed devices; disable device objects.
- Delete or keep disabled according to retention rules, then confirm with a post-offboarding scan.
Testing and rollback: pilot the automated flow on a test identity with accounts in every connected application, and verify each step from the application side, not just from the IdP log. Keep accounts disabled rather than deleted for a defined period (for example 30 days) so a wrongly processed leaver can be restored with history intact; Okta, for example, requires deactivation before deletion and deletion cannot be undone.
Platform specifics
| Platform | Steps | Caveats from vendor documentation |
|---|---|---|
| Active Directory | Disable-ADAccount, then reset the password (twice if compromise is suspected) | Disable on premises before acting in Entra ID in hybrid setups |
| Microsoft Entra ID | Clear Account enabled (or Update-MgUser -AccountEnabled:$false), then Revoke sessions (Revoke-MgUserSignInSession), then disable registered devices | Access tokens last up to one hour by default unless the resource supports Continuous Access Evaluation; Entra cannot revoke app-issued session cookies; app provisioning runs about every 20 to 40 minutes. Disabling an admin needs Privileged Authentication Administrator |
| Google Workspace | Wipe mobile devices, remove recovery email and phone, change password, revoke OAuth 2.0 tokens, reset sign-in cookies, revoke security keys and app passwords, transfer data, delete the account | A password change revokes some OAuth tokens, but authorised apps should still be reviewed and revoked |
| Okta | Deactivate the user (suspend is for temporary holds) | Suspension keeps app assignments and roles; deactivation revokes assignments and admin roles and deprovisions apps only where deprovisioning is enabled per app; it runs as a background task |
| GitHub organisation | Remove the member, remove from the IdP app and SCIM groups, review fine-grained PATs and SSH keys | Former members may keep local clones; membership data is kept three months for reinstatement; owners cannot review classic PATs |
See the Entra ID Security Guide, the Okta Security Hardening Guide and the Token and Session Security Guide.
SaaS, cloud and code platforms outside the IdP
SCIM deprovisioning removes accounts where the application supports it, but does not remove tokens, API keys and sessions a user created. See the SCIM Provisioning Guide.
- SaaS with local logins: keep a register of applications not behind SSO, and assign each an owner responsible for removing leavers within the SLA. SaaS posture tools can report accounts that no longer map to an active employee. See the SaaS Security Guide.
- OAuth consents: third-party apps a leaver authorised may hold refresh tokens to company data. Review and revoke grants for the user. See the SaaS and OAuth App Governance Guide.
- Cloud consoles: remove IAM users and access keys in AWS, personal roles in Google Cloud and Azure role assignments; check that the leaver held no cloud account root or billing contact role.
- Code and package platforms: remove GitHub, GitLab and Bitbucket organisation membership, deploy keys the person added, and maintainer rights on npm, PyPI and container registries. The Mastra npm attack used a former contributor's account whose scope access was never revoked. See the Mastra npm Supply Chain Attack 2026.
- DNS and domains: check registrar, DNS hosting and certificate authority accounts, which are often held in an individual's name; transfer them to role accounts.
- Personal AI tools: AI assistants and agents the person connected to company mail, drives or code with their own credentials need their grants revoked. See the Shadow AI Discovery Guide.
Where identity fits: the NHIs a leaver owns
OWASP's NHI1:2025 Improper Offboarding names "partially offboarded employees" as a core scenario: an administrator or developer who saw an NHI's credentials leaves without them being revoked. Its guidance is to review all NHIs linked to a departing employee, decommission those no longer needed, transfer ownership of the rest and rotate any credential the person could access.
| NHI type | Leaver action |
|---|---|
| Service accounts and service principals they own | Assign a new owner before the last day; rotate secrets |
| API keys and PATs they created | Revoke; reissue under a team or workload identity if still needed |
| Shared secrets they could read | Rotate, prioritising production and signing keys |
| OAuth apps and integrations they registered | Transfer ownership or retire; check the consenting user |
| Automation running as their user account | Migrate to a service identity; scripts and flows break when the account is disabled |
The Klue incident shows what happens when an integration credential outlives its purpose: a GitHub token from an abandoned 2022 pilot stayed active for about four years and was used in June 2026 to steal customers' Salesforce OAuth tokens. See the Klue OAuth Breach 2026. The full retirement process is in the NHI Offboarding and Decommissioning Guide.
Email, data and devices
- Mail forwarding: check for inbox and transport rules forwarding to external addresses before and after the exit; attackers and leavers both use them (ATT&CK T1114.003 Email Forwarding Rule). See the Email Security Guide.
- Delegations: remove mailbox delegates and calendar delegates in both directions.
- Files: transfer ownership of documents before deletion and revoke "anyone with the link" shares the user created.
- Private forks and clones: GitHub notes that former members may keep local copies; the organisation is responsible for making sure confidential information is deleted, which means exit attestations and DLP monitoring during the notice period. See the Data Loss Prevention (DLP) Guide.
- Devices: Microsoft notes that an Intune wipe needs the device to be online; recover devices physically for high-risk exits, and disable device objects so a retained laptop cannot get new tokens. See the Lost or Stolen Device Response Checklist.
Small and large organisations
Small organisations usually have one IdP and a few dozen SaaS apps. A written checklist owned by one person, SSO enforced wherever the plan allows, and a password manager for shared credentials (so rotation lists are known) cover most of the risk. Large organisations need the HR feed into IGA, SCIM for every app that supports it, a disconnected-application process with owners and SLAs, and a weekly reconciliation of every application's accounts against HR. In both, high-risk exits need a pre-agreed runbook so security can act within minutes when HR calls. See the Workforce Identity Security Guide and the Insider Threat and Identity Guide.
Detection and metrics
Alert on any sign-in attempt by a disabled account, any successful API call authenticated by a leaver's token or key, new forwarding rules or bulk downloads during the notice period, and new accounts or credentials created by a leaver in their last weeks (ATT&CK T1136.003 Cloud Account, T1098.001 Additional Cloud Credentials). Use of a former employee's valid credentials maps to T1078 Valid Accounts.
| Metric | What it shows | Target |
|---|---|---|
| Median and 95th percentile time from HR termination to IdP disable | Trigger speed | Within SLA |
| Time from termination to last credential revoked (all systems) | True offboarding lag | Within SLA, falling |
| Accounts in applications with no matching active HR record | Offboarding drift | Zero after each reconciliation |
| Leavers with owned NHIs not transferred or retired by exit date | NHI offboarding gap | Zero |
| Contractor offboarding lag compared with employees | Offboarding parity | Equal |
| Authentication attempts from disabled accounts per month | Missed revocations or misuse | Investigated, falling |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | PS-4 Personnel Termination, PS-5 Personnel Transfer, PS-7 External Personnel Security | Disable access, revoke authenticators, retrieve property, handle movers and contractors |
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, AC-2(3) Disable Accounts, IA-5 Authenticator Management | Account and credential removal |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05 | Identity and credential management; access permissions reviewed with least privilege |
| CIS Controls v8.1 | 6.2 Establish an Access Revoking Process, 5.3 Disable Dormant Accounts | Revocation process and catching what it missed |
| ISO/IEC 27001:2022 Annex A | 5.11 Return of assets, 5.18 Access rights, 6.5 Responsibilities after termination or change of employment | Asset return, access removal, continuing obligations |
| MITRE ATT&CK v20 | T1078 Valid Accounts, T1528 Steal Application Access Token, T1114.003 Email Forwarding Rule | Misuse of retained access |
| MITRE D3FEND | D3-AL Account Locking, D3-CR Credential Revocation | Defensive techniques used in offboarding |
Common failure patterns
- Disabling without revoking sessions: the leaver's browser and mobile sessions keep working until tokens expire or the app ends them.
- Forgetting what the person knew: shared admin passwords and signing keys are not tied to the account; the Coupang signing key stayed valid after its holder left.
- Leaving publish and code rights: registry and code platform access outside the IdP outlives employment, as at Mastra.
- Breaking automation, then re-enabling the account: scripts running as a person stop working, and the quick fix is to re-enable the leaver. Migrate automation to service identities before the exit.
- Treating contractors as an afterthought: no HR record means no trigger, so agency and supplier accounts stay active after the engagement ends unless a sponsor and an expiry date force the issue.
- Forgotten test and legacy accounts: Microsoft's Midnight Blizzard intrusion started with a legacy test tenant account without MFA. See the Microsoft Midnight Blizzard Breach 2024.
Practitioner checklist
- Feed leavers and movers from HR into the IdP or IGA automatically, with SLAs per exit category.
- Run a pre-agreed high-risk exit runbook that removes access before the person is told.
- Disable the account, revoke sessions and refresh tokens, and remove MFA and recovery methods in one flow.
- Keep a register of non-federated applications with owners responsible for leaver removal.
- Revoke PATs, SSH keys, API keys, app passwords and third-party OAuth grants for the user.
- Rotate shared secrets, break-glass credentials and signing keys the leaver could read.
- Transfer ownership of the leaver's NHIs, apps, groups and automation before the last day.
- Remove mail forwarding, delegations and external sharing links; recover or wipe devices.
- Reconcile application accounts against HR weekly and alert on disabled-account sign-in attempts.
- Apply the same process and SLA to contractors and supplier staff through sponsors and expiry dates.
Standards and references
- NIST: SP 800-53 Rev. 5
- OWASP: NHI1:2025 Improper Offboarding
- CISA: Insider Threat Mitigation
- Microsoft Learn: Revoke user access in Microsoft Entra ID
- Google Workspace Admin Help: Maintain data security after an employee leaves
- Okta: Deactivate and delete user accounts
- GitHub Docs: Removing a member from your organization
Related NHI Mgmt Group resources: Joiner-Mover-Leaver Guide · NHI Offboarding and Decommissioning Guide · Access Reviews Guide · Insider Threat Programme Guide · Identity Integration in M&A Guide