> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/lifecycle/offboard-a-leaver.md). # Offboard a leaver end to end The five things that have to happen when somebody leaves, which page owns each one, and the parts OpenIAM does not automate at all. ## What this is, and when you need it Somebody has left, or is leaving on a known date, and you need their access to stop. No single screen does that. Offboarding is five separate mechanisms, owned by four sections of this guide, and each one covers a different part of the job — the identity's status, the accounts in the managed systems, the entitlements they hold, their live sessions, and their credentials. This page sequences them, says what each constituent page does and does not do, and names the parts OpenIAM leaves to you. Read it before you tell anyone that offboarding is automated on your installation. **The page titled for leavers automates the status change and nothing else.** A deployment that has enabled [Disable leavers automatically on their end date](/administration-guide/lifecycle/disable-leavers-automatically.md) and stopped there has automated roughly the first of the five steps below. ## The five parts, and who owns each | # | What has to happen | What does it | Automated? | | - | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | | 1 | The identity stops being usable | **Terminate User** on the user record, or the `LEAVER_PROCESS` batch task | Yes, once you have configured one of them | | 2 | Their live sessions stop working | Follows from 1 — session renewal refuses for a terminated, disabled or locked identity | Yes, at each browser's next request | | 3 | The accounts in the managed systems are disabled or deleted | Provisioning, driven by the lifecycle action; each managed system's `ON_DELETE` resource property decides which | Yes, per managed system — and worth verifying at the target | | 4 | Their entitlements are unwound | **Terminate User** end-dates role and group memberships only. Everything else is a separate act | **Partly.** See below | | 5 | Their credentials and second factors are retired | Nothing does this. A TOTP secret or a passkey on a device the person kept still works if you ever re-enable the identity | **No** | ## Do them in this order ### 1. Decide what changes the identity's status, and when There are two triggers and they are not interchangeable. **A person, on the day.** **Terminate User** on the user record under **User Admin → User Search** sets the status to `TERMINATED` and records `USER_TERMINATE`. This is the button to use for a resignation, a dismissal, or any case where somebody is telling you to act now — see [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md). **A date, unattended.** The `LEAVER_PROCESS` batch task — *Disable by last date*, cron `0 0 17 * * ?` — ships **enabled** and runs your leaver script against users whose **End date** falls inside a window. It **disables**; it does not terminate, and it does not touch memberships. It also selects nobody until you set **Parameter 1**, because an empty window matches no dates. Configure it on [Disable leavers automatically on their end date](/administration-guide/lifecycle/disable-leavers-automatically.md). {% hint style="warning" %} **A future-dated DeActivate or Delete is carried out by a batch task that ships disabled.** If you future-date the action on the user record instead, the user parks in `PENDING_DEACTIVATION` or `PENDING_DELETE` and stays there until `DELETE_PENDING` — *Delete/Deactivate by last Data*, cron `0 0/30 * * * ?` — is enabled. Nothing records that the action did not happen. This is the single most common way an offboarding process silently does nothing: [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md). {% endhint %} Where the trigger is an HR feed rather than a person or a date, the transformation drives it and the patterns are on [Advanced lifecycle patterns](/administration-guide/lifecycle/advanced-lifecycle-patterns.md). ### 2. Expect the sessions to end at the next request, not immediately Session renewal re-checks the identity's status on every request and refuses for a user whose status is `TERMINATED`, `DEACTIVATED`, `INACTIVE` or one of the leave statuses, or whose secondary status is `DISABLED`, `LOCKED` or `LOCKED_ADMIN`. So step 1 ends the live sessions, at each browser's next request — nothing is pushed to the browser, and a window sitting completely idle keeps looking signed in until it asks for something. There is no screen that lists or ends another person's sessions; the status change *is* the administrative path, and it is the audited one. [Terminate a user's sessions](/administration-guide/security/session-management.md) is the procedure, including the evidence to capture first, and it is what to read when the requirement is a stolen laptop rather than a leaver. Two things a session termination does not reach: an application the person is already signed in to through federation — nothing OpenIAM does sends that partner a logout — and Kerberos or certificate authentication, which re-establishes a session silently while the identity is still enabled. ### 3. Confirm the far end actually changed An OpenIAM status change is not a target change. The lifecycle action drives provisioning to every managed system the user has an identity on, and whether each account is **disabled** or **deleted** is that managed system's `ON_DELETE` resource property — absent means delete. Prefer disable where audit or correlation needs the account to survive. Check the account in each managed system, not the OpenIAM status alone, and read the per-identity child audit records rather than the parent event: a completed termination is not proof that every connector succeeded. [Configure provisioning](/administration-guide/lifecycle/configure-provisioning.md) covers the request and its recovery. ### 4. Unwind the entitlements deliberately: most of this is not automatic This is the part that gets missed, because the two automated mechanisms each cover a slice of it. | What holds access | What terminate does to it | What the leaver batch task does to it | | ------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | Role memberships | End-dates them today, or removes them when `org.openiam.workflow.termination.access.remove` is `true` (ships `false`) | Nothing | | Group memberships | The same | Nothing | | Resource entitlements | **Nothing** | Nothing | | Organization affiliations | **Nothing** | Nothing | So after a termination the person still holds every directly granted resource and every organization affiliation they had, and — with the shipped default — their roles and groups are end-dated rather than gone. Three consequences worth planning for: * **An end date is not a revocation.** `AUTO_REVOCATION` — *Notification of expiring/revoke of expired access*, cron `0 0 20 * * ?` — ships **disabled**, so an end date that passes revokes nothing until somebody enables it. * **The total actions exist, and they are total.** A business rule action of `END_DATE_ALL_ACCESS` or `DROP_ALL_ENTITLEMENTS` reaches all four collections — roles, groups, resources and organization affiliations. `DROP_ALL_ENTITLEMENTS` marks every membership for deletion and cannot be undone by re-adding a role, because it takes the affiliations that drive organization-based access with it. See [Business rule reference](/administration-guide/access/business-rules/business-rule-reference.md#broad-access-actions). * **The end-dated trail is usually what you want to keep.** The shipped `false` preserves the record of what the person held, which is what a certification or an investigation needs later. If your policy is "the leaver keeps nothing", express it as a reviewed business rule and test it on a disposable user — not as a habit of pressing **Terminate User** and assuming. ### 5. Retire the credentials, by hand Ending a session changes no credential. If the person kept a phone with a TOTP secret or a laptop with a platform authenticator, that enrolment is still valid against the identity, and re-enabling the identity later restores it. Clear the enrolment deliberately — [Add TOTP as a second factor](/administration-guide/security/totp.md) and [FIDO2 and WebAuthn](/administration-guide/security/fido2-and-webauthn.md#recover-a-lost-replaced-or-compromised-authenticator). **Reset Account** on the user record clears the password, the security questions and the secret word in one action and is not reversible; it is the blunt instrument for this, and it leaves the user in `PENDING_INITIAL_LOGIN`. ## What OpenIAM does not do for you State these in your own offboarding runbook rather than discovering them: * **"Delete" does not delete the OpenIAM record.** It sets the status to `REMOVE`. The user stays findable in the Webconsole; the accounts on the managed systems may not survive. * **No screen lists another person's live sessions**, so there is no "who is still signed in" report to attach to a leaver ticket. The `LOGIN` and `DO_LOGIN` audit events are the history that survives. * **Nothing signs the person out of a federated application** they had already reached. * **You cannot future-date an action and exclude a managed system from it.** On **DeActivate** and **Delete**, clearing **Perform now?** to reveal the date field removes the exclusion control; run it on the day, or accept that the deferred run reaches every managed system. * **A managed system with no resource behind it is silently dropped** from an exclusion list. Verify by target state. * **Data handover — mailboxes, home directories, file shares, licences** — is not modelled in OpenIAM at all. Deprovisioning an account is not archiving what it owned. ## How to prove a leaver is really gone In increasing order of strength, and none of the first three is sufficient on its own: 1. **The audit event.** `USER_TERMINATE` for the button, or `TERMINATE_USERS_BY_LAST_DATE` and one `AUTOMATIC_USER_TERMINATION` per user for the batch task, at **Administration → Log Viewer**. 2. **The stored status**, read back on the record. `PENDING_DEACTIVATION` or `PENDING_DELETE` means scheduled, not done. 3. **The entitlement list** on the user, checked against your policy — including resources and organization affiliations, which the termination did not touch. 4. **The account in each managed system**, or its absence. This is the only evidence that the connector acted. 5. **A sign-in attempt with the person's own credential**, which should now fail. Renewal refusal appears in the ESB log as *"RenewToken: user status failed for userId = %s"*. ## Related * [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md) — the **Terminate User** button, what it does to memberships, and the batch task that carries a future-dated action * [Disable leavers automatically on their end date](/administration-guide/lifecycle/disable-leavers-automatically.md) — `LEAVER_PROCESS`, its empty window, and the guards a leaver script needs * [Terminate a user's sessions](/administration-guide/security/session-management.md) — the session half, and the evidence to capture before you change anything * [Grant and revoke access](/administration-guide/identities/grant-and-revoke-access.md) — removing the entitlements a termination leaves behind * [Advanced lifecycle patterns](/administration-guide/lifecycle/advanced-lifecycle-patterns.md) — the HR-feed-driven termination, the off-cycle leaver and the rehire * [User lifecycle reference](/administration-guide/reference/user-lifecycle-reference.md) — the eleven lifecycle actions, their audit actions and the 21 statuses *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/lifecycle/offboard-a-leaver.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.