Why it matters
Incomplete deprovisioning is one of the fastest ways identity risk accumulates. A disabled IdP account can still leave local application accounts open. Shared credentials may remain. API keys and service accounts tied to a person can outlive the role that justified them.
Security and compliance teams care about deprovisioning because residual access is both an attack path and an audit finding. Business teams care because leftover licenses and lingering privileges create operational noise. Identity teams care because every missed leaver becomes tomorrow's orphaned account.
The hardest deprovisioning work sits in disconnected applications, where there is no SCIM disable event to send.
Example
An employee leaves on Friday. By Friday evening the IdP account is suspended and mailbox access is gone. On Monday the former employee still has an active login to an on-prem document workflow tool that was never connected to the IGA. That missed disable is a deprovisioning failure.
How it is typically handled (and where it breaks)
Connected apps are usually handled well: the IGA or IdP emits a disable or delete through SCIM or a connector. Everything else depends on offboarding checklists, ITSM tickets, and application owners. Those steps race against the person's last day and often lose for low-visibility apps.
Access certifications can catch leftovers later, but that is detection after the fact, not timely revocation.
How Redblock handles it
When a leaver or revoke event is approved, Redblock can execute removal inside disconnected and no-API applications, then verify that the account or entitlement is gone. Evidence flows back to the governance platform so teams can show that offboarding reached the application itself.
This pairs naturally with orphan discovery. Aggregation finds accounts that should not exist. Deprovisioning removes them under the same control model. Explore orphan-account cleanup and how Redblock executes identity changes.
Timing matters as much as completeness. Access that lingers for days after termination is a different risk profile than access removed within minutes. Identity teams set aggressive SLA targets for leavers, then discover those SLAs only apply where connectors exist.
Deprovisioning also intersects with standing privileges and shared accounts. Removing a named user is straightforward in theory. Cleaning up group memberships, local admin roles, and credentials the person could still use is harder when the application model is opaque.
High-performing teams combine automated disables for connected apps with a hard deadline checklist for the rest, then reconcile with aggregation. The checklist approach still fails when the list of apps is incomplete or when owners do not execute on time.
Related terms
- Joiner-Mover-Leaver (JML)
- Orphaned Accounts
- Access Certification
- Last-Mile Provisioning
- Disconnected Applications
Frequently Asked Questions
Is disabling an IdP account enough to deprovision a user?
It is necessary but often not sufficient. Applications with local accounts outside federation can remain accessible until those accounts are disabled in the app.
How is deprovisioning different from access certification?
Deprovisioning is the act of removing access. Access certification is a periodic review that decides whether access should still exist. Reviews often trigger deprovisioning when access is rejected.
Can Redblock deprovision without an API?
Yes. Redblock agents can perform approved removals through application interfaces, verify the result, and return audit evidence.