Disabling a leaver's directory account does not end their access: refresh tokens, app sessions, local SaaS logins, personal access tokens, shared passwords and the API keys they created can all keep working after the last day. This template is a per-leaver checklist that an IT or identity team can run on the day of departure and again after it, with a named owner and evidence for each line. It covers the trigger and preparation, the identity provider, SaaS outside single sign-on, devices, privileged and shared credentials, tokens and API keys the person created, data and mailbox handling, and the post-exit checks at 7 and 30 days. It is written for IT administrators, identity engineers and the HR and line managers who start the process. For the reasoning behind the sequence and platform detail, read the Employee Offboarding Security Guide; this page is the record you fill in.
How to use this template
- Create one copy per leaver, linked to the HR ticket. Replace text in square brackets, such as [Organisation], [leaver name], [IdP] and [SIEM], with your own details.
- Each line has an owner role and a deadline relative to the leaving time (T). "T" is the moment employment or contract access ends, agreed with HR. For a hostile or involuntary exit, T is the moment the person is told, and sections 3 to 6 run while that conversation is happening.
- Mark each line Done (with time and evidence), Not applicable (with a reason, for example "no GitHub account found") or Exception (with the approver). A blank line is a fail.
- The checklist follows NIST SP 800-53 PS-4 Personnel Termination: disable access within a defined time, revoke authenticators and credentials, retrieve property and keep access to the information the person controlled.
- Movers (internal transfers) use sections 3, 6 and 9 to remove access the new role does not need; see the Joiner-Mover-Leaver Guide.
1. Leaver record
| Field | Value |
|---|---|
| Leaver, role, department | [leaver name], [role], [department] |
| Type of exit | [voluntary / involuntary / contractor end / retirement]; risk rating [standard / elevated] |
| Leaving time (T) | [date and time, time zone] |
| Manager and data owner after exit | [manager], [person receiving mailbox and files] |
| Privileged roles held | [admin roles, PAM entitlements, cloud roles, break-glass knowledge] |
| Ticket and checklist owner | [ticket ID], [IT owner] |
2. Before the last day (T minus 5 working days)
| Check | Owner | Done |
|---|---|---|
| HR has sent the leaver event to IT through the agreed channel, ideally the HR system feeding the identity provider automatically. | HR | [ ] |
| An access inventory is pulled for the person: IdP app assignments and groups, privileged roles, SaaS accounts found by email address in each admin console, cloud accounts, code platform memberships, and vault or password manager shares. | IT | [ ] |
| Non-human identities the person owns are listed: service accounts, API keys, OAuth apps they registered, automation and bots, scheduled jobs running under their account. New owners are named for each. | IT, manager | [ ] |
| Shared secrets the person knew are listed for rotation: team vault entries, shared admin passwords, Wi-Fi keys, door codes, break-glass credentials. | Security | [ ] |
| Handover of files, mailboxes, calendars and project ownership is agreed with the manager. | Manager | [ ] |
| Elevated risk exits: monitoring for unusual downloads, forwarding rules and mass sharing is turned on for the notice period, with legal and HR approval. See the Insider Data Theft Guide. | Security | [ ] |
3. Identity provider and directory (at T)
| Check | Owner | Done |
|---|---|---|
| Account disabled in the IdP (Microsoft Entra: clear Account enabled; Okta: deactivate or suspend; Google Workspace: suspend). Disable rather than delete on day one, so data and audit history stay available. | IT | [ ] |
| Hybrid directories: account disabled in on-premises Active Directory too, and the password reset (Microsoft's guidance resets it twice to limit pass-the-hash where replication may lag). | IT | [ ] |
| Sessions and refresh tokens revoked: Entra Revoke sessions; Google Workspace sign-in cookies reset. Disabling alone does not end an access token already issued, which by default lasts an hour in Entra. | IT | [ ] |
| MFA methods, security keys, passkeys and app passwords removed, and recovery email and phone removed from the account. | IT | [ ] |
| OAuth grants the user made to third-party apps reviewed and revoked (Google lists this as a separate step, because a password change revokes only some tokens). | IT | [ ] |
| Registered devices disabled in the directory. | IT | [ ] |
| Group memberships and privileged role assignments removed, including eligible (just-in-time) roles that are not active. | IT | [ ] |
| VPN, remote access and certificate-based access revoked, including any user certificates issued to the person. | Network | [ ] |
4. SaaS and applications outside single sign-on (by T plus 4 hours)
Disabling the IdP account stops new SSO sign-ins. It does not end an application's own session, and it does nothing for accounts with a local password. Microsoft notes that the IdP cannot revoke a session token an application issued itself, and that automatic deprovisioning (Entra app provisioning typically runs every 20 to 40 minutes) is the effective fix. See SaaS Deprovisioning Guide.
| Check | Owner | Done |
|---|---|---|
| SCIM-provisioned apps show the account deactivated; failures in the provisioning log are fixed by hand. | IT | [ ] |
| Apps without SCIM: each app owner removes or deactivates the account and ends active sessions, from the list in section 2. | App owners | [ ] |
| Accounts with local passwords or social logins (signed up outside SSO) found by searching admin consoles for the person's email, and removed. | IT | [ ] |
| Code platforms: removed from GitHub, GitLab or Bitbucket organisations. GitHub notes removed members may keep local copies and may keep access through forks held in other organisations. | Engineering | [ ] |
| Cloud consoles: IAM users, access keys and role bindings for the person removed in each AWS account, Azure subscription and Google Cloud project. | Cloud team | [ ] |
| Licences reclaimed after accounts are removed. | IT | [ ] |
5. Tokens, API keys and non-human identities (by T plus 1 day)
| Credential type | Where to look | Action | Done |
|---|---|---|---|
| Personal access tokens | GitHub and GitLab organisation token lists, Atlassian, cloud provider consoles | Revoke; replace automation that used them with an app or service identity | [ ] |
| Personal API keys | SaaS admin consoles (CRM, monitoring, email delivery, payment), key lists filtered by creator | Revoke, or rotate and reassign where systems depend on them | [ ] |
| OAuth apps and integrations they registered | IdP app registrations, Slack and Google Workspace app lists | Reassign owner or remove | [ ] |
| Service accounts and bots they owned | NHI inventory, IdP, cloud IAM | New owner recorded; credentials rotated | [ ] |
| SSH keys and deploy keys | Code platforms, servers' authorised keys, bastion hosts | Remove | [ ] |
| Scheduled jobs and scripts under their account | Schedulers, CI pipelines, automation tools | Move to a service identity before the account is deleted | [ ] |
OWASP lists improper offboarding as NHI1 in its Non-Human Identities Top 10. See the NHI Offboarding and Decommissioning Guide.
6. Privileged and shared credentials (by T plus 1 day)
| Check | Owner | Done |
|---|---|---|
| PAM accounts and vault access removed; check-outs in progress ended. | Security | [ ] |
| Shared credentials the person could see in team vaults or password manager shares are rotated, starting with admin and production credentials. | Credential owners | [ ] |
| Break-glass credentials rotated if the person held or knew them. | Security | [ ] |
| Domain registrar, DNS, certificate authority and payment accounts checked for the person as a contact or admin. | IT, finance | [ ] |
| Physical access badges deactivated and door codes changed where they were shared. | Facilities | [ ] |
7. Devices and data (at T)
| Check | Owner | Done |
|---|---|---|
| Company laptop, phone, security keys and other property returned and logged against the asset register. | IT | [ ] |
| Devices not returned are locked or wiped remotely. Personal devices: selective wipe of corporate data from managed apps. Microsoft notes wiped data cannot be recovered, so confirm a legal hold is not needed first. | IT | [ ] |
| Mailbox converted to a shared mailbox or delegated to [data owner] with an auto-reply; forwarding rules the person set are removed. | IT | [ ] |
| Files and drive ownership transferred to [data owner] before any deletion; externally shared links reviewed. | IT, manager | [ ] |
| Legal hold applied where litigation, investigation or retention rules require it. | Legal | [ ] |
8. After the exit (T plus 7 and T plus 30 days)
| Check | When | Done |
|---|---|---|
| IdP and [SIEM] show no successful sign-ins, token use or API calls by the person's accounts or by keys they created. | T+7 | [ ] |
| Failed sign-in attempts against the disabled account are reviewed; repeated attempts go to the security team. | T+7 | [ ] |
| A second search of SaaS admin consoles and the SaaS discovery tool finds no remaining account under the person's email. | T+7 | [ ] |
| Data transfer is complete and the account is deleted or held according to the retention policy. | T+30 | [ ] |
| The next access review confirms no entitlements remain. See the Access Review Checklist. | Next review | [ ] |
9. Sign-off
Checklist owner: [name], [date]. Exceptions: [number], approved by [name]. Lines not applicable: [number], with reasons recorded.
Implementation guidance
Automate the trigger first: most missed offboardings start with IT not hearing about the leaver. Connect the HR system to the IdP so termination disables the account at T, then use SCIM and lifecycle workflows to push deactivation to applications. Keep this checklist for what automation cannot see: local accounts, tokens, shared secrets and devices. See the SCIM Provisioning Guide.
Small and large organisations: a small business without an IdP can still run sections 2 to 8 by hand from a list of every app and who has an account; the risk is in apps nobody remembered. Large organisations should measure each step, since dozens of leavers a week make manual steps the bottleneck.
Rollback: if the wrong person is disabled or a date was wrong, re-enable the IdP account, re-assign groups from the access inventory in section 2, and record the incident. Disable before delete makes this possible; deletion often cannot be undone.
Metrics: time from T to IdP disable (target under [1] hour); percentage of leavers with all sections complete within [24] hours; accounts found at T+7 that should have been removed (target 0); tokens or keys used after T (target 0); shared credentials rotated within [1] day of a privileged leaver.
Common failures: disabling the account but not revoking sessions; apps with local passwords never found; a leaver's personal access token running a production pipeline, so revoking it breaks a build and someone re-enables it; shared admin passwords never rotated; contractors offboarded by nobody because HR does not own them; and mailbox forwarding to a personal address left in place.
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK |
|---|---|---|---|
| Disable access, revoke credentials (3 to 6) | PS-4, AC-2(3), IA-5 | PR.AA-01 | T1078 Valid Accounts |
| Remove entitlements and roles (3, 6) | AC-2, AC-6 | PR.AA-05 | T1098 Account Manipulation |
| Movers | PS-5 | PR.AA-05 | |
| Property and data (7) | PS-4 | PR.AA-01 |
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (PS-4, AC-2)
- OWASP: Non-Human Identities Top 10, NHI1 Improper Offboarding
- Microsoft Learn: Revoke user access in Microsoft Entra ID
- Google Workspace: Maintain data security after an employee leaves
- GitHub Docs: Removing a member from your organization
Related NHI Mgmt Group resources: Employee Offboarding Security Guide · Joiner-Mover-Leaver Guide · SaaS Deprovisioning Guide · OWASP NHI Top 10 NHI1 Improper Offboarding Guide · NHI Offboarding and Decommissioning Guide