The Complete IT Employee Offboarding Checklist: Every Step, Every App, No Orphaned Accounts

A full, grouped IT offboarding checklist covering SSO, non-SCIM apps, OAuth tokens, shared credentials, MDM, license reclamation, and audit evidence - with a copy-ready template.

13 min read · Last updated August 2026

Every employee departure is a security event. The exit interview, the laptop return, the farewell Slack message - none of that matters if the access is still live.

Industry reports show that over 30% of organizations take more than three days to fully revoke all system access after an employee leaves - and some never complete the process at all. A Beyond Identity survey found that 89% of former employees still retain access to at least one application from their previous employer. That's not a policy failure. It's a structural one - and it's exactly what this checklist is designed to fix.

Why Offboarding Is Your Highest-Risk Identity Event

When someone leaves, they carry a digital footprint that spans your entire stack: SSO sessions, cloud app credentials, VPN tokens, API keys, OAuth grants, shared vault entries, and SaaS seats. When not properly revoked, these become orphaned accounts - an open door for insider threats, data leakage, or audit failures.

The problem compounds in SaaS-heavy environments. According to BetterCloud's 2025 State of SaaS report, organizations manage an average of 106 SaaS applications per company. Most of those apps were adopted by individual teams, often outside IT's view. When someone leaves, IT doesn't always know which apps to address - so SaaS offboarding is incomplete by default.

There's also a timing problem. Only 44% of companies ensure that all access rights are revoked within 24 hours of an employee's departure. That gap is where breaches happen. Compromised credentials accounted for 22% of all breach incidents in Verizon's DBIR 2025 data.

The SSO-Only Trap

Many teams believe that disabling an SSO account is the same as revoking access. It isn't. Disabling an SSO account does not terminate existing SaaS sessions or remove app-specific entitlements - API keys, shared passwords, and locally stored tokens survive an IdP disable entirely. SSO revocation removes one authentication path; it does not close the downstream access graph.

OAuth token revocation and unmanaged SaaS apps purchased outside IT are the most commonly overlooked offboarding steps - they sit outside the identity provider's reach and require either manual checklists or an orchestration layer that tracks apps beyond SSO federation. The gap stays invisible until an audit or security incident surfaces it.

This is the long tail problem: the 60-80% of your stack that doesn't support SCIM, isn't federated to your IdP, and won't automatically deprovision when you disable an account in Okta or Entra ID.

Finish offboarding in 30s

The Complete IT Offboarding Checklist

Use this as your operational template. Group each item by phase, assign owners, and capture timestamps for every action.

Phase 1 - Trigger and Timing

The offboarding clock starts the moment HR confirms a departure - not when IT gets around to it.

Connect your HRIS to your IGA platform. A termination event in Workday, BambooHR, or SuccessFactors should automatically trigger the offboarding workflow. Manual handoffs introduce latency, and latency is the vulnerability.
Aim for same-day revocation of sensitive systems. For privileged users, administrators, and anyone with access to financial, health, or customer data, target within the hour. Compliance frameworks are specific: FedRAMP PS-4 sets a 4-hour window; SOC 2 CC6.1 and ISO 27001 Annex A 6.5 treat same-day revocation as the minimum standard.
Flag involuntary terminations separately. For layoffs or terminations for cause, the window is tighter. Cyberhaven's 2024 analysis showed a 720% spike in risky data exfiltration activities just before layoffs are announced. Revoke access before - or simultaneously with - the notification.
Don't wait for the last day. If you know a departure date in advance, pre-stage the workflow so execution is instant.

Phase 2 - Revoke SSO and Every Downstream App

Disable the user's account in your identity provider (Okta, Entra ID, Google Workspace).
Terminate all active SSO sessions - not just future logins.
Work through every app in your stack, not just those federated to SSO. Tag apps by support level: SCIM-enabled, API-enabled, admin-console only, or unsupported. Each category needs a different revocation method.
For non-SCIM apps: use direct admin console access, API calls, or a governed runbook with named owners and a required completion check.
Remove the user from all groups, roles, and permission sets - not just the top-level account.

SSO offboarding only covers the apps federated to your IdP — typically 20–40% of your stack. The remaining apps require separate, explicit revocation. If your offboarding process stops at the IdP, you have a structural gap, not a completed offboard.

Phase 3 - Disable Accounts (Don't Delete Them)

Disable, don't delete. Deleting accounts immediately destroys the audit trail and can break data ownership chains. Disable first; delete after the retention period defined in your policy.
Suspend accounts in every app where the user had direct access - including apps where they may have created a local account outside SSO.
Confirm the account status in each system. A disabled account in the IdP does not guarantee a disabled account in the downstream app.

Phase 4 - Rotate Shared Credentials, API Keys, and Service-Account Secrets

This is the step most offboarding checklists miss - and the one most likely to be exploited afterward.

Identify every shared credential the departing employee could have known: password manager vaults, team credentials, service account passwords, SSH keys, cloud provider access keys.
Rotate all of them. Revoking vault membership alone doesn't close the vulnerability if the employee already knew the password.
Identify every API key, service account, or automation credential the employee created or had access to. Determine whether each is still needed. If yes, transfer ownership and rotate. If no, decommission.
OWASP's Non-Human Identities Top 10 (2025) places Improper Offboarding at position NHI1:2025 - the single highest-ranked risk in the entire framework - defined as inadequate deactivation of service accounts, API keys, OAuth tokens, and certificates when the human who managed them leaves.
The Cloud Security Alliance found that only 20% of organizations have formal processes for offboarding and revoking API keys. If you don't have a process, this is where to start.

Phase 5 - Revoke OAuth Grants, Active Sessions, and Tokens

MFA doesn't stop a live token. Once a token is issued, it functions as a bearer credential - whoever holds it can use it, regardless of whether the underlying account has been disabled.

Enumerate all OAuth grants the user authorized - integrations they connected, third-party apps they approved, automation tools they linked.
Revoke every active OAuth token and refresh token. Refresh tokens can persist indefinitely outside SSO controls.
Terminate all active browser sessions and session cookies.
Check for integrations the user set up on behalf of the team (Zapier workflows, Slack app connections, GitHub Actions tokens) - these survive account disablement and continue running.

The 2025 Salesloft-Drift incident demonstrated how a compromised OAuth token spread across more than 700 companies' data through downstream integrations - MFA never triggered because the authentication moment had already occurred when the integration was originally authorized.

Phase 6 - Reclaim Devices and Trigger MDM Actions

Confirm all company-owned devices are returned or remotely wiped via MDM (Jamf, Intune, Kandji).
For remote employees: initiate remote wipe before or immediately after the final day.
Revoke device certificates and remove the device from your MDM enrollment.
For BYOD: unenroll the device from MDM and confirm that corporate data containers have been wiped.
Revoke VPN certificates and remove the user from VPN groups.

Phase 7 - Reclaim and Reassign SaaS Licenses

Offboarding is also a cost-recovery event. Wasted SaaS licenses from departed employees can account for up to 30% of total SaaS license cost.

Identify every paid seat the departing employee held - including long-tail tools like Figma viewers, Loom Pro, Linear contributors, and Vercel teams that rarely get reclaimed.
Reassign or release each seat immediately. Don't wait for the next renewal cycle.
Note: many SaaS apps continue billing for disabled or suspended accounts as if they were active. Disabling is not the same as releasing the seat - check each vendor's billing model.
A structured offboarding process with prompt license reclamation can reduce SaaS spending by 15-30% annually for mid-sized companies.

Phase 8 - Transfer Data and File Ownership

Transfer ownership of Google Drive, OneDrive, Notion, or Confluence content to the employee's manager or a designated successor.
Reassign GitHub repositories, Figma files, Linear projects, and any other work artifacts where the user was the owner.
Preserve data according to your retention policy - don't delete files until ownership is confirmed and the retention period has passed.
Document what was transferred, to whom, and when.

Phase 9 - Handle Mailbox, Forwarding, and Calendar

Set up an out-of-office auto-reply with the appropriate contact.
Configure mail forwarding to the manager or a shared inbox for the defined retention period.
Reassign calendar events and recurring meetings.
After the retention period, archive or delete the mailbox per your data retention policy.
Remove the user from distribution lists and shared inboxes.

Phase 10 - Capture Evidence for Audit

An offboarding that isn't documented didn't happen - at least not as far as your auditors are concerned.

Log every action taken: who did it, what system was affected, what the outcome was, and when.
Capture timestamps for each revocation step - not just a single "offboarding completed" ticket close.
ISO/IEC 27001, SOC 2, and the NIST Cybersecurity Framework 2.0 all require evidence of timely access revocation; an offboarding ticket containing only an IdP timestamp is generally insufficient under modern auditor expectations.
Store evidence in an immutable, queryable system. Audit logs that can be edited are not audit logs.
Retain evidence for the period required by your applicable frameworks (SOC 2, ISO 27001, GDPR, HIPAA, etc.).

Manual vs. Automated Offboarding

Manual vs. Automated Offboarding: Key Metrics

Manual offboarding breaks at the same points in most stacks: HRIS delays, SCIM coverage gaps, sequencing errors, offline devices, and cross-departmental handoffs that never get logged. Each layer assumes the next system handled the rest - which is how a clean ticket closure turns into a messy audit trail.

BetterCloud's 2025 State of SaaS report found that 33% of IT teams still take more than 24 hours to complete offboarding steps, leaving active sessions and licenses exposed. Companies with automated offboarding processes reduce security incidents by 34%.

Automation doesn't just close the timing gap. It closes the coverage gap - ensuring that every app in the stack, including the non-SCIM long tail, is addressed in the same workflow, with the same evidence standard.

Close security gaps during offboarding

The Contractor and Non-HRIS Worker Problem

Standard JML automation fires on HR system events. Contractors aren't in the HRIS. No termination event ever propagates - so the contractor's access persists indefinitely because nothing automated knows the engagement ended.

This is a structural gap, not a process gap. The tools most teams use weren't built to solve it. Contractors, freelancers, and project-based workers need a separate governed lifecycle: a defined sponsor, an explicit end date, and an offboarding trigger that doesn't depend on an HRIS event.

See our guide to Contractor Onboarding and Offboarding for the full workflow, and The Complete Guide to Joiner-Mover-Leaver for how to build a lifecycle that covers every identity type - human, non-human, and everything in between.

Use This Widget to Estimate Your Offboarding Risk

The Offboarding Checklist Template (Copy-Ready)

Use this as your starting point. Adapt it to your stack, assign owners to each section, and add it to your ITSM or runbook.

EMPLOYEE OFFBOARDING CHECKLIST
Employee: _______________  Last Day: _______________
Initiated by: _______________  Date/Time: _______________

PHASE 1 - TRIGGER & TIMING
[ ] HRIS termination event confirmed
[ ] Offboarding workflow triggered (automated or manual)
[ ] Involuntary termination flag set (if applicable)
[ ] Sensitive-system revocation window confirmed (target: same-day / ≤1 hr for privileged users)

PHASE 2 - SSO & DOWNSTREAM APP REVOCATION
[ ] IdP account disabled (Okta / Entra ID / Google Workspace)
[ ] All active SSO sessions terminated
[ ] SCIM-connected apps deprovisioned (list: _______________)
[ ] Non-SCIM apps revoked via admin console (list: _______________)
[ ] User removed from all groups, roles, and permission sets

PHASE 3 - ACCOUNT DISABLE (NOT DELETE)
[ ] Accounts disabled in all downstream systems
[ ] Local/direct accounts identified and disabled
[ ] Account status confirmed in each system (not assumed)

PHASE 4 - SHARED CREDENTIALS & API KEYS
[ ] Password vault access revoked
[ ] All shared credentials the employee knew - rotated
[ ] API keys created or accessed by employee - inventoried
[ ] API keys still needed - ownership transferred + rotated
[ ] API keys no longer needed - decommissioned
[ ] Service accounts reviewed and ownership transferred

PHASE 5 - OAUTH GRANTS, SESSIONS & TOKENS
[ ] All OAuth grants authorized by the user - enumerated
[ ] OAuth access tokens and refresh tokens - revoked
[ ] Active browser sessions and session cookies - terminated
[ ] Team integrations set up by the user - reviewed and reassigned

PHASE 6 - DEVICES & MDM
[ ] Company devices returned or remote wipe initiated
[ ] Device removed from MDM enrollment
[ ] BYOD corporate data container wiped
[ ] VPN certificates revoked, user removed from VPN groups

PHASE 7 - LICENSE RECLAMATION
[ ] All paid SaaS seats identified (including long-tail apps)
[ ] Seats released or reassigned immediately
[ ] Billing impact confirmed with each vendor

PHASE 8 - DATA & FILE OWNERSHIP
[ ] Drive/cloud file ownership transferred
[ ] Repositories, projects, and work artifacts reassigned
[ ] Data retained per retention policy

PHASE 9 - MAILBOX & CALENDAR
[ ] Out-of-office auto-reply configured
[ ] Mail forwarding set up (to manager or shared inbox)
[ ] Calendar events reassigned
[ ] Distribution list membership removed

PHASE 10 - AUDIT EVIDENCE
[ ] Per-step timestamps logged (who, what, when, outcome)
[ ] Evidence stored in immutable audit log
[ ] Offboarding record retained per compliance framework requirements
[ ] Offboarding confirmed complete by IT owner: _______________

Find unused licenses

What Automated Deprovisioning Actually Looks Like

A well-built offboarding workflow doesn't start with a ticket. It starts with an HRIS event - a termination record in Workday or BambooHR - that automatically triggers a policy-driven sequence: IdP disable, SCIM deprovisioning for federated apps, API-based revocation for non-SCIM apps, OAuth token cleanup, session termination, and license release. Every step is logged with a timestamp and a completion state. The audit trail is immutable and exportable.

That's what Iden does - across your entire stack, including the apps that don't support SCIM or APIs. Not just the 20-40% of apps your SSO covers. All of them.

The Bottom Line

Offboarding is not an HR process with an IT checklist attached. It's a security-critical, access-driven operation that demands precision across every layer of your stack - SSO, downstream apps, OAuth grants, shared credentials, devices, licenses, and audit evidence.

The gap between "we disabled the account" and "access is fully revoked" is where breaches live. Closing that gap requires coverage of every app, not just the ones your IdP knows about - and automation that fires the moment HR confirms a departure, not when IT gets around to it.

Manual checklists are a starting point. Automated, full-stack deprovisioning is the standard.