Accountability sits with the function that owns the workflow, not just the departing user. If HR, IT, and application owners are split, the organisation must define which team verifies revocation and which system records proof. Strong lifecycle governance requires a named owner for every offboarding step and an auditable completion record.
Why This Matters for Security Teams
When SaaS access is left active after offboarding, the issue is rarely a single missed click. It is a workflow ownership failure across HR, IT, application owners, and sometimes the business manager who approved access in the first place. The security risk is straightforward: dormant accounts and tokens retain the same privileges they had on the last day of employment, which can turn a routine departure into an active exposure. NHIMG research shows 91% of former employee tokens remain active after offboarding, a reminder that lifecycle controls often fail at handoff points rather than in the tooling itself. See The 2025 State of NHIs and Secrets in Cybersecurity and OWASP Non-Human Identity Top 10 for the broader identity and secrets risk pattern. In practice, many security teams encounter access leakage only after an audit, an incident, or a legal hold request, rather than through intentional offboarding verification.
How It Works in Practice
Accountability should be assigned to the function that owns the offboarding workflow end to end, not to the departing employee and not to security alone. In mature programs, HR triggers the workflow, IT executes account and device removal, application owners confirm SaaS-specific revocation, and the identity team records evidence that the control completed. That evidence matters because SaaS access often includes more than a username and password: session tokens, OAuth grants, API keys, SSO assignments, and delegated access can all outlive termination if they are not explicitly revoked. NHIMG’s NHI Lifecycle Management Guide is useful here because it frames offboarding as a lifecycle control, not a ticket closure.
Practitioners usually reduce failure by making the workflow auditable:
- Require a named owner for each SaaS system, with a clear revocation SLA.
- Track revocation separately for user access, privileged roles, and issued tokens.
- Store proof of completion in a system of record, not in email or chat.
- Validate that disabled accounts cannot still authenticate through cached sessions or federated grants.
Current guidance suggests this should be treated as a control handoff problem, which is why identity governance, application ownership, and security operations must share the same state view. For related lifecycle failure patterns, see Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. These controls tend to break down in federated SaaS environments because revocation must occur across multiple tenants and token types, each with different audit trails.
Common Variations and Edge Cases
Tighter offboarding control often increases coordination overhead, requiring organisations to balance fast employee exits against complete access removal. That tradeoff becomes more visible when access is granted through group membership, app-specific role mapping, or delegated admin permissions. In those cases, the responsible team cannot assume that disabling the directory account is enough. Best practice is evolving, but current guidance suggests treating every SaaS app as a separate revocation domain with its own proof requirement, especially where the platform supports API tokens, refresh tokens, or third-party integrations.
Shared accounts, contractors, and temporary project access create additional ambiguity. The right answer is still to define ownership before the offboarding event, because retroactive blame does not remove standing access. This is also where a clear inventory matters: if the organisation cannot enumerate who had access to what, it cannot prove revocation with confidence. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and Guide to the Secret Sprawl Challenge show how quickly access and secrets spread when lifecycle ownership is unclear. In edge cases like M&A, outsourced IT, or shadow SaaS, the model breaks down because the revocation owner and the evidence owner are not the same system or the same team.
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 failures often leave credentials and tokens active. |
| NIST CSF 2.0 | PR.AA-1 | Identity lifecycle control depends on timely removal of valid access. |
| NIST AI RMF | Governance requires accountability, traceability, and lifecycle oversight. |
Assign a control owner for offboarding and measure whether revocation is provable.
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
