Who is accountable when SSO leaves users active after offboarding?

Why This Matters for Security Teams

Offboarding failures are rarely an SSO problem alone. Identity providers can disable the primary login, but applications, service integrations, and delegated access paths may still remain active. That means accountability has to be shared across the identity owner, the application owner, and the governance process that proves removal actually happened. Current guidance from the NIST Cybersecurity Framework 2.0 reinforces that access governance is an outcome, not a single control event.

This is especially important where SSO is treated as a finish line instead of a control layer. NHIMG research shows the problem is not theoretical: the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, while many still leave long-lived access behind. That pattern applies to human offboarding too, because connected applications often retain their own session state, tokens, or local entitlements after the directory record is closed. In practice, many security teams discover stale access only after an audit, an incident, or a failed deprovisioning test rather than through intentional lifecycle verification.

How It Works in Practice

Accountability should be assigned to the people who can actually remove access in each layer. The identity owner is responsible for directory-side deprovisioning, account disablement, and policy enforcement in the SSO stack. The application owner is responsible for ensuring the app honors those events, removes local entitlements, and invalidates sessions, refresh tokens, and application-specific accounts. Governance or GRC teams should verify that both steps occurred and that evidence exists for each connected system.

A practical offboarding control set usually includes:

• Triggering deprovisioning from the source of truth, then confirming the identity is disabled in the directory.
• Checking each integrated application for local accounts, role assignments, and cached sessions that SSO does not automatically remove.
• Revoking non-SSO access paths such as API keys, recovery tokens, shared inboxes, and delegated admin rights.
• Logging proof of removal, including timestamps, system owner, and verification results.
• Running periodic exception reviews for applications that do not support automated deprovisioning.

The NHI Lifecycle Management Guide is useful here because the same lifecycle discipline applies: access must be created, monitored, rotated, and removed with evidence at each stage. For identity programs, that means offboarding cannot rely on a single IdP event. It needs reconciliation between the directory, the SaaS application, and any downstream systems that maintain their own authorisation state. Organisations that align this with NIST Cybersecurity Framework 2.0 tend to define clear ownership for asset, identity, and access governance rather than treating SSO as the control owner.

Where this guidance breaks down is in legacy and federated environments where applications do not support SCIM, lack deprovisioning hooks, or preserve sessions independently of the IdP.

Common Variations and Edge Cases

Tighter offboarding controls often increase operational overhead, requiring organisations to balance assurance against application complexity. That tradeoff becomes visible when hundreds of SaaS tools, custom apps, and partner portals each implement SSO differently. Best practice is evolving, but there is no universal standard for proving offboarding across every connected system.

Some edge cases require extra handling. Shared accounts may still be used by teams after an employee leaves, which shifts the control problem from offboarding to account redesign. Federated apps can appear deprovisioned in the IdP while retaining local admin roles. Long-lived refresh tokens may continue to work until explicitly revoked. Service-linked user accounts and delegated access can also survive the employee lifecycle unless they are mapped to a separate owner.

NHIMG research highlights why this discipline matters: the Top 10 NHI Issues identifies lifecycle gaps and excess standing access as recurring failure modes across modern identity estates. For that reason, organisations should treat offboarding as a verified workflow, not a checkbox. The accountable parties are the identity owner, the application owner, and the control owner who requires evidence that access was removed everywhere it existed. In practice, the gap is usually found in the applications that were never fully integrated into the SSO program.

Related resources from NHI Mgmt Group

• Who should be accountable when SaaS access persists after offboarding?
• Who is accountable when user access remains active after offboarding?
• Who is accountable when server access remains active after offboarding?
• Who is accountable when offboarding leaves SaaS access active?