SCIM Provisioning: The Part Everyone Forgets
Sample post — replace with your own writing.
When teams adopt SCIM, the celebrated moment is provisioning: a new hire appears in the IdP and, minutes later, accounts materialize across a dozen SaaS apps. It demos beautifully. It is also the easy half of the problem.
The half that ends up in audit findings is deprovisioning.
The asymmetry
Provisioning failures are loud — someone can’t log in on day one and files a ticket. Deprovisioning failures are silent. A contractor’s account lingers for months after their engagement ends, and nobody notices until a security review asks, “who is this, and why do they still have access?”
That asymmetry is exactly why deprovisioning deserves more design attention, not less.
Design the offboarding path first
Before you wire up a single Create operation, answer the deprovisioning questions:
- When a user is disabled in the IdP, does the app deactivate or merely stop new sign-ins? (Soft-delete vs. hard-delete matters for licensing and audit.)
- What happens to data ownership when the account is removed?
- Does the app honor SCIM
active: false, or does it need an explicit delete?
If you can describe the full lifecycle from active: true to fully removed, the
provisioning side tends to fall out for free.
Verify with the boring test
The test nobody runs: disable a real (test) account in the IdP and confirm the downstream app actually revokes access within the SLA you promised the auditors. Do it on a schedule, not once at go-live. Integrations rot quietly, and a deprovisioning path that worked last quarter is exactly the kind of thing that breaks without a sound.
Joiner-mover-leaver is one process, not three. The leaver step is the one that keeps you out of the incident report — so build it first.