They should assume SCIM is only one layer of deprovisioning and design a fallback process for apps that keep their own sessions or tokens alive. If the application cannot respond to lifecycle events directly, the offboarding control must still terminate access in that app before the user is considered fully removed.
SCIM Stops the Sync, Not the Risk
SCIM is a provisioning protocol, not a complete offboarding guarantee. If a SaaS app keeps local sessions, refresh tokens, API keys, or delegated grants alive after SCIM deactivation, the user can remain effectively active. Treat the SCIM event as one signal in a broader deprovisioning workflow, not the finish line for removal.
A practical IAM pattern is to separate identity deactivation from application access termination. The former updates the source of truth, while the latter clears whatever the app still trusts, including sessions, cached tokens, and app-specific credentials. Where SaaS products expose only partial lifecycle hooks, the fallback process has to close the gap explicitly.
That gap is common in mixed estates because not every application consumes the same lifecycle event in the same way. Some apps honor inbound deprovisioning immediately, while others require an API call, admin action, token revocation, or manual evidence that access was actually removed. This is why deprovisioning needs an application coverage map, not just an SCIM connector count.
What the Fallback Process Must Actually Do
The control objective is simple: the user should lose the ability to authenticate or act in each app before offboarding is declared complete. In practice, that means IAM teams need a documented fallback for systems that do not terminate sessions on their own. The fallback should define the alternate control point, the owner, and the trigger for escalation.
For high-value SaaS, the fallback usually includes a sequence such as disabling the account, revoking sessions and refresh tokens, removing app passwords or API keys, and confirming that any federated entitlement or direct local privilege is gone. If the SaaS product cannot do all of that automatically, the process should require a compensating control and a clear completion check.
The most reliable way to run this is to classify apps by deprovisioning behavior: SCIM-complete, SCIM-partial, and non-SCIM. That classification tells the IAM team which apps can be left to automation and which ones need a secondary workflow, ticket, or integration. It also helps downstream owners understand where removal proof must be collected before the case can be closed.
How IAM Teams Should Design the Offboarding Model
Use the application, not the identity platform, as the unit of offboarding validation. If an app maintains its own sessions, tokens, or local admin grants, the IAM process must prove that those credentials or sessions were invalidated. A clean source-system deprovision does not matter if the app still honors an active token.
In mature programs, the fallback process is owned jointly by IAM, the application team, and the service desk or operations function that can execute exceptions. The operating model should define who can revoke access, what evidence counts as success, and when a failed automated deprovision becomes a control failure rather than a queue item.
For the hardest cases, define a standard exception path: shut off the identity provider path first, then force application-side revocation, then confirm no residual access remains. That order matters because many SaaS applications will continue to trust pre-existing sessions even after the user record is disabled upstream.
Risk and Threat Considerations
When SCIM only removes the directory link but leaves app-native access alive, offboarding becomes a residual-access problem. The main risk is that a former user, contractor, or compromised account can continue to access data through surviving sessions, refresh tokens, or locally issued credentials after the organization believes removal is complete.
Failure mechanism: The application continues to trust access material that the SCIM event did not revoke, so the user remains active in practice even though the central identity record shows deprovisioned.
Impact: This creates post-exit access, weakens auditability, and enlarges the window for data exposure or misuse, especially in SaaS systems that hold business records, customer data, or delegated admin rights.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | SCIM gaps are an account lifecycle and deprovisioning problem. |
| Recommendation — Map non-SCIM apps to account-management controls and require verified removal completion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Fallback offboarding must revoke tokens, keys, and other surviving authenticators. |
| AC-2 — Account Management | The question is about removing access cleanly across SaaS accounts and lifecycle events. | |
| Recommendation — Revoke surviving authenticators and validate that app access cannot persist after removal. Enforce account disabling and termination checks for every application in scope. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Offboarding must ensure access rights are removed when a user leaves. |
| Recommendation — Review and withdraw access rights for apps that SCIM does not fully cover. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud SaaS access removal and lifecycle control sit squarely in IAM governance. |
| Recommendation — Define compensating lifecycle controls for SaaS apps that do not honor SCIM end-to-end. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Residual sessions and tokens after deprovisioning are a classic offboarding failure mode. |
| Recommendation — Revoke app-held sessions and credentials before declaring non-human or app access removed. | ||
Practitioner Guidance
What to verify: For every high-risk SaaS app, verify the exact termination behavior for sessions, refresh tokens, API keys, and local roles before you trust SCIM as a complete offboarding mechanism. If the app cannot prove that access is invalidated, treat the control as incomplete.
Decision rule: If the SaaS app has any independent authentication state beyond SCIM, require a secondary revocation step and an explicit completion signal. If it does not, document that SCIM is the authoritative removal mechanism and still test the edge cases where sessions outlive directory status.
Practitioner takeaway: Offboarding is complete only when the application can no longer authorize the former user, not when the identity platform says the account was removed.
Related resources from NHI Mgmt Group
- How do IAM and IGA teams keep offboarding effective across a large SaaS stack?
- How do security teams know whether offboarding is actually removing access across the full SaaS stack?
- How do IAM teams balance SSO, SCIM, and audit logging in B2B SaaS?
- How should IAM and governance teams measure SaaS stack value?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org