Offboarding Delays and How SCIM Automates Account Removal
The real risks when leaver account removal lags, and how SCIM provisioning automates on- and offboarding to eliminate the problem structurally.
The day after an employee leaves, what if you could still log in to internal apps with their account? At many companies this is not a hypothetical but reality. The HR system has completed the offboarding, yet the actual app accounts often stay alive for days, sometimes weeks.
The risk created by delayed account removal
When offboarding lags, two problems arise at once.
One is a security risk. That a leaver can still reach the CRM, code repository, and document tools means a path for data leakage is left open. Even without malicious intent, an unmanaged active account is an attack surface in itself. The other is a compliance risk. Most security audits, including ISMS-P, check whether "unnecessary accounts were revoked in time." If a record of delayed removal remains, it becomes a finding as is.
The root of the problem is usually not the process but manual work. When a staff member opens each app's admin screen one by one to disable accounts, omissions appear once there are even ten apps. Frequently used apps get handled, but an app used once a quarter is forgotten.
How SCIM solves it
SCIM (System for Cross-domain Identity Management) is a protocol for exchanging account information between systems in a standard way. Put simply, it is a standard that automatically propagates the creation, modification, and deactivation of a user from a single source to multiple apps.
This is the general model SCIM enables: when a new hire joins, an account is created once at the center, and accounts are created automatically in the connected apps. When a role changes, you only adjust the group, and when offboarding is processed, the account is deactivated across all connected apps together. The step where a staff member goes into each app to turn things off by hand disappears.
What to check before adopting it
If you are considering SCIM, review these first.
- Which of the apps your company uses support SCIM provisioning
- Where you will place the account "source of truth"—usually the IdP plays that role
- How you will design the group and role structure—this design becomes your access policy
- Whether provisioning events are recorded in audit logs—needed for audit readiness
Apps that do not support SCIM need a separate account management approach, so splitting your app list into supported and unsupported early on makes later planning clearer.
How AxiPass helps
AxiPass provides a SCIM 2.0 API as a receiving server. From the HR system or upstream directory your company uses, you can automatically reflect account creation, modification, and deactivation into AxiPass, keeping the account source in one place and AxiPass members in sync with it. Blocking app access follows from here as an effect of IdP centralization. Disabling an AxiPass account blocks logins to every app connected via OIDC or SAML, and on offboarding the session termination propagates downstream (OIDC tokens, SAML, SWA, and the browser extension). Major events including provisioning remain automatically in the audit log for use as audit material. The token used for SCIM authentication is kept as a one-way hash, so the original is not stored after it is issued.
If you want to try offboarding automation yourself, you can begin when you start for free, and if you need a provisioning design suited to your internal app landscape, talk to us.