How should security teams handle offboarding when SaaS apps are outside SCIM coverage?

Why This Matters for Security Teams

When SaaS applications sit outside scim coverage, offboarding stops being a directory task and becomes an access assurance problem. Disabling the IdP account may cut off one path, but it does not automatically revoke cached sessions, delegated OAuth grants, API tokens, or browser-persistent access. That gap is exactly where leaver risk survives. NHIMG’s NHI Lifecycle Management Guide treats lifecycle closure as a control objective, not an admin step, because every credentialed path must be accounted for.

This is especially important in SaaS estates with shared tenants, shadow integrations, and app-specific account stores. The 2025 State of NHIs and Secrets in Cybersecurity report from Entro Security shows that 91% of former employee tokens remain active after offboarding, which underscores how easily access can outlive employment if revocation is not explicitly verified. In practice, many security teams discover the missed access only after a former user has already retained a working session, not through a clean deprovisioning workflow.

How It Works in Practice

Offboarding without SCIM coverage works best when security teams split the process into two layers: identity deactivation and application-specific revocation. The first layer is handled by the IdP or directory, which should disable the user, end SSO access, and remove group-based entitlements. The second layer must be a named fallback per application, because each SaaS product may handle sessions, tokens, and local accounts differently.

A practical offboarding runbook usually includes the following steps:

• Disable the primary directory account and confirm the user can no longer authenticate through SSO.
• Revoke active sessions, refresh tokens, API keys, and delegated OAuth grants inside the SaaS app.
• Remove the user from any local app-specific roles or direct assignments that bypass the IdP.
• Invalidate browser trust, device trust, or persistent login state where the product supports it.
• Record evidence that revocation completed, then verify access from an external test or audit check.

That workflow aligns with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement and revocation evidence matter. It also reflects the lifecycle discipline highlighted in NHIMG’s Top 10 NHI Issues, because stale access often persists where accounts, tokens, and app permissions are managed separately.

For high-risk applications, some organisations also terminate active sessions at the network layer or use browser-enforced cut-off tools if the SaaS platform has weak admin APIs. Current guidance suggests treating that as a compensating control, not a replacement for app-level revocation. These controls tend to break down when the SaaS app has no admin audit trail and no reliable session invalidation, because proof of removal becomes hard to verify.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance assurance against manual effort. That tradeoff is especially visible when dozens of non-SCIM apps each need different revocation steps, owners, and evidence formats. Best practice is evolving, but there is no universal standard for this yet, so the control set should be risk-based rather than identical across every application.

Edge cases usually include contractor accounts, shared service logins, and SaaS apps where authentication is tied to an external identity but authorisation lives locally. In those cases, IdP disablement may be necessary but not sufficient, because the application can still honour pre-existing tokens or local sessions. The strongest pattern is to maintain an offboarding registry that maps each non-SCIM app to a fallback revocation method, a business owner, and a verification step.

For teams building a stronger lifecycle program, NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for aligning closure steps with lifecycle governance, while the Entro Security research is a reminder that stale tokens are not a theoretical issue. The hardest environments are those with decentralized app ownership and no reliable app admin path, because offboarding then depends on human follow-through instead of enforceable technical revocation.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should security teams handle SaaS offboarding when non-human identities are involved?
• How should security teams handle SaaS offboarding when users also use AI tools?
• How should security teams handle local accounts in cloud and SaaS apps?