Teams should treat dormant accounts as part of their security footprint, not harmless clutter. Start with a full audit of accounts and passwords, reset insecure credentials, enable multifactor authentication where possible, and close accounts that are no longer needed. Before closure, confirm what data is stored, how it is deleted, and whether identity checks are required to complete the request.
Why Dormant Accounts Need Active Lifecycle Management
dormant account are not just leftover records. They are still reachable identities unless they are confirmed inactive, tightly controlled, or fully removed. The practical question is whether the account can still authenticate, what it can still access, and whether the business has a valid reason to keep it. That is why identity governance has to cover dormant accounts alongside active ones, especially where access reviews and entitlement cleanup are already part of the control model.
Teams should begin by inventorying the account, the owner, the authentication method, and the systems it can reach. If the account exists because of a temporary need, the preferred outcome is to retire it; if it must remain, it should have a clear owner, a documented purpose, and a bounded review cycle. This is the difference between an intentionally retained identity and an account that lingers by accident.
When organizations treat dormant accounts as part of the same access lifecycle as joiner, mover, and leaver events, they reduce both administrative clutter and hidden privilege accumulation. IAM and IGA Basics is useful here because dormant-account handling sits inside entitlement governance, not just password hygiene. The same logic applies when the account is tied to remote access or legacy login paths that should no longer exist.
What Makes Dormant Accounts Risky in Practice
The danger is not the label "dormant" itself. The risk comes from accounts that still have valid credentials, stored secrets, active sessions, delegated access, or connections to sensitive systems. A forgotten account can become a low-friction entry point if password reuse, missing multifactor authentication, or stale entitlements remain in place.
Dormant accounts are also harder to defend because defenders often assume nobody is using them. That assumption creates a blind spot around audit logging, access review, and offboarding discipline. Identity Security Posture Management (ISPM) Guide is relevant because dormant and stale accounts are classic posture findings that need prioritization, not just cleanup. If the account is externally reachable, that blind spot can matter even more.
A real-world example is the Colonial Pipeline ransomware attack, where an unused remote access account with a leaked password and no MFA became a material access path. The lesson is not that every dormant account will be attacked, but that unused access paths can remain exploitable if they are never retired.
How to Close Dormant Accounts Cleanly
The safest closure process is deliberate, not ad hoc. Confirm who owns the account, what data or services it can reach, whether the account is tied to legal retention or operational records, and whether the account can be removed outright or must be disabled first. If closure depends on identity verification, make that a controlled step so the wrong person cannot request deletion or retention changes.
Where the account still needs to exist for a transition period, reset or revoke credentials, remove privileged entitlements, and require stronger authentication until retirement is complete. The goal is to reduce the account's blast radius before it disappears. Remote Access Identity Guide is a useful companion when dormant accounts are tied to VPN, ZTNA, or other entry points that should be retired alongside the identity itself.
For teams that want a tighter operating model, use the closure request to verify whether the identity still has any downstream dependencies, such as shared ownership, service handoffs, or data export obligations. If the account is an application or machine identity rather than a person account, the same retirement logic applies, but the dependency check becomes even more important because the account may support a system process rather than a user 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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Dormant accounts often persist through stale credentials and weak revocation. |
| AC-2 — Account Management | Dormant-account cleanup is an account lifecycle and deprovisioning problem. | |
| IA-2 — Identification and Authentication (Organizational Users) | Dormant human accounts remain a valid authentication concern until retired. | |
| Recommendation — Rotate or revoke stale authenticators before disabling the dormant account. Review, disable, and remove no-longer-needed accounts under a formal lifecycle process. Require strong authentication and verify account identity before any reactivation or closure action. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Dormant non-human and shared accounts can linger after they are no longer needed. |
| NHI-07 — Long-Lived Secrets | Dormant accounts are often risky because their secrets remain valid too long. | |
| Recommendation — Offboard unused identities quickly and remove their access paths. Shorten secret lifetimes and eliminate credentials tied to inactive accounts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Dormant accounts are an account lifecycle control issue covered by CIS account governance. |
| Recommendation — Inventory accounts regularly and disable or remove those no longer required. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Dormant accounts are governed through identity lifecycle and ownership controls. |
| A.5.17 — Authentication information | Dormant accounts remain dangerous if passwords or other authentication material are still valid. | |
| Recommendation — Assign ownership and lifecycle rules for dormant identities and remove them when no longer needed. Protect, reset, or revoke authentication information attached to inactive accounts. | ||
Practitioner Guidance
What to prioritize: Start with accounts that can still authenticate to production, remote access, or admin functions. Those accounts carry the greatest residual risk, even if nobody expects them to be used.
What to verify: Before closure, confirm the account owner, last use, attached entitlements, stored data, and the exact deletion or deprovisioning path. If any of those are unknown, treat the account as an unresolved access-control issue rather than a housekeeping item.
Common mistake: Teams often disable the login but leave the account's permissions, tokens, or linked access paths untouched. That creates a false sense of closure because the identity still exists in the control plane.
Practitioner takeaway: Dormant-account handling should be run as access governance, not cleanup, because the right question is not whether the account looks unused, but whether it can still be abused, inherited, or accidentally reactivated.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams handle dormant accounts without leaving downstream access behind?
- How should security teams handle shadow SaaS and dormant accounts during M&A integration?
- How should security teams handle dormant privileged accounts in a PAM environment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
