They focus on inactivity instead of access residue. An account can be unused and still dangerous if it keeps admin groups, delegated access, or long-lived tokens. Cleanup has to look at what the identity can still touch, not only whether someone has logged in recently.
Why This Matters for Security Teams
Dormant account cleanup is often treated as a housekeeping task, but it is really an access-residue problem. An identity can be inactive and still retain admin group membership, delegated mailbox access, API tokens, or linked service permissions. That means the real exposure sits in what the account can still reach, not whether it has logged in recently. NIST’s NIST Cybersecurity Framework 2.0 frames this as a continuous governance issue, not a one-time purge.
For non-human estates, the risk is sharper. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges. That combination makes inactivity a weak signal if standing access remains in place. The same pattern shows up in privilege-residue incidents such as Azure Key Vault privilege escalation exposure, where access pathways outlast the original business need.
In practice, many security teams discover dormant-account risk only after a stale identity is reused, reactivated, or chained into a broader privilege escalation path rather than through intentional cleanup.
How It Works in Practice
Effective dormant-user cleanup starts with an entitlement inventory, not a login report. Security teams should review what each account can still touch across directory groups, cloud roles, application entitlements, shared folders, mailbox delegation, and any long-lived credentials or tokens. The goal is to identify whether the identity has retained privilege residue that survives inactivity. The operational model aligns with continuous access review guidance in NIST Cybersecurity Framework 2.0, but the cleanup logic must go deeper than standard recertification.
- Flag accounts inactive for a policy-defined period, then inspect effective permissions before disabling or deleting them.
- Check for inherited access, nested group membership, application roles, and delegated admin rights.
- Revoke tokens, keys, certificates, and session grants tied to the identity, not just the login credential.
- Confirm whether the identity is linked to automation, shared workflows, or break-glass paths before removal.
- Require an owner and an offboarding record for every exception that remains active.
For NHIs and agentic workloads, the same logic applies with even less tolerance for static assumptions. NHIMG’s Ultimate Guide to NHIs highlights how secrets, rotation, and offboarding failures create durable exposure even when the workload appears idle. Current guidance suggests using short-lived credentials and workload identity where possible, because an unused secret is still an exploitable secret if it remains valid. These controls tend to break down in hybrid estates with delegated administration and multiple identity stores because permissions are fragmented and ownership is unclear.
Common Variations and Edge Cases
Tighter cleanup often increases operational friction, requiring organisations to balance reduced attack surface against business continuity and audit overhead. That tradeoff matters because not every dormant account is disposable on the same schedule. Some are tied to archival systems, vendor support access, legal holds, or break-glass roles, and best practice is evolving on how aggressively those should be retired versus preserved under extra controls.
The biggest edge case is shared or inherited access. A user may appear dormant while still owning a team resource, a workflow connection, or a delegated permission chain that other systems depend on. Another common exception is service-linked human accounts used for automation, where inactivity does not equal harmlessness. In those cases, current guidance suggests reclassifying the identity, binding it to an owner, and moving it to a reviewed exception list rather than leaving it in the standard disable queue.
NHIMG’s research on Azure Key Vault privilege escalation exposure is a reminder that lingering access paths matter more than visual status in a directory. The practical test is simple: if the account can still authenticate, authorize, or inherit privileges, it is not really dormant from a security perspective.
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 | Dormant identities still pose risk when secrets and access are left valid. |
| NIST CSF 2.0 | PR.AC-4 | Access review and least-privilege controls directly address dormant account residue. |
| NIST AI RMF | AI RMF governance supports continuous identity oversight and accountability. |
Assign ownership for cleanup decisions and monitor identity risk as an ongoing governance function.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
