The complete guide to IT offboarding

why IT offboarding fails

The directory gets closed. Everything else stays open. This is a visibility problem, rarely a discipline one. An employee accumulates access continuously: a SaaS tool adopted by one department, a direct login to an analytics platform created before SSO was configured, an API token generated on a Friday to get something done, a shared admin password they were given three years ago and never asked to hand back.

By the time someone leaves, their access footprint is typically larger than any list IT holds. Offboarding depends on that list being complete. When it is not, access outlives the employment. IBM's Cost of a Data Breach report puts the average time to identify and contain a breach at 241 days. An account left open after departure can be used across that entire window with no alert that would surface a breach.

There is also a structural problem: offboarding relies on a handoff chain. HR notifies IT. IT runs a checklist. Each application responds. Each step is a potential gap, and in environments with manual processes, some steps simply do not happen. The result is orphaned accounts: active logins that belong to people who are no longer employees.

The JML gap. Joiner-mover-leaver is the process that governs access at every transition. The joiner step tends to work because new employees need access to do their jobs and someone notices when it is missing. The leaver step has no such urgency. The former employee is gone. Nobody is waiting. The work gets deferred or forgotten.

the full deprovisioning scope

Running a complete offboarding means working through each category below. Some are trivial if your environment is well-configured. Some require manual work regardless.

1. Identity directory. The primary IdP: Active Directory, Google Workspace, Okta, Microsoft Entra ID. Disabling the account here removes access to every app that authenticates through SSO. This is the step most offboarding processes execute reliably.

2. SSO-connected applications. Applications that authenticate through the IdP via SAML or OIDC will lose access when the directory account is disabled, provided SSO is enforced. Verify that SSO enforcement is active, not just configured. An app where SSO is available but not required still accepts direct logins.

3. Applications outside SSO. Every application that holds a direct login, independent of the directory. These are not touched by disabling the IdP account. They require a manual revocation or a separate automated workflow. Common examples: legacy tools with their own user databases, consumer SaaS tools adopted without IT involvement, apps where SSO was never configured. Identifying these apps requires either a tool that maps them, or a systematic export of each known application's user list compared against your active employee directory.

4. OAuth grants. Applications authorized via OAuth hold their own access token, independent of the user's directory status. Disabling the IdP account does not automatically revoke that token in all cases. OAuth grants need to be reviewed and revoked at the application level, or through your IdP's OAuth grant management console if it provides one. This step is regularly missed because the grants are not visible in standard offboarding checklists.

5. API tokens and keys. Tokens and keys generated by a specific person often have no transfer-of-ownership record. They live in CI/CD pipelines, third-party integrations, and scripts. If they were generated by the departing employee, they may carry their identity and need to be rotated, not just revoked, to ensure continuity. The working approach is to pull tokens from each system that issues them and filter by creator or associated identity.

6. Service accounts owned by the departing employee. Service accounts used by applications and integrations are often set up by specific engineers or admins. When that person leaves, the service account may have no documented owner. Find any service account linked to the departing employee's identity, assign a new owner, and change any credentials where they were the sole holder.

7. Shared-account passwords. Wherever the departing employee was part of a shared-account arrangement, rotate the password. Shared credentials are a security problem in their own right, but in the interim, rotating on departure is the minimum step.

8. Contractor and vendor access. External parties with access to internal systems need the same revocation process as full-time employees. The difference is that contractor offboarding depends on someone notifying IT when the engagement ends, and that notification often does not come.

9. Devices. Retrieve company-owned devices before or on the last day. Remotely wipe company data from personal devices where MDM is enrolled. Revoke device certificates if applicable. Deregister from MDM after wipe.

10. Data ownership and transfer. Files, documents, and shared drives owned by the departing user need to be transferred to a manager or designated successor before the account is fully disabled. Once the account is closed, the data may be inaccessible.

step-by-step offboarding sequence

Timing matters. The goal is to close high-risk access before the departure, complete full revocation on the day, and verify nothing was missed in the weeks after.

before the last day (ideally 48-72 hours out)

Confirm the departure date with HR; the trigger should come as early as possible. Identify high-risk access (admin rights, customer data systems, financial platforms, code repositories, email); these are your P0 items. Notify relevant system owners for applications IT does not control directly. Transfer data ownership before the account is disabled. Prepare the revocation checklist by pulling the full access list for this person: IdP exports, SaaS app user lists, OAuth grant logs, known API tokens.

day of departure

Disable the IdP account first, before the working day ends; in higher-risk departures it should happen at the start of the last day. Revoke OAuth grants through the OAuth grant management console for each connected application. Revoke application access for apps outside SSO, working through the checklist item by item. Rotate shared credentials. Wipe and deregister devices. Invalidate active sessions by forcing sign-out of all sessions for the IdP account.

after departure (30-day check)

Verify revocation is complete by pulling user lists from each application and confirming the departed user does not appear as active anywhere. Check for API tokens and service accounts if this was not completed on the departure day. Close out any open items, documenting what was completed, deferred, and resolved, which is the evidence trail required by compliance frameworks. Confirm license release in each paid application.

contractors and fixed-term access

Contractor offboarding fails for a different reason than employee offboarding. The problem is not the process once IT knows the engagement ended. The problem is that IT often does not know. Full-time employees have an HR termination record. Contractors may be managed by a department head, a finance team, or directly by a project manager. When the project ends, the contractor stops working, and nobody tells IT to remove access. The account sits open.

The fix is architectural, not procedural. Contractor access should be provisioned with a defined end date from the start. When the end date passes, access should expire automatically, or at minimum, an alert should trigger a review. Most identity platforms support this through account expiry settings or through conditional access policies tied to a group membership. The same applies to fixed-term employees, interns, and agency workers. Any engagement with a known end date should have access tied to that end date from the start. Vendor and third-party access follows the same logic. A quarterly audit of contractor and vendor accounts is a practical minimum: compare every external account in your directory against a current list of active engagements.

how to make offboarding repeatable

A checklist run manually for each departure is better than no checklist. It is not a scalable process. The goal is automation at the point where access is granted. If every account is provisioned through a central identity provider, and every application authenticates through SSO, offboarding is a single action: disable the IdP account. Everything downstream propagates automatically.

That state requires a central IdP that all applications connect to, SSO enforced (not optional) on every application, and SCIM provisioning configured for applications that support it. SCIM (System for Cross-domain Identity Management) is the protocol that allows an IdP to push user lifecycle events to connected applications. When SCIM is configured, deprovisioning in the IdP triggers automatic account deletion or suspension in the connected application. Not all SaaS applications support SCIM. For those that do not, the alternatives are a manual revocation step per application, or a third-party IGA tool that manages provisioning across systems.

The practical path for most organizations is incremental. Start with a complete inventory of where access exists. Configure SSO and SCIM for the highest-risk and most-used applications first. Build the checklist for everything else. The applications that present the most risk are the ones furthest from your central directory: apps adopted without IT involvement, apps with direct logins, apps where SSO is configured but not enforced.

how offboarding maps to compliance frameworks

Every major access control framework requires evidence that departures are handled completely and within a defined time window. Partial offboarding, or offboarding with no documentation, is a finding in each of them.

SOC 2 (Trust Services Criteria CC6.2). Requires logical access to be provisioned and revoked based on authorization. Offboarding is the canonical test of whether revocation happens. A checklist with a completion record satisfies this if it is consistently applied.

ISO 27001 (Control A.5.18 / A.8.7). Access rights should be removed upon termination of employment and adjusted upon role changes. The standard requires a defined process and documented evidence. The scope includes all access: application, network, physical.

NIS2 (Article 21). Access management and the handling of personnel changes are included in the security measures required of essential and important entities. NIS2 expects demonstrable access control across the organization's information systems.

DORA (Regulation EU 2022/2554). Financial entities under DORA are required to manage ICT user access and align it with the principle of least privilege. Departure handling is a direct test of whether user access management is functioning. DORA expects documented evidence and defined timeframes for access revocation. Across all four frameworks, the requirement is the same: a process exists, it is applied consistently, and evidence is available.

common mistakes

Closing the directory and stopping there. The most common failure. Apps outside SSO, OAuth grants, and API tokens are not touched. The person is gone from IT's view, and the access persists.

No post-offboarding verification. The checklist is completed on the departure day. Nobody checks 30 days later. Items deferred at departure remain open indefinitely.

Contractor access with no end date. Contractors are provisioned. Nobody sets an expiry. The project ends. IT is not notified. The account sits open for months or years.

Service accounts with no owner. The departing employee created service accounts that nobody documented. They surface only when something breaks, or when an auditor finds them.

Shared credentials not rotated. The departing employee knew several shared passwords. The passwords are not changed because nobody wants to update every integration that uses them. The convenience wins, and the risk stays.

Delayed notification from HR. IT finds out the employee left after the last day. By then the person has had unsupervised access to company systems for the duration of their notice period and beyond.

No documentation. The offboarding happened but nothing was recorded. When an auditor asks, the answer is "we did it" with no evidence. That is a finding.