They often assume disabling the primary account is enough. In reality, offboarding must also remove app-specific accounts, revoke OAuth tokens, and confirm that shadow IT services do not retain access. If the app estate is only partially known, offboarding is partial by definition and leaves residual access behind.
Why This Matters for Security Teams
Offboarding in SaaS is often treated as a human identity task, but the real risk sits in the non-human identities tied to that user. Disabling the primary login does not automatically remove app-specific accounts, OAuth grants, service tokens, API keys, or delegated access that may still be active across connected tools. NIST Cybersecurity Framework 2.0 frames this as an access governance problem, not just an account closure step.
The practical failure is inventory blindness. If the app estate is incomplete, offboarding cannot be complete. Shadow IT, embedded automations, and SaaS-to-SaaS connectors frequently retain access after the employee is gone. NHI Management Group research shows how common this gap is: in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, only 20% of organisations reported formal processes for offboarding and revoking API keys. In practice, many security teams encounter lingering access only after an audit, a breach review, or a vendor incident has already exposed it.
How It Works in Practice
Effective saas offboarding has to follow the identity chain, not just the primary directory record. That means identifying all accounts the person used, all applications that trusted their session, and all machine credentials that were issued on their behalf. The NHI Lifecycle Management Guide is useful here because it treats revocation, rotation, and validation as separate steps rather than a single disable action.
A defensible offboarding workflow usually includes:
- Disable the human account in the IdP and confirm downstream SaaS synchronisation.
- Revoke OAuth refresh tokens, session tokens, and app passwords where supported.
- Remove app-specific users, bot accounts, and delegated admin roles.
- Rotate shared secrets, API keys, and certificates that could have been copied or cached.
- Check SaaS audit logs for connected integrations, SCIM links, and automation rules.
- Verify that shadow IT tools, personal workspaces, and unmanaged SaaS tenants do not still trust the departed identity.
This is where the issue becomes an NHI problem. Secrets and tokens often outlive the employee who requested them, and SaaS apps frequently lack a universal revocation model. The Top 10 NHI Issues highlights lifecycle gaps because short-lived intent is rarely enforced across the whole stack. NIST guidance on access control and event response supports the same direction: offboarding must be verified, not assumed. These controls tend to break down when organisations have no authoritative inventory of connected apps because revocation can only reach systems that are known and governed.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance rapid user exit against complete dependency cleanup. That tradeoff matters most in SaaS estates with self-service app sign-up, duplicated admin roles, or heavy use of automation. Best practice is evolving, but current guidance suggests treating every SaaS connection as potentially persistent until proven otherwise.
Two edge cases cause repeated misses. First, delegated access through vendors or partners can remain active even after the employee leaves, especially when the SaaS platform supports long-lived service integrations. Second, shared team accounts blur ownership, so no single user removal actually removes the access path. The same risk appears in real incidents such as the Salesloft OAuth token breach, where token persistence became the problem, not the login itself.
Where organisations have mature identity governance, offboarding should include post-exit validation: confirm token revocation, confirm connector deletion, and confirm no residual trust relationships remain. If that validation cannot be performed, the offboarding event is only partially complete. That limitation is especially severe in SaaS environments with multiple admin consoles and no single source of truth.
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 | Offboarding must revoke NHI credentials, tokens, and app-specific access. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be removed across connected SaaS systems, not just the IdP. |
| NIST AI RMF | AI RMF supports governance of autonomous SaaS automations and delegated access risk. |
Map offboarding to access removal checks across every integrated application and connector.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
