When offboarding ignores shadow IT, former users can keep active access to applications IT never tracked, including trials, department-managed tools, and self-service SaaS. That leaves residual access after separation even when central systems look clean. A complete leaver process needs discovery of the full access footprint before credentials are revoked.
Why This Matters for Security Teams
Offboarding breaks down when the organisation assumes central IAM is the whole identity estate. shadow it creates a parallel access layer through trial SaaS, department-owned platforms, personal sign-ups, and delegated admin accounts that never appear in the main directory. When those accounts are missed, the former user can still access data, workflows, and connected integrations long after termination.
This is not just a cleanup problem. It undermines account disablement, data retention, and legal defensibility at the same time. NHI Management Group’s Top 10 NHI Issues and NIST Cybersecurity Framework 2.0 both point to the same operational reality: asset visibility has to exist before access can be removed with confidence. In practice, many security teams only discover shadow IT after a leaver event becomes an incident, rather than through intentional discovery and control.
How It Works in Practice
A complete offboarding process starts with discovery, not revocation. Security teams need a repeatable way to identify all identities, applications, tokens, and integrations associated with the departing user, including systems outside the corporate directory. That means looking at expense reports, browser SSO histories, SaaS admin consoles, email forwards, chat integrations, and any delegated access granted through team-owned accounts. The goal is to find the full access footprint before the person is fully removed from the organisation’s operating context.
The practical sequence is usually:
- Inventory known accounts from HR, IAM, and endpoint data.
- Review shadow IT sources such as self-service SaaS and departmental tools.
- Identify API keys, OAuth grants, shared passwords, and service accounts linked to the user.
- Revoke or rotate credentials after dependencies are understood.
- Confirm deletion, transfer, or reassignment of ownership for business-critical tools.
NHI Management Group’s NHI Lifecycle Management Guide and the Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs both reinforce that lifecycle governance must include discovery, ownership, rotation, and revocation, not just central directory actions. This is also consistent with the operational intent of NIST CSF 2.0, which treats asset and access management as a prerequisite for effective protection. One relevant data point from NHI Mgmt Group’s cited research is that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why residual access persists after leavers exit.
These controls tend to break down when business units can create SaaS tenants, shared workspaces, or API integrations without central approval because there is no dependable inventory to revoke against.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance speed of separation against the effort needed to hunt down every hidden account. That tradeoff becomes more pronounced in mergers, contractor-heavy environments, and decentralised SaaS estates, where the person leaving may have created tools the central team never knew existed.
There is no universal standard for shadow IT shutdown sequencing, but current guidance suggests treating it as a discovery-and-containment exercise rather than a single IAM event. A shared mailbox, a team-owned admin account, or a personal trial account may support a business process long after the individual is gone. In those cases, the right action is not only revocation but also transfer of ownership, reassignment of secret custody, and validation that workflows still function.
The biggest edge case is when shadow IT is embedded in automation. A former user might not retain direct login access, yet their API token or webhook secret can still trigger jobs, export data, or authenticate to third-party services. That is why offboarding should include secrets review and integration mapping, not just account disablement. For teams dealing with broad NHI sprawl, Entro Security’s 2025 State of NHIs and Secrets in Cybersecurity is useful context, especially where token validity and lifecycle drift create lingering exposure. The same lesson applies in organisations with fragmented app ownership: cleanup fails when the system of record does not match the system of use.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Offboarding needs full identity and asset visibility before access can be removed. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Shadow IT often leaves unmanaged secrets and accounts active after departure. |
| NIST AI RMF | Governance needs accountability for access held outside the main IAM boundary. |
Map leaver workflows to PR.AA-01 and verify all user-linked accounts are discovered before revocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
