Offboarding is the identity task that goes wrong most quietly, because a failure produces no error message. A leaver whose account is still alive in one forgotten application looks exactly like a leaver who is fully gone, until the day someone checks. This guide walks through building a dependable leaver workflow in seven steps, drawing on the IdentityOps material in the Ops Atlas and on public identity standards. It assumes a central identity provider, an HR system as the source of employment records, and a handful of applications that accept automated provisioning.
Step 1: Name the trigger and its owner
Every automated sequence needs a starting event. In a well-run estate that event is the termination date recorded in the HR system, not a ticket someone remembers to raise. The Ops Atlas places this joiner, mover and leaver handling at the core of IdentityOps and treats HR as the authority on who belongs. Write down two things: which field in HR fires the workflow, and who is accountable if that field is wrong. Most downstream errors can be traced back to a late or mistyped HR record, so the owner of data quality matters as much as the owner of the automation.
For the wider framing of what this discipline covers and where its edges lie, consult the Ops Atlas page on IdentityOps, which also records that the term is not yet formally standardised.
Step 2: Decide the order of operations
Sequence is not cosmetic. The Atlas describes the intended flow as follows:
- The HR system records the termination.
- The identity provider account is disabled.
- Active sessions and tokens are revoked.
- A provisioning message marking the user inactive is sent to each connected application.
- Timestamps for every step are recorded.
Resist the temptation to reorder for convenience. Revoking sessions before disabling the account allows the user to sign straight back in; disabling without revoking leaves existing sessions running. And a record without timestamps makes it impossible to prove to an auditor, or to yourself, that the targets were met.
Step 3: Learn your platform’s quirks before you rely on it
The Atlas catalogues several vendor behaviours that surprise teams. On one popular identity platform, the setting that allows deactivation of users must be enabled before provisioning can switch accounts off. On another, the scheduled provisioning cycle runs on the order of every forty minutes, and the on-demand push, which typically finishes in under thirty seconds, only works for users who are unassigned from an application. Unassigning a user and pushing in that order leaves the downstream account switched on until the last push completes, a sequencing trap that is easy to miss in testing. For applications authorised through OAuth, such as some collaboration suites and file-sharing tools, the provisioning job may need to be stopped first.
Treat these as test cases, not trivia. Run a dummy account through each application before the process goes live.
Step 4: Handle sessions deliberately
Disabling an account does not necessarily end a session already in progress. The Atlas points out that access tokens on one major platform commonly last between sixty and ninety minutes, and can stretch to roughly twenty-eight hours under continuous access evaluation. Its revoke-sign-in-sessions operation may take a few minutes to take effect, and on another identity platform, ending a session at the provider does not clear sessions held inside the applications. For anything sensitive, add an application-side sign-out or a token-introspection check to the runbook, and test the delay so you know the real exposure window.
There is a related caveat worth recording: when a provisioning job is quarantined because of repeated errors, it can slow to one attempt a day and may eventually be disabled after more than four weeks. Alert on quarantine, because a stalled job means departures are silently not being processed.
Step 5: Treat disable and delete as different decisions
On one identity platform, deactivating a user is a destructive act that deprovisions every connected application, whereas suspending preserves assignments. Read the semantics carefully before choosing which action the workflow performs. In provisioning standards, the effect of marking a user inactive is left to each application, and some vendors send a delete request under certain conditions while others never do. The practical advice: map each application to what it actually does on receipt of the message, record that in the register, and verify by looking, not by trusting the log.
A related, useful read is our overview of tools that help defend against account takeover, which shows what happens when a leftover credential is found by someone else first.
Step 6: Reconcile from the application, not from the log
The most valuable control in the whole workflow is the check that the work happened. Export user lists from each application on a schedule and compare them to the list of current employees. The Atlas specifically warns against reconciling from provisioning logs, which show what was sent, not what was received. Run the reconciliation daily and treat any unmatched account as an incident to be closed, not an observation to be noted.
Then measure honestly. The Atlas gives a worked case with forty leavers, where thirty-six had the directory account disabled in time but three of them still held an active account in a lower-tier application. Judged only at the directory the result is 90.0 percent, whereas the end-to-end figure is 82.5 percent. Publish the second number.
A word on exceptions
Every real workflow needs a short list of exceptions, written before the first leaver is processed, not argued over afterwards. People on HR-approved suspension, such as extended leave, should not be swept up by dormancy rules. Emergency break-glass accounts are intentionally quiet and must be excluded from inactivity sweeps, though they deserve their own monitoring. A machine credential with a registered longer review cycle may legitimately look idle. Put each exception in the register with an owner and a review date so that it cannot quietly turn into a loophole.
Step 7: Add a drill and a calendar
Quarterly, create a dummy employee, assign them to every system, terminate them in HR and time how long each removal takes. Compare the result to the service targets: the Atlas offers four hours for the identity provider and twenty-four hours for all applications as illustrative values. Combine this with the rest of the recommended cadence, which includes weekly sampling of recovery cases and a monthly report on machine credentials about to expire, and the process stays alive.
If you are looking to wire these checks into delivery tooling, our piece on where security automation fits into a DevOps toolchain offers context.
Common mistakes to avoid
- Counting the directory only. A disabled directory entry is not an offboarded person.
- Relying on first-login provisioning. Accounts created on a first sign-in have no removal channel; the Atlas notes that a container-platform vendor recommends provisioning via SCIM with that first-login option off.
- Forgetting machine accounts. When an engineer leaves, the service credentials they created do not leave with them. Each needs a recorded owner who can be reassigned.
- Ignoring licences. Feeding accounts from HR requires a paid directory tier on one major cloud platform, lifecycle workflows call for a governance edition, and plenty of SaaS vendors reserve SCIM for their upper plans.
The shape of a good first quarter
Once ninety days have passed you should have a documented trigger, a tested sequence, a register of how each application responds, a daily reconciliation and a first drill result. That is already ahead of many organisations. The Atlas’s maturity ladder places a live HR feed with a measured leaver target at the first level and leaver compliance of ninety percent or higher at the second. Climbing further means phishing-resistant sign-in, owned machine credentials and shared-signal automation, each of which deserves its own project.
Start with the leaver. It is bounded, measurable and pays off quickly.