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. Five hours of revoking access across forty apps, hoping nothing got missed.
Three months later, the ex-employee can still log in to one of them. Could be the BI tool finance still has bookmarked. Could be a Salesforce account with production records. Could be the LIMS the lab opened a seat in three years ago. Nobody finds out until the audit. Or worse, the incident.
This is the gap zero-touch offboarding is supposed to close. Not better offboarding. Not faster offboarding. A different operating model. The departure trigger fires once, every account everywhere gets handled in seconds, and nobody clicks anything.
What zero-touch offboarding actually means
Strip the marketing and there are five things you can measure.
- One trigger. Usually a status change in the HRIS. Not a Slack message. Not an email to IT. Not a calendar reminder.
- The trigger propagates automatically to every system the person had access to.
- Each system gets the right action. Disable, revoke, transfer ownership, archive, delete.
- The whole sequence completes in seconds or minutes.
- An audit trail captures every action, with timestamp and the policy that fired it.
If your current offboarding is missing any of those, what you have is manual offboarding with some automation bolted on. That's a different category. Both are common. Only one is zero-touch.
Why most offboarding fails
Two reasons, in order of how often they show up.
The coverage problem. SSO and SCIM together handle around 20% of the average company's app stack. The rest is a mix of SaaS on standard plans (where SCIM is gated behind an enterprise tier, the SCIM tax), internal admin panels, legacy systems someone in finance set up years ago, the SAP environment that lives outside everyone's roadmap, and the non-human side of identity. Service accounts. API keys. AI 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 can persist. The data is still reachable. The ex-employee can log in directly because the email still exists as a user record inside the app. SSO has no opinion about that.
The granularity problem. Even in apps that do get touched, the action is often too coarse. You remove the person from an "Engineers" group. Their direct repo access stays. Their per-channel access in the messaging tool stays. Their admin permission in the staging environment stays. The group was a proxy for what they actually had, and proxies don't fully 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 discover the gap at audit, or by accident, or when someone notices an old credential still showing in a vendor dashboard. This is not an IT failure. The tools weren't built to make it complete.
What it takes to automate it
Four things have to be true.
One trigger, not many
The HRIS knows when someone leaves. That has to be the source of truth. The instant the status changes in Workday or BambooHR or Personio or Rippling or whatever you use, every downstream system should be working from that signal. If IT is still finding out from a Slack message, the trigger is wrong.
Coverage across the actual stack
Including the parts that aren't SCIM-friendly. This is where most offboarding tools quietly fail. They claim coverage by counting integrations, but the integration for the app you care about turns out to be a "manual workflow trigger" that just creates a ticket for someone to handle.
The hard work of offboarding is the long tail. The internal admin tool. The marketing intelligence platform someone in growth signed up for. The HR system the previous IT lead never documented. The SAP user lifecycle nobody owns. The custom application engineering built three years ago. If a tool can't reach those, it's solving the easy fifth of the problem.
The right action per app
Disabling the account is correct in some apps. In others you need to remove the person from specific repositories but keep the account for two weeks during a transition. In others you need to revoke specific permissions but preserve records for compliance retention. In others you need to archive their owned content before deleting the account.
Group-level revocation is too coarse. Account deletion is too destructive. The system needs to know, per app, what "offboarded" actually means in that environment.
Data preservation handled with the access
Most offboarding tools treat identity termination as the end of the work. It isn't. There's a data layer underneath. Files in Drive. Ownership of documents and databases. Dashboards. Repositories. Customer notes. Some of it needs to be transferred. Some archived. Some deleted under GDPR or your retention policy.
A real offboarding flow handles this alongside the access revocation, not as a separate manual process the team is supposed to remember.
Patterns that break it
A few of the most common failure modes, named so you can spot them.
The manual checklist that drifts. Whoever ran offboarding two years ago wrote a runbook. Different person runs it today. Half the apps on the list no longer exist; new apps in the stack are not on the list. The runbook is half-fiction at this point.
The "SSO covers it" assumption. The directory deactivates the user. The app account stays. This is where most orphan reports come from.
Group-level only. Removing someone from the "engineers" group does not touch their direct repo access in GitHub, their admin permission in the staging environment, or the database role they were granted last quarter. The group was a coarse proxy. Proxies miss things.
Contractor blind spots. Contractors often don't sit in the HRIS. The trigger never fires. Their access persists until someone notices. That can be a year.
Shadow IT. The app marketing signed up for last quarter that nobody told IT about. It has its own admin login and its own permissions. It's also not in any offboarding flow.
Non-human identity. The API keys the ex-employee created. The service account they spun up for a side project. The AI agent they connected to your production database. None of these sit in the directory. None of them get revoked unless someone built that path on purpose.
What a working day-of looks like
Practically, on the day someone leaves, the sequence should run like this.
The HRIS marks the employee as departed at 5pm. By 5:00:30, every connected app has begun processing. Account-level changes fire first: disable, password rotate, session invalidate. Permission-level changes come next: remove from specific repos, channels, projects, database roles. Data ownership transfers route to the new owner based on the policy your team defined upstream. Service accounts and API keys the person created get rotated or revoked. The audit log captures every action with a timestamp and the policy that triggered it.
The IT manager finds out it happened the next morning when they open the dashboard. Not at 11pm trying to remember which apps were still on the offboarding list.
There's a name for the first state. Hope-based offboarding. Zero-touch is the alternative.
Where Iden fits
Iden is built around this model. HRIS as the trigger, coverage past SSO into the systems where the gap lives, audit trail live and exportable. Configurable per app, because "offboarded" means different things in different places.
If your offboarding is still in a shared spreadsheet, this is the shift. If it's already partially automated through Okta Lifecycle Management or a SaaS management tool, Iden is the layer that fills the gaps those tools leave.
"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.