Accountability usually spans IAM, application owners, and the teams that manage SaaS integrations, because the failure sits between directory disablement and downstream revocation. If one team assumes another closed the loop, phantom access persists. The control owner must be explicit for every credential type.
Why This Matters for Security Teams
When an offboarded identity still reaches data, the problem is rarely a single missed disable action. The break usually sits across IAM, application configuration, SaaS connectors, and any secret or token that outlived the directory record. That is why accountability must be explicit for each credential type, not implied by job title or team boundary. The OWASP Non-Human Identity Top 10 treats lingering credentials and weak lifecycle control as first-order risks, while NHI Mgmt Group notes in the Ultimate Guide to NHIs that only 20% of organisations have formal processes for offboarding and revoking API keys.
That matters because offboarding is not just an HR event. A human account can be disabled while a service account, refresh token, OAuth grant, cached session, or third-party integration keeps working. The failure mode is especially common in SaaS and hybrid environments where one team owns the directory, another owns the application, and a third owns the secret store. In practice, many security teams encounter phantom access only after a former user has already retained a live path into sensitive data.
How It Works in Practice
Accountability starts by mapping every access path back to a named control owner. For human identities, that often includes IAM and the HR offboarding workflow. For machine access, it includes application owners, platform teams, and the team that owns the secret or token lifecycle. The operational question is not “who disabled the user,” but “who revoked every credential and session that could still authenticate.” The Lifecycle Processes for Managing NHIs research link is useful here because lifecycle control is where revocation often fails.
A sound process usually includes:
- Directory disablement for the human account or source identity.
- Revocation of API keys, OAuth grants, refresh tokens, certificates, and service account passwords.
- Session invalidation in the target application or SaaS tenant.
- Verification that downstream integrations no longer accept the identity.
- Logging and ticket closure only after evidence of revocation exists.
Current guidance suggests that teams should treat offboarding as a cross-system control, not a single action. Standards like OWASP Non-Human Identity Top 10 and NIST identity guidance both support least privilege and timely credential invalidation, but there is no universal standard for exactly which team must own each step. The practical answer is to assign one accountable owner per credential class, then define downstream responders for each connected system. These controls tend to break down when SaaS apps issue long-lived tokens and no central inventory exists for where those tokens are stored or used.
Common Variations and Edge Cases
Tighter offboarding control often increases operational overhead, requiring organisations to balance fast user exits against the need to revoke every live credential. That tradeoff is especially visible in federated SaaS, delegated admin models, and shared service accounts, where the directory owner may not control the actual access token. In those environments, accountability is still needed, but the closure path is more distributed.
One common edge case is delegated access granted through an external app marketplace or SCIM-style provisioning pipeline. Another is a shared mailbox, integration user, or bot account that was never tied cleanly to one person. Best practice is evolving, but current guidance suggests documenting a single accountable owner, a backup approver, and a verification checkpoint for every identity class. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how often weak lifecycle control turns into persistent exposure, and the Key Research and Survey Results underline the scale of the problem.
Where the standard answer breaks down most is in shadow integrations: the account is offboarded in one system, but a connected tool still trusts the old credential because nobody owns that trust relationship.
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 | Offboarding failures often come from lingering non-human credentials and tokens. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed across systems, not only in the directory. |
| NIST AI RMF | Governance requires clear accountability for identity lifecycle decisions and failures. |
Inventory every credential path and revoke each secret, token, and account at offboarding.
Related resources from NHI Mgmt Group
- Who is accountable when an orphaned AI agent keeps accessing live data?
- Who is accountable when a machine identity exposes cardholder data?
- Who is accountable when a vendor identity failure exposes institutional data?
- Who is accountable when a non-human identity deletes production data through a valid token?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
