The IT Offboarding Checklist for 2026: Every Access, Every App, Every Time

A complete IT offboarding checklist for revoking employee access across SaaS apps, directories, credentials, and devices. 7 phases, every app type covered, including the ones most IT teams miss.

What IT actually needs to do — from the termination call to the signed audit trail — without missing the apps that always get missed.

Direct-answer block:

The IT offboarding checklist covers seven phases: (1) pre-departure preparation once notice is given, (2) directory and IdP suspension on the employee's last day, (3) revocation across API and SCIM-connected SaaS apps on the same day, (4) revocation across browser-only and non-SCIM apps — the ones most teams miss, (5) credential and key cleanup including personal access tokens, SSH keys, and shared passwords, (6) device wipe and endpoint management, and (7) audit trail creation for SOC 2 CC6 compliance. Industry research suggests the median time between an employee's departure and full SaaS access revocation is around 11 days at mid-market companies. A complete IT offboarding checklist, executed the same way every time, closes that gap. Automated HR-driven lifecycle platforms run the full sequence in under 60 seconds.

Why the "employee offboarding checklist" and the "IT offboarding checklist" are two different things

HR owns the exit interview, the laptop return form, the final paycheck timing.

IT owns the access revocation. And those are very different checklists.

The HR offboarding checklist asks: did we get the badge back? Did we process the last paycheck? Did we file the separation paperwork?

The IT offboarding checklist asks: is every credential revoked? Is the GitHub org clean? Did we get the service account passwords out of their 1Password vault? Did the device wipe complete before they walked out?

One missed step on the HR side is a process gap. One missed step on the IT side is a data breach.

This checklist covers the IT side. If you need the full combined list — HR + IT + legal — read the employee offboarding checklist. If you need to move fast right now because someone just handed in their notice, start here.

The 7-phase IT offboarding checklist

Phase 1: Before the last day

Triggered when: notice is given, or HR notifies IT of a pending departure. Do not wait until the last day to start this phase.

1.1 Get the confirmed last-day date in writing from HR. The access revocation clock starts here. Everything in phases 2–6 needs to happen on or before this date. If HR notifies you verbally, reply in writing to create a timestamp.

1.2 Export or transfer everything that needs to survive the account deletion.

• Google Workspace: transfer document ownership via the Admin Console before suspension. Google will not let you recover docs after deletion.
• Microsoft 365 / Entra ID: export or reassign SharePoint files, OneDrive contents, and shared mailbox access before the account is disabled.
• Slack: archive DM threads if legally required. Confirm your data-retention policy covers this.
• GitHub: identify repos where they were the sole owner. Transfer or add a second admin before revoking org access.

1.3 Identify all the apps this person has access to. The apps they told you about. The apps you provisioned. The apps they signed up for themselves using their work email (shadow IT). The contractor tools they onboarded during a project six months ago that nobody updated in the access matrix.

If you're doing this manually, pull from: the IdP directory, the HRMS provisioning log, your SaaS management tool, and — honestly — ask their manager. There are always two or three apps the IT ticket list doesn't know about.

If you have a tool like KINT, the access map is already there.

1.4 Flag any service accounts, shared credentials, or integrations tied to their personal account. This is the single most-missed category. An engineer who set up a CI/CD pipeline using their personal GitHub account. A Salesforce admin who created an API key tied to their Salesforce login. An IT admin who is the sole owner of the Google Workspace Marketplace app approval account.

Find these now. You cannot rotate credentials if you don't know they exist.

1.5 Notify affected team leads and system owners. If the departing employee was a system admin for any tool — GitHub org owner, Salesforce admin, Okta super-admin — the backup admin for that tool needs to be confirmed before the last day. Do not discover this gap at 5pm Friday.

Phase 2: Day of departure — directory and IdP (within the first hour)

This phase is time-critical. Start the moment the last-day window opens — before end-of-business, not after.

2.1 Suspend (do not delete) the account in the primary directory.

• Microsoft Entra ID / Active Directory: disable the account, not delete. Deletion is permanent and you may need the mailbox and files for 30–90 days.
• Google Workspace Admin Console: suspend the account. This blocks login while preserving data.
• Okta: deactivate the user. All app assignments associated with Okta SSO are automatically revoked when Okta deactivates.
• JumpCloud: suspend the user account before deletion.

Why suspend, not delete: Active data, compliance evidence, and e-discovery needs can require access to the email and files for weeks after departure. Suspension blocks login; deletion destroys data. Suspend first. Delete after the retention window, per your data policy.

2.2 Revoke all active SSO sessions. Disabling an account in Entra ID or Okta does not immediately terminate active browser sessions. In Okta: Admin → Users → [user] → More Actions → Clear Sessions. In Entra ID: revoke all refresh tokens via PowerShell or the Azure portal. In Google: Admin Console → Users → [user] → Revoke sign-in sessions.

An active session can persist for hours after account suspension if you don't explicitly revoke it.

2.3 Rotate the shared admin passwords or service account credentials the employee had access to. This is non-negotiable if they were an admin on any system. The shared IT admin password for your network gear. The root AWS credential they had. The API key for the billing integration they managed. Rotate all of these on the same day as the account suspension, not the day after.

Phase 3: API and SCIM-connected SaaS apps (same day as Phase 2)

Every app that connects to your IdP or supports SCIM provisioning can be revoked automatically or semi-automatically. Work through this list fast.

3.1 Google Workspace (if it's the IdP) Already covered in Phase 2 — suspension in the Admin Console revokes all Google-native app access. Confirm Google Drive transfer is complete before suspension.

3.2 Microsoft 365 / Entra ID apps Account suspension in Entra ID revokes access to all apps using Entra for SSO. Verify: SharePoint, Teams, OneDrive, Power BI, any Azure-connected apps. Check the Entra ID enterprise applications list for any apps the employee may have individually consented to — these can persist.

3.3 Slack If your Slack is provisioned via Okta or Entra SCIM, account deactivation in the IdP cascades to Slack. If Slack is standalone: Admin → People → [member] → Deactivate. The deactivated account retains message history; it cannot log in. Check that no active Slack Connect channels remain open with the member listed as the connecting contact.

3.4 GitHub Remove from all GitHub organizations. Settings → Organization → People → Remove. Also: revoke all personal access tokens, SSH keys, and OAuth app authorizations that were granted under their account. If they had GitHub Actions secrets or environment variables tied to their personal account, rotate those too. Full guide: remove ex-employee GitHub access.

3.5 Jira / Atlassian Deactivate via Atlassian Admin (admin.atlassian.com) — this deactivates across Jira, Confluence, and all connected Atlassian products simultaneously. Re-assign any open tickets they owned. Check if they had API tokens created under their Atlassian account — revoke those from the admin panel.

3.6 Salesforce Deactivate the user in Setup → Users → Deactivate. Salesforce does not allow deletion of users with data history — deactivation frees the license. Check for API integrations and Connected Apps authorized under their account.

3.7 Zendesk / Freshdesk Deactivate or delete depending on ticket ownership needs. If they owned open tickets, reassign before deactivating. Check for any API tokens or webhook configurations they created.

3.8 Zoom Deactivate via the Zoom Admin Portal. If your Zoom is provisioned via Okta or Entra SCIM, the IdP suspension handles it. If standalone, deactivate manually. Recordings in their personal Zoom cloud are not automatically transferred — download or reassign any recordings that matter before deactivation.

3.9 Hubspot / CRM Deactivate and reassign open deals, contacts, and tasks. CRM access lingering is a surprisingly common gap — ex-employees can retain access to customer data for weeks if this is missed.

3.10 Any other SCIM-connected apps Your SCIM-enabled apps will cascade from the IdP if they're properly configured. Run a spot-check: after disabling the account in Entra ID or Okta, attempt a test login for one SCIM-connected app to confirm revocation actually cascaded. SCIM sync delays can cause a 5–15 minute lag; active sessions may persist even after provisioning is revoked.

Phase 4: Browser-only and non-SCIM apps (the ones IT teams miss)

This is the hardest phase. Around 40% of mid-market SaaS apps do not support SCIM or any machine-readable provisioning API. This means your IdP cascade did nothing to them. Each one requires a manual login.

These are the apps that create the 11-day lag. Not the SCIM apps — those are (mostly) handled by the IdP cascade. It's the ones that sit outside the IdP that accumulate.

4.1 Adobe Admin Console Adobe Creative Cloud does not provision or deprovision via SCIM in the standard mid-market configuration. Log in to the Adobe Admin Console, navigate to Users, remove the departing employee. If they were an admin of any Adobe product license plan, demote them before removing.

4.2 Notion Notion supports SAML-based SSO but the deprovisioning behavior depends on your plan and configuration. If SSO is set up correctly, disabling in the IdP should block login. If not, log in to Notion Settings → Members and remove manually. Shared workspaces remain accessible to external collaborators even after internal removal — check those too.

4.3 Loom, Miro, Canva All three require manual admin removal unless your org has SCIM configured (Miro and Canva have SCIM on paid plans; Loom's SCIM is available on Enterprise). Log in to each admin panel and remove the user. Check for shared templates, boards, and workspaces that contain sensitive company content.

4.4 Figma Figma supports SCIM on the Organisation plan. If you're on a lower plan, deprovisioning is manual: Admin → Members → Remove from organization. Check that all files in their personal drafts that belong to the company are transferred to a team project before removal.

4.5 Any tool they signed up for with their work email (shadow IT) This is the category no checklist can fully enumerate. Standard approach: send a standard IT separation notice to the employee before their last day asking them to list any SaaS tools they signed up for using their work email that aren't IT-managed. Most people will cooperate. Then rotate the work email password after their departure — any tool using their email + that password is blocked when the password changes.

Phase 5: Credentials, keys, and service accounts

Access doesn't only live in SaaS app user accounts. Credentials can persist in multiple other places.

5.1 Personal access tokens (PATs) and API keys GitHub, Jira, Salesforce, Hubspot, and most SaaS platforms allow users to create API tokens tied to their account. When the account is deactivated, these tokens are usually invalidated — but verify this per platform. Check any CI/CD pipelines, automation scripts, or integrations that may be calling APIs using credentials created under their account.

5.2 SSH keys Remove their public key from every system where it was authorized: GitHub, GitLab, servers, cloud infrastructure. If you're running on AWS EC2, Azure VMs, or GCP Compute — remove from ~/.ssh/authorized_keys on each instance.

5.3 Shared passwords from the team vault If your team uses 1Password, Bitwarden, Dashlane, or any shared credential vault, remove the departing employee from all shared vaults and rotate any credentials they had write access to. Shared passwords they knew are compromised credentials — treat them as such.

5.4 MFA devices and backup codes Revoke any MFA devices registered to their account in Okta, Entra ID, or your authenticator platform. Invalidate any backup codes that were generated. If they had hardware keys (YubiKey, etc.), those should be physically returned and deregistered.

5.5 AWS / GCP / Azure IAM users Delete or disable any cloud IAM users associated with their identity. Remove them from all IAM groups. Rotate any access keys tied to their IAM user. If they had console access, confirm the session is terminated.

Phase 6: Device and endpoint

6.1 Initiate remote wipe if required by policy. If the device is not being returned, or was a personal device under a BYOD policy with corporate data on it, trigger the remote wipe through your MDM (Jamf, Microsoft Intune, VMware Workspace ONE, etc.). Confirm the wipe completed — most MDM platforms send a confirmation.

6.2 Remove the device from MDM enrollment. After the wipe is confirmed: unenroll the device from Jamf, Intune, or your MDM platform. This removes it from your managed fleet.

6.3 Revoke device certificates. If your organization uses certificate-based authentication for VPN or Wi-Fi, revoke the certificates issued to the departed employee's device.

6.4 Rotate VPN credentials. If you're using a pre-shared key or username-based VPN, ensure the employee's credentials are revoked. If they had access to any internal systems via VPN that aren't covered by SSO, confirm those are blocked.

6.5 Review firewall rules for any named-user rules. Some teams create firewall or network access rules tied to specific users. Check for these and clean them up.

Phase 7: Audit trail

This is what makes the revocation defensible — to your security team, your auditor, and any future review.

7.1 Document every revocation with a timestamp. For each app in phases 2–5: who revoked access, what was revoked, when. A spreadsheet is fine. A signed log in a lifecycle tool is better. An auditor asking "when was this person's GitHub access revoked?" needs a specific answer, not "I think it was around the time they left."

7.2 Map to SOC 2 CC6 controls if applicable. SOC 2 CC6.1 covers logical access controls, CC6.2 covers user provisioning authorization, CC6.3 covers access removal. Your offboarding evidence — the revocation log — maps directly to CC6.3. Keep it exportable and retrievable.

7.3 Confirm 30-day post-departure access review. Set a 30-day reminder to re-check the key systems: GitHub, Salesforce, AWS IAM. Former employees sometimes have access restored by accident (someone re-adds them to a distribution list that grants app access, a service account with their name gets re-enabled during a system restore). A 30-day spot-check catches these.

The apps IT teams miss most

In practice, the SCIM-connected apps in Phase 3 are rarely the gap. Okta or Entra handles those.

The gaps show up in four places:

1. Browser-only apps (Phase 4). Adobe, Notion, Miro, Canva, Loom, Figma. They don't cascade from the IdP. They need manual admin access. Most mid-market IT teams have 3–8 of these, and they're often not in the official app catalogue.

2. Service accounts and API keys (Phase 5). The GitHub personal access token that's been running a nightly sync for 18 months. The AWS access key from the engineer who set up the original infrastructure. These don't show up in user management panels — they live in secrets managers, CI configs, and .env files.

3. Apps the employee self-provisioned (shadow IT). Survey any departing employee before their last day. The list always has surprises.

4. The 30-day drift. Systems get restored. Lists get re-populated. Someone adds an old email alias back to a Slack channel that grants Google Calendar access. The 30-day post-departure audit catches what slipped through.

How long should IT offboarding take?

Manual, for a mid-market company running 20–40 SaaS apps: 2–4 hours per offboarding, assuming nothing goes wrong. Industry research suggests the median is 11 days end-to-end — not because any single step takes that long, but because the steps get scattered across time, tickets, and team members.

Automated, with an HR-driven lifecycle tool: under 60 seconds for the API and SCIM apps. The browser-only apps still need manual or browser-automation handling. KINT runs a full offboarding across 6+ apps in parallel in ~47 seconds — the timeline goes from HR trigger to signed evidence packet without a ticket in between.

The 14-day free trial has no card required. If you're managing 100+ employees and offboarding manually, it's worth seeing how the automation maps to your stack.

FAQ

Q: What's the first thing IT should do when an employee is terminated? Suspend the account in the primary directory (Entra ID, Google Workspace, or Okta) within the first hour of the termination. This blocks SSO-based access across every connected app in one action. Do not wait until the end of the day.

Q: Should you delete or suspend an employee's account when they leave? Suspend first, delete later. Suspension blocks login while preserving data — email, files, and access history you may need for compliance or legal review. Most legal and compliance teams recommend a 90-day hold before deletion. Check your data retention policy and confirm with legal before deleting accounts.

Q: What happens to files when you deactivate an employee in Google Workspace? Documents the employee created and owns in Google Drive remain accessible to admins after account suspension but will be deleted if the account is deleted. Before deactivating, transfer document ownership to a manager or designated Google Workspace admin. Google's Admin Console has a built-in "Transfer Drive files" tool for this.

Q: How do you revoke access to apps that don't support SCIM? Manually, by logging into the app's admin panel and removing the user. Apps like Adobe Creative Cloud, Notion (without SSO), Loom, Miro, and Canva require this. The alternative is browser automation — tools like KINT use browser automation to handle these apps programmatically so they're not left for manual follow-up.

Q: What is the biggest offboarding security risk for a 100–500 employee company? Service accounts and API keys tied to a departing employee's personal account. Unlike SaaS user accounts (which are blocked when the account is suspended), API tokens and SSH keys can continue functioning even after the user is deactivated — unless they're explicitly revoked. Check every CI/CD pipeline, automation script, and cloud infrastructure deployment for credentials issued under the departing employee's identity.

Q: How do you prove to an auditor that offboarding happened? You need a timestamped log for each revocation — app, action, date, who performed it. SOC 2 CC6.3 specifically requires evidence of timely access removal for terminated employees. If you're doing offboarding manually, keep a revocation log in writing. If you're using a lifecycle platform like KINT, every revocation is automatically signed with an Ed25519 signature and mapped to SOC 2 CC6 controls, exportable in three clicks.

Q: How do you handle contractor offboarding differently from employee offboarding? The same IT checklist applies — all access revocation steps are identical. The timing is different: contractor access should be provisioned with a hard expiry date set at the start of the engagement, so that offboarding is an automatic event rather than a triggered response. The gaps in contractor offboarding are usually around shadow IT apps and API keys that were set up during the project and never tracked centrally.

Q: What's the risk of waiting until end of day to revoke access? High. An employee who knows they're being terminated has hours to copy files, exfiltrate data, or make changes before their access is revoked. Best practice is to revoke access at the same time the termination conversation happens — or within the hour. For involuntary terminations especially, simultaneous access revocation and notification is standard at security-conscious organizations.

Q: What does "IT offboarding checklist" cover that a general employee offboarding checklist doesn't? The IT offboarding checklist is specifically the access and credential side: directories, SaaS apps, SSH keys, API tokens, device management, and audit trail. A general employee offboarding checklist includes all of that plus HR steps (exit interview, final paycheck, benefits termination, equipment return form). IT runs its checklist regardless of what HR's timeline looks like.

Q: How do you automate the IT offboarding checklist? HR-driven lifecycle platforms like KINT connect to your HRMS (BambooHR, Workday, HiBob, Keka, Darwinbox, etc.) and trigger a deprovisioning workflow the moment a departure event fires. The platform revokes access across every connected SaaS app in parallel — API apps, SCIM apps, and browser-only apps via browser automation — and produces a signed audit log. Setup is OAuth-based, under 5 minutes, with a 14-day free trial at kingsleyint.com.

Published by Kingsley Integrators — KINT is an HR-driven identity lifecycle automation platform for 100–500 employee companies. Self-serve signup at app.kingsleyint.com.