How to automate offboarding

Offboarding is treated as a diligence problem. It is a coverage problem, and that is why a better checklist has never fixed it anywhere.

Someone quits on Friday. The clock starts.

Across most companies what happens next is not a system. It's a checklist. Someone runs it, usually the IT manager, usually halfway through three other things. That's 5 hours of revoking access across 40 apps, hoping nothing got missed.

Then 3 months later the ex-employee can still log in to one of them. Could be the BI tool finance has bookmarked. Could be a Salesforce account with production records. Could be the LIMS the lab opened a seat in 3 years ago. Nobody finds out until the audit. Or worse, the incident.

Zero-touch offboarding is supposed to close that gap. Not better offboarding, and not faster offboarding. A different operating model, where the departure trigger fires once, every account everywhere gets handled, and nobody clicks anything.

What zero-touch offboarding means

Strip the marketing and there are 5 things you can measure.

1. One trigger. Usually a status change in the HRIS. Not a Slack message, not an email to IT, not a calendar reminder.
2. The trigger propagates to every system the person had access to, without a human relaying it.
3. Each system gets the right action. Disable, revoke, transfer ownership, archive, delete.
4. The sequence completes in seconds or minutes.
5. An audit trail captures every action, with a timestamp and the policy that fired it.

Miss any of those and what you have is manual offboarding with some automation bolted on. Both are common. Only one is zero-touch.

Why most offboarding fails

Two reasons, in the order you'll hit them.

The coverage problem. SSO and SCIM together handle around 20% of the average stack. The rest is SaaS on standard plans where SCIM sits behind an enterprise tier (the SCIM tax; the SCIM Tax Index lists 300+ such vendors), internal admin panels, legacy systems someone in finance set up years ago, the SAP environment outside everyone's roadmap, and the non-human side: service accounts, API keys, agents that didn't exist last year.

Offboarding routed through SSO deactivates the directory account. In apps that don't honor the directory, the account stays. The session persists. The data is still reachable. The ex-employee logs in directly, because their email still exists as a user record inside the app, and SSO has no opinion about that.

The granularity problem. Even in the apps that do get touched, the action is often too coarse. You remove someone from an "Engineers" group. Their direct repo access stays. Their per-channel access stays. Their admin permission in staging stays. The group was a proxy for what they actually had, and proxies don't match.

The result is the orphaned account. About a third of ex-employees still have access to something after their last day, according to the 2026 PDQ State of System Administration survey. Most teams find out at audit, or by accident. That isn't an IT failure. The tools weren't built to make it complete.

What it takes to automate it

Four things have to be true, and the order matters more than most write-ups admit.

HRIS: termination effective 17:00
   |
   +-- ONE trigger. Not a ticket, not a checklist, not an email.
   |
   v
for each app in the inventory, the method it actually supports
   |
   +-- SCIM            deactivate            seconds
   +-- API             deactivate + reassign seconds
   +-- UI-driven       drive the console     minutes
   +-- custom          purpose-built path    minutes
   +-- no path yet     flagged for a person, offboarding stays OPEN
   |
   v
order enforced per app
   transfer owned resources  --->  revoke sessions  --->  close account

evidence written per line: method used, result, timestamp

1. One trigger, not many. The HRIS knows when someone leaves, so that has to be the source of truth. The instant the status changes in Workday or BambooHR or Personio, every downstream system should be working from that signal. If IT still finds out from a Slack message, the trigger is wrong.

2. Coverage across the actual stack, including the parts that aren't SCIM-friendly. This is where most tools quietly fail. They count integrations, and the integration for the app you care about turns out to be a manual workflow trigger that files a ticket for someone to handle.

The hard work of offboarding is the long tail. The internal admin tool. The marketing platform someone in growth signed up for. The HR system the previous IT lead never documented. The custom application engineering built 3 years ago. A tool that can't reach those is solving the easy fifth.

3. The right action per app. Disabling is correct in some. In others you remove the person from specific repositories but keep the account for 2 weeks during a transition. In others you revoke permissions but preserve records for retention. Group-level revocation is too coarse and account deletion is too destructive, so the system has to know what "offboarded" means in each environment.

4. Data preservation handled with the access. Most tools treat identity termination as the end of the work. It isn't. Files, document ownership, dashboards, repositories, customer notes. Some transfers, some archives, some gets deleted under your retention policy. That runs alongside revocation, not as a separate thing someone is supposed to remember.

Patterns that break it

Named so you can spot them in your own process.

1. The checklist that drifts. Whoever ran offboarding 2 years ago wrote it down. A different person runs it today. Half the apps on the list no longer exist and the new ones aren't on it.
2. The "SSO covers it" assumption. The directory deactivates the user, the app account stays. This is where most orphan reports come from.
3. Group-level only. Removing someone from "engineers" doesn't touch their direct repo access, their staging admin permission, or the database role granted last quarter.
4. Contractor blind spots. Contractors often aren't in the HRIS, so the trigger never fires. Their access can persist for a year.
5. Shadow IT. The app marketing signed up for last quarter, with its own admin login and its own permissions, in nobody's offboarding flow.
6. Non-human identity. The API keys the leaver created, the service account they spun up, the agent they connected to production. None sit in the directory, and none get revoked unless someone built that path deliberately. (For agents specifically, see the AI agent governance pillar.)

Doing this without a tool

You can get most of the way with a spreadsheet and a cron job. It's worth knowing what that costs before deciding it's not worth buying anything.

1. Build the real app inventory. Not from your SSO, which only knows about the fifth it handles. Pull from expense reports and card statements, then ask each team lead what they use. Expect 2 to 3 times what you thought.
2. For every app, record the admin and the removal path. Who can remove someone, and the exact steps. This column is the one that goes stale.
3. Put the HRIS termination report on a daily job into a channel IT reads. This is your trigger, and it's the cheapest part to build.
4. Order the per-app steps so ownership transfers run before anything is deleted. A deleted account takes its owned files with it, and that mistake is not recoverable.
5. Keep an evidence log. App, action, who did it, timestamp. A spreadsheet is fine. Your auditor cares that it exists and is contemporaneous, not that it's elegant.
6. Re-audit the inventory quarterly, because step 1 decays faster than anything else here.

Two to 5 hours per departure once it's running, plus a day a quarter keeping the inventory honest.

That last day is the whole thing. The inventory is the asset here and it rots faster than anything else on the list: apps get bought, apps get retired, and the document that was accurate in January describes a stack that no longer exists. A working process becomes a half-fiction 18 months later without anybody deciding to let it.

What still needs a person

Zero-touch is not no-touch. Some lines will always route to a human, and an honest process says so up front.

A shared admin account with no single owner can't be closed until someone decides who inherits it. An app where the leaver was the only administrator needs somebody promoted before anything can be revoked. A licence worth reclaiming deliberately is a decision, not a task.

These should arrive with full context, and the offboarding should stay open until they're cleared. That property is what makes the record worth anything later.

Where Iden fits

The mechanism above, running.

The HRIS termination is the trigger. Iden walks the inventory and uses whatever each app supports: SCIM where it exists, an API where it doesn't, a custom automation framework for the console-only ones, and a purpose-built connector where none of that applies. Transfers run before closures. Every line writes its own evidence row.

The apps with no path yet get flagged rather than skipped, and the offboarding stays open until a person clears them. That's the difference between a report that says 40 of 40 and a report you can hand an auditor.

Findings as an inbox. Categories and counts on the left, the queue on the right, and two categories already at zero. Angelina was offboarded three days ago and still holds six apps.

You can also run it backwards on people who already left. That's usually the uncomfortable number.

"We found 47 orphaned accounts we didn't know existed. We're only 100 people."

Head of IT, SaaS startup

Their previous tools weren't bad. They just couldn't reach where the accounts lived.