SSO offboarding removes a user from the corporate identity system, while full SaaS lifecycle revocation also disables local SaaS accounts, tokens, integrations, and shares that exist inside the application. The difference matters because many SaaS access paths are created outside the directory and survive after SSO closure.
Why This Matters for Security Teams
SSO offboarding is only a directory action, so it rarely reaches the identities and permissions that SaaS platforms create after login. Full SaaS lifecycle revocation is broader: it must remove local users, API tokens, OAuth grants, service accounts, shared links, and app-specific integrations that can continue to operate after the corporate account is closed. That distinction is central to NHI governance because the risk is not just login access, but retained machine-to-machine reach inside the application.
This is where many teams underestimate exposure. NHI lifecycle failures are common across SaaS, and the The 2025 State of NHIs and Secrets in Cybersecurity research shows that 91% of former employee tokens remain active after offboarding, which is exactly the kind of gap that SSO-only processes leave behind. OWASP’s OWASP Non-Human Identity Top 10 also treats lifecycle and revocation as first-class controls, because unmanaged non-human access can survive long after a human account is disabled. In practice, many security teams discover the residual SaaS access only after an incident review, not through intentional offboarding.
How It Works in Practice
Effective offboarding needs two layers. First, the identity provider must disable the user or contractor account so SSO can no longer authenticate the person. Second, each connected SaaS application must be queried and cleaned up for anything it created locally. That usually includes app-native usernames, delegated admin roles, refresh tokens, API keys, service credentials, support shares, and any automations tied to the departing user.
A practical workflow usually looks like this:
- Disable directory access and revoke active sessions at the IdP.
- Call the SaaS app’s revocation endpoints, if available, to remove tokens and connected apps.
- Delete or transfer app-local ownership for dashboards, documents, and shared spaces.
- Rotate any shared secrets or integration keys the user could reach.
- Validate that exports, webhooks, and scheduled jobs no longer run under the old identity.
For lifecycle discipline, the NHI Lifecycle Management Guide is the clearest starting point, and the Top 10 NHI Issues page explains why over-permissioning and visibility gaps make revocation incomplete. Where SaaS exposes no reliable revoke API, current guidance suggests compensating controls such as mandatory token rotation, admin-owned app inventories, and post-offboarding verification. That aligns with the OWASP Non-Human Identity Top 10 focus on inventory, secrets hygiene, and deprovisioning. These controls tend to break down in highly federated SaaS estates because ownership is split across business units and no single system has complete revocation authority.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, requiring organisations to balance security assurance against SaaS administration effort. The biggest tradeoff appears when the app is not fully tied to SSO. In those environments, SSO offboarding may look complete from the directory view while the app still retains a live local account, a long-lived refresh token, or a shared integration credential.
There is no universal standard for this yet, so teams usually adapt controls based on how the SaaS is integrated. For example, if a platform supports SCIM, deprovisioning can be automated more reliably. If it does not, the offboarding playbook should require a manual check for local ownership, external sharing, and application-specific tokens. This matters especially for collaboration tools, CRM systems, and SaaS admin consoles where the departing user may have created automation or delegated access outside central IAM. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce why long-lived credentials and duplicated access paths make revocation harder than simple account closure.
For audit-ready programmes, best practice is evolving toward application-level attestation: prove that the user has no local SaaS residue, not just that the directory account is disabled. That is the practical difference between offboarding a person and revoking the identity footprint they left behind.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle revocation depends on removing tokens and app-local access, not just SSO closure. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review is needed to remove residual SaaS entitlements after offboarding. |
| NIST AI RMF | Governance is needed when revocation spans multiple systems and owners with incomplete visibility. |
Assign accountability for cross-SaaS revocation and require evidence of app-level access removal.
Related resources from NHI Mgmt Group
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between rotating a secret and revoking access?
- What is the difference between rotation and deprovisioning for NHIs?
- What is the difference between rotating service account credentials and reducing service account risk?
