Accountability sits with the identity and application owners who control revocation, not with the directory alone. If offboarding stops at SSO or email, residual SaaS entitlements can outlive employment. Governance should require verification that every direct application account, token, or delegated admin path has been closed.
Why This Matters for Security Teams
Offboarding is not complete when a worker leaves the directory. The real risk is the residual access that remains in SaaS apps, delegated admin roles, refresh tokens, API keys, and shared automation accounts after HR has closed the record. That gap matters because SaaS entitlements often sit outside the identity system that security assumes is authoritative. Current guidance on OWASP Non-Human Identity Top 10 treats these residual credentials as a lifecycle failure, not just a provisioning mistake.
NHI Management Group research shows the scale of the problem: in the 2025 State of NHIs and Secrets in Cybersecurity, Entro Security reports that 91% of former employee tokens remain active after offboarding. That number is not just a hygiene issue. It means accountability has to extend beyond the directory team to the owners of the application, integration, and secret that actually control access. In practice, many security teams encounter this only after an audit, incident review, or unauthorized SaaS activity has already exposed the gap.
How It Works in Practice
Accountability should be assigned to the people who can actually revoke access. That usually means the identity owner for the overall lifecycle, plus the application owner for each SaaS product and the platform owner for any token or delegated admin path. Directory admins can disable SSO, but that does not close direct logins, OAuth grants, service accounts, or saved API tokens. This is why offboarding needs a control checklist that reaches every access path, not just the primary sign-in method.
Practitioners increasingly treat this as a verification problem. The question is not whether a termination ticket was opened, but whether each credential class was confirmed dead. The strongest programs cross-check SaaS audit logs, token inventories, and admin consoles against the offboarding event, then require evidence of revocation. The Ultimate Guide to NHIs is clear that lifecycle control is central to reducing residual exposure, especially where service accounts and long-lived secrets are involved.
Useful operating steps include:
- Assign a named owner for every SaaS app and every privileged integration.
- Require revocation of direct accounts, SSO sessions, refresh tokens, and API keys as separate actions.
- Use a final offboarding validation step that compares expected closed accounts with actual SaaS account state.
- Track delegated admin and partner access separately, because these paths often bypass the directory.
- Escalate exceptions when an app cannot provide revocation evidence within the offboarding window.
Frameworks such as OWASP Non-Human Identity Top 10 and the NHI Lifecycle Management Guide both emphasize that lifecycle ownership must include revocation, not just issuance and inventory. These controls tend to break down when SaaS is purchased outside central IT because access paths, admin rights, and token issuance are then scattered across business teams.
Common Variations and Edge Cases
Tighter offboarding increases operational overhead, requiring organisations to balance revocation speed against application complexity. That tradeoff is especially visible in SaaS environments with nested roles, external collaborators, and long-lived integrations. Current guidance suggests that the answer should not be “best effort”; it should be a defined ownership model with an exception path for systems that cannot automate revocation.
There is no universal standard for this yet, but the practical pattern is consistent. If an app supports SCIM, token introspection, or admin API revocation, the application owner should prove those controls work. If it does not, the business owner should accept the residual risk explicitly. For shared inboxes, vendor portals, and delegated support tools, accountability often shifts to the department that sponsored the access in the first place, because the directory may never have been the source of truth.
This is also where saas offboarding overlaps with broader NHI governance. The same failure mode appears in service accounts, automation tokens, and stale secrets, which is why NHI programs often use the same ownership model for human departure and machine credential retirement. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same lesson: if no one owns revocation end to end, stale access survives the offboarding process.
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-01 | Directly addresses lifecycle ownership and residual credential risk after offboarding. |
| NIST CSF 2.0 | PR.AC-1 | Access management requires timely removal of credentials when employment ends. |
| NIST AI RMF | Governance and accountability principles apply to identity lifecycle decisions. |
Assign explicit revocation owners and verify every direct account, token, and admin path is closed.
Related resources from NHI Mgmt Group
- Who is accountable when a former employee still has access after offboarding?
- Who is accountable when former employees still have admin access?
- Why do former employees still keep access after offboarding in many organisations?
- Who is accountable when a leaver still has SaaS access after offboarding?
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
