Accountability sits with the identity, security, and application owners who define the workflow and the revocation path. If a departing user still has access, the failure is usually a governance one: no enforced owner, no tested deprovisioning path, or no closure on outstanding entitlements.
Why This Matters for Security Teams
Offboarding is not a paperwork issue. When SaaS access stays active after a user leaves, the organisation is left with an identity that no longer has a business owner, but still has valid entitlements, sessions, and sometimes API tokens. That creates avoidable exposure across collaboration tools, finance systems, source control, and admin consoles. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong indicator that revocation gaps are usually systemic, not exceptional.
The accountability question matters because SaaS deprovisioning spans HR, identity governance, security operations, and the application owner. If any one of those groups assumes another has closed the loop, the user remains active. That is why the real control is not just an offboarding checklist, but an enforced workflow with named ownership and verification. The OWASP Non-Human Identity Top 10 is useful here because the same lifecycle failures that affect machine identities also show up in human departure processes, especially where access is federated across multiple SaaS platforms. In practice, many security teams discover the gap only after an audit, an incident, or a former employee still present in a production tenant.
How It Works in Practice
Clear accountability usually starts with an access lifecycle owner who can drive revocation across systems rather than stopping at account disablement in the directory. The identity team typically owns the control plane, security defines the standard, HR triggers the event, and the SaaS application owner confirms that application-specific access, roles, linked tokens, and delegated permissions are removed. Where automation exists, the best pattern is event-driven deprovisioning: HR termination event, directory disablement, SaaS connector action, token revocation, and verification evidence.
Practitioners should treat offboarding as both an identity problem and a secrets problem. A user may lose interactive login while retaining refresh tokens, OAuth grants, shared mailbox access, or admin roles in connected apps. NHI Management Group’s NHI Lifecycle Management Guide is relevant because the same lifecycle discipline applies: create, use, monitor, revoke, and verify closure. For implementation, teams often align with the OWASP Non-Human Identity Top 10 and tie revocation to policy, not memory.
- Define one accountable owner for offboarding completion, not just for initiation.
- Require automatic revocation for SaaS roles, tokens, and app-specific grants.
- Log and verify closure, including evidence that access was removed from the target tenant.
- Review orphaned accounts and delegated access as part of continuous access governance.
Where this guidance breaks down is in decentralized SaaS sprawl, especially when departments buy tools outside central identity governance and app owners cannot inventory downstream entitlements.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, so organisations have to balance speed of termination against the cost of false positives and manual cleanup. Best practice is evolving, but there is no universal standard for whether identity, security, or the application owner should be the final approver in every case; the practical answer depends on who can actually revoke access in the target system.
Edge cases appear when access is inherited through group membership, shared service accounts, SCIM delays, or third-party integrations that cache tokens outside the main directory. In those environments, disabling the primary account does not guarantee removal of effective access. The 52 NHI Breaches Analysis and related breach reporting show how often lifecycle gaps and credential persistence turn into real exposure. The important operational takeaway is that accountability must extend beyond the HR exit event to include verification of every connected SaaS entitlement and every token path. If the organisation cannot prove revocation, it should assume access still exists.
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 | Covers lifecycle and revocation failures that leave access active. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and removed when no longer needed. |
| NIST AI RMF | Accountability and lifecycle governance are core AI RMF governance principles. |
Assign a named owner to revoke, verify, and evidence every SaaS entitlement at offboarding.
