Accountability sits with the organisation that owns the lifecycle process, not with the departing employee. In practice, that means HR, IAM, IT operations, and application owners must each own a defined part of revocation and confirmation. If no one owns the final closure check, residual access becomes a predictable outcome.
Why This Matters for Security Teams
When a leaver still has SaaS access after offboarding, the failure is rarely a single missed click. It is a lifecycle breakdown across HR, IAM, IT operations, and the application owner who should have confirmed revocation. That matters because SaaS access often includes tokens, refresh tokens, delegated permissions, and connected integrations that survive the user relationship itself. The issue is broader than human departure: the same offboarding blind spots appear in service accounts and other non-human identities, which is why the Ultimate Guide to NHIs treats lifecycle governance as a core control area.
NHIMG research shows the scale of the problem: only 20% of organisations have formal processes for offboarding and revoking API keys, and 91% of former employee tokens remain active after offboarding, according to The 2025 State of NHIs and Secrets in Cybersecurity by Entro Security. That is a governance gap, not an employee misconduct issue. In practice, many security teams discover residual access only after a SaaS audit, an incident review, or an external notification has already exposed the failure.
How It Works in Practice
Accountability should be assigned by lifecycle stage, not by hope. HR should trigger the leaver event. IAM should disable directory access and identity federation. IT operations should remove device trust, mailbox forwarding, and endpoint access. The application owner should confirm SaaS deprovisioning, token revocation, and removal from shared spaces, automated workflows, and admin groups. That division of responsibility aligns with the principle behind the OWASP Non-Human Identity Top 10: credentials and access paths must be governed as living attack surfaces, not one-time setup artifacts.
In mature environments, offboarding is a controlled workflow with checkpoints, timestamps, and evidence. The practical steps usually include:
- Triggering termination events from HR into IAM and ticketing systems
- Revoking SSO sessions, OAuth grants, refresh tokens, API keys, and app passwords
- Removing the user from SaaS admin roles, shared mailboxes, and group-based entitlements
- Validating that connected integrations no longer use the leaver’s identity
- Recording a closure check owned by a named control owner, not a generic queue
This is also where non-human identity governance and human offboarding converge. The same lifecycle discipline described in the NHI Lifecycle Management Guide applies when SaaS access is backed by tokens or service-linked credentials. Current guidance suggests that revocation must be paired with verification, because disabling the account alone does not necessarily invalidate all active authorisations.
These controls tend to break down in federated SaaS environments with shadow admins, delegated OAuth consent, and unmanaged app-to-app trust because the visible account is not the full access path.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, requiring organisations to balance speed of termination against completeness of revocation. That tradeoff becomes sharper in mergers, contractor exits, and emergency terminations, where access must be removed quickly but evidence still matters.
Best practice is evolving for SaaS apps that maintain their own session stores or issue long-lived tokens outside central IAM. In those environments, it is not enough to close the directory account and assume the SaaS provider will sync instantly. Some platforms require explicit token invalidation, tenant-level administrative action, or manual confirmation from the application owner. Where single sign-on is in place, federated login may disappear fast, but pre-existing sessions, mobile tokens, and API grants can remain active unless they are revoked separately.
The accountability model also changes for shared mailboxes, team drives, and delegated admin rights. These are not “owned” by the leaver, so ownership must sit with the receiving team or the service owner. That is why evidence-based closure is important: one person closes employment; another closes access; a third verifies that no residual SaaS sessions remain. When the process depends on assumptions, offboarding failures are usually found after a data exposure, not during the termination workflow.
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 | Leaver access often persists through unmanaged credentials and tokens. |
| NIST CSF 2.0 | PR.AC-4 | Access revocation and least privilege are central to offboarding accountability. |
| NIST AI RMF | Governance and accountability are essential for automated access decisions and lifecycle controls. |
Define accountable owners for identity lifecycle decisions and evidence collection across automated workflows.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
