loading
loading
Workforce identity offboarding: A checklist to verify access removal A workforce identity offboarding checklist for IT and security teams: what to disable, revoke, transfer, and rotate in each app, and the evidence to keep. Suppose a staff engineer resigns on a Friday. HR marks her terminated, IT disables her account in the identity provider (IdP), and the ticket closes. On her laptop, chat is still open and a command-line tool holds a refresh token. A CI job uses her personal API key, and another automation runs under a grant she authorized. She also knows the shared password for a billing portal that never supported single sign-on (SSO). Each of those can outlast the disabled IdP account. This checklist is for the IT and security team running offboarding. It lists what to close, transfer, or rotate in each application when someone leaves, and the evidence that shows each step happened. If you build the app that has to act on the deprovisioning signal, SCIM deprovisioning is a promise your app probably breaks covers the developer side. Disabling the IdP account can leave sessions, tokens, delegated grants, and shared secrets usable. Why disabling the IdP account is not enough The IdP account is one of several places where access lives, and the others have to be handled separately. - Sign-in paths outside the IdP. Federated sign-in runs through the IdP. A local password, a magic link, or a personal social login set up directly in an app does not. - The account inside each app. When an app is provisioned over SCIM (System for Cross-domain Identity Management), deprovisioning can set the SCIM active attribute to false instead of deleting the user. Check how the app handles that signal. For apps built on WorkOS, Directory Sync exists to carry that state change into the app. - Permissions on any account that remains. Roles, app assignments, group memberships, and resource-level grants determine what a surviving account can still do. - Credentials already issued. A session cookie or refresh token issued before the deprovisioning event can remain usable until it expires or the app invalidates it. Under OAuth 2.0 token revocation, a revocation request invalidates the token and, where applicable, other tokens based on the same authorization grant. Personal API keys, grants that automations run under, shared passwords, and ownership of the person's resources each need their own step as well. The checklist below covers all of them. The per-application checklist The HR record and the IdP account are handled once per person. Repeat the remaining rows for every application the person could reach. For a planned departure, inventory and transfer business automation in advance. If access must end immediately, revoke it first and have the service owner recover any affected automation. Keep the checklist in the system that tracks the departure, with a set of rows for each application and a named owner on every row, so the evidence stays attached to the departure record instead of sitting in someone's personal document. The owners listed are suggestions to map onto your own org chart. Personal credentials and business automation What deprovisioning does to a token depends on how the system that issued it ties it to the user account. If a personal access token is not tied to the user's status, deprovisioning the user will not invalidate it, so a token in a CI job can keep working after the person leaves. Okta API tokens carry the opposite risk. Each is issued for a specific user, every request made with it acts on behalf of that user, and it carries that user's permissions as they change. Okta rejects tokens issued by deactivated users and recommends that tokens for ongoing work be generated by a service account that will not be deactivated. Automation running on a departing person's Okta token stops when that person is deactivated. For each credential in the inventory, decide whether it is personal access to cut or business automation to move. For a planned departure, move automation before the cutoff: create a service-owned credential, switch the job over, confirm the job succeeds, and then revoke the original. If access has to end immediately, revoke first. Removing access takes priority over keeping the job running. Waiting for tokens to expire is not a substitute. Okta API tokens, for example, are valid for 30 days, renew each time they are used, and are revoked after 30 days of inactivity, so a token that a job uses regularly keeps renewing. A token that lapsed on its own is also not evidence that anyone removed the access. Ending sessions that are already open Sign the person out in the IdP, then in each app that keeps its own sessions. An IdP-level sign-out does not necessarily end sessions that an app manages itself. In Okta, an admin can open Directory, then People, select the user, choose More Actions, select Clear User Sessions, and confirm with Clear Sessions & Revoke Tokens. That signs the user out of Okta sessions on all devices and browsers without requiring a password reset. In Microsoft Entra, the revokeSignInSessions API invalidates the user's Entra-issued refresh tokens and sign-in session cookies. Check separately for sessions maintained by each application. Microsoft documents a possible delay of a few minutes before token revocation takes effect, so do not treat the Entra call as instant. The same API does not revoke sign-in sessions for external users, because they sign in through their home tenant. RFC 7009, the OAuth 2.0 token revocation specification, allows for the same kind of lag. It specifies immediate invalidation but acknowledges that the change can take time to reach every server. It requires support for revoking refresh tokens but only recommends support for revoking access tokens. Where an authorization server does not support access token revocation, access tokens are not immediately invalidated when the matching refresh token is revoked. Provisioning has its own gap. With polling-based sync, a terminated employee can still show as active in an app until the next sync runs. Record the remaining access window for each application. Consider an app that syncs hourly and accepts self-contained access tokens, which it validates without checking back with the server. A departed user's access there can last longer than in an app with push provisioning and server-side session revocation, and the offboarding record should say which kind each app is. Apps that cannot revoke sessions or tokens Some apps have no admin session control, no token list, and no audit log. Put each one on an exceptions list with an owner, a review date, and a compensating control, instead of leaving its row unchecked. The compensating controls available are narrow. You can rotate the shared credential immediately, or restrict access to the app to network paths the former employee can no longer use. You can also open a vendor ticket asking for a forced sign-out and keep the response. Escalate to the security owner when an app holds regulated or customer data and supports none of these. Verifying and keeping evidence A closed ticket only shows that someone marked the work done. For each application, keep the action taken, who took it, the timestamp, and the available revocation logs or account-state records. Record any remaining access window, including an unknown one, as an exception that needs an owner. Keep the exceptions list in the same record, with each compensating control and review date. Check each access path and record whether it has been removed. To test the offboarding steps themselves, use an authorized identity provisioned for the purpose, never the former employee's credentials or account. Scope the test, tell the app owner before it runs, and keep its results. A test identity validates the process; it does not prove that the departed person's sessions or credentials were revoked. Keep that person's removal records separately. If you run an app on WorkOS SSO, the Sessions tab in the WorkOS Dashboard shows authentication-flow records from up to 90 days back. Those records show whether an SSO attempt succeeded, failed, or timed out. They do not by themselves prove that an existing application session or API token stopped working. Use the app's session and credential records for that check. For credentials, capture the revocation itself. Okta's System Log records API token creation and revocation with the messages "API token created" and "API token revoked". When an admin who did not create a token revokes it, the actor and target differ in the record, which lets a reviewer see that someone other than the token's creator revoked it. Removing access has one limit that no checklist row fixes. It stops new access, but it does not erase data already copied, exported, or synced to a personal device. That calls for a separate investigation with its own controls.
document fetched 2026-10-24 11:27