Why do SSO-based offboarding processes sometimes leave access behind?

Why This Happens During Offboarding

SSO-based offboarding often removes the front door but leaves side doors open. A user can lose access to the identity provider while still holding a valid session cookie, an app-issued refresh token, or a direct entitlement inside the SaaS platform. That gap is especially common when offboarding only targets the directory and not the application layer. NHI Management Group’s Ultimate Guide to NHIs notes that offboarding failures are a recurring lifecycle issue, not an edge case.

The practical problem is that SSO is an authentication control, while offboarding must also address authorization, session state, and downstream credentials. If the application maintains its own identity record, access can persist until the app receives a deprovisioning event or the session naturally expires. OWASP’s Non-Human Identity Top 10 treats lifecycle and credential governance as first-order risks for the same reason: revocation has to reach every place access exists, not just the SSO boundary. In practice, many security teams discover this only after a departing user logs back into a business app days later, rather than through intentional verification of the full offboarding path.

How SSO Revocation and Session Termination Should Work Together

Effective offboarding requires three layers to move in sync: identity removal, session invalidation, and entitlement cleanup. The SSO provider should disable authentication, but the application should also revoke active sessions, invalidate refresh tokens, and remove direct app permissions that bypass federated login. Where the application supports SCIM or native deprovisioning, that path is usually the cleanest way to force state consistency. Where it does not, current guidance suggests compensating with API-driven revocation, token rotation, and periodic access reconciliation.

For practitioners, the useful question is not whether SSO was disabled, but whether the former user can still perform actions inside the application. That means checking:

• whether the app keeps its own session alive after SSO logout
• whether API keys, personal access tokens, or app passwords remain valid
• whether group membership or role mapping continues to grant access
• whether mobile, desktop, or long-lived browser sessions are exempt from immediate revocation

NHI Management Group’s NHI Lifecycle Management Guide is clear that lifecycle control must cover creation, use, rotation, and offboarding, not just initial provisioning. That same logic applies to human users when SaaS apps issue their own bearer tokens. NIST’s Zero Trust Architecture also reinforces the need for continuous verification rather than trust based on a single login event. These controls tend to break down in federated SaaS estates with disconnected admin consoles because each app enforces revocation on a different schedule.

Common Gaps, Edge Cases, and What to Verify

Tighter offboarding control often increases administrative overhead, requiring organisations to balance faster revocation against application compatibility and support burden. Best practice is evolving, because there is no universal standard for how every SaaS platform should terminate sessions or invalidate downstream tokens.

Two edge cases matter most. First, some applications treat SSO only as a login method and keep authorization entirely local, so disabling the IdP account does not remove the app role. Second, some sessions are intentionally long-lived for offline access or mobile sync, which means a former employee may retain access even after central identity removal. The right response is to inventory which applications have native deprovisioning, which rely on SCIM, and which need manual or scripted session cleanup. NHI Management Group’s Top 10 NHI Issues highlights the broader governance pattern: access risk persists whenever lifecycle controls are fragmented.

A practical offboarding checklist should confirm that SSO disablement, application entitlement removal, token revocation, and session expiration all occurred, then verify with a post-offboarding access test. Where the application lacks revocation APIs or supports separate local accounts, the residual access problem is structural, not procedural. That is why teams should treat SSO as one control in the chain, not the entire offboarding process.

Related resources from NHI Mgmt Group

• Why do IAM tools still leave access risk behind after offboarding?
• Why do manual offboarding checklists so often leave access behind?
• Why do organisations need post-offboarding access reviews?
• When should organisations prioritise offboarding over new access features?