A dormant account is an account that has not been used for a defined period but still exists and can often still authenticate. Auditors look for these accounts because they are easy targets for takeover and can retain unnecessary access. Review last sign-in, ownership, privileges, and whether the account should be disabled or removed.
What auditors mean by “dormant” and why it matters
A dormant account is not the same as a deleted account or a locked account. In audit terms, it is an account that still exists in the environment, may still be able to authenticate, but has not shown normal use for a defined period. The audit question is not just “is it unused?” It is “does it still have a valid path into systems, data, or privileged functions?”
That distinction matters because dormant accounts are often overlooked during day-to-day access management. They can survive role changes, employee departures, contractor offboarding, and forgotten test activity. An auditor will usually treat the account as a control signal: either the access review process is not aggressive enough, or the organisation is carrying unnecessary authentication surface and privilege exposure.
In practice, the account’s age, last sign-in date, ownership, and assigned privileges tell the story. A dormant account with no meaningful entitlements is a hygiene issue. A dormant account with admin rights, VPN access, API reach, or production access is a much larger control concern because the unused account can become a convenient entry point if credentials are exposed or reused.
How auditors test dormancy in an access review
Auditors usually start by asking how the organisation defines dormancy, because the definition should be policy-based and consistent. They then compare that definition with actual directory, application, and privileged access records to see whether inactive accounts are identified, reviewed, and handled on time. The core test is whether the organisation can prove it knows which accounts are inactive and what happened to them next.
A useful review normally includes last authentication activity, account owner or sponsor, business justification, group memberships, and whether the account is tied to a human, service, contractor, or shared function. That evidence helps distinguish a genuinely abandoned account from a low-frequency account that is still needed for a legitimate operational reason.
For identity and access governance, the broader issue is whether dormant accounts are being recertified, disabled, or removed in a disciplined way. NHIMG’s IAM and IGA Basics is a useful reference point for how access review, entitlement management, and joiner-mover-leaver controls fit together when auditors look for evidence of access hygiene.
Where organisations use posture tooling, auditors may also expect a repeatable way to surface stale access patterns. The Identity Security Posture Management (ISPM) Guide is relevant because dormant accounts are often one of the clearest signs that access governance is drifting away from actual business need.
What to do when a dormant account is found
The first decision is whether the account still has a valid owner and a current business purpose. If it does not, disable it promptly rather than leaving it available “just in case.” If the account is tied to a business process, confirm who is accountable for it and whether the access should be revalidated, reduced, or converted to a narrower form.
Auditors also care about the cleanup sequence. If an account has been dormant for a long time, check whether its password, token, API key, or session material may still be valid somewhere else. If the account has privileged access, production reach, or third-party connectivity, review those permissions before deciding that inactivity alone makes it harmless. NHIMG’s Remote Access Identity Guide is especially relevant where dormant remote access accounts may still provide a usable entry path.
When the dormant account is part of a larger audit finding, the practical response is to document the exception, remove unnecessary access, and confirm that the lifecycle control that should have caught it is actually working. That is often more important than the individual account itself, because repeated dormancy usually points to weak offboarding or weak recertification discipline.
Risk and Threat Considerations
Dormant accounts create hidden exposure because they are easy to miss, easy to forget, and sometimes still fully usable. If an attacker obtains the credentials for one, they may find a valid login path that avoids fresh provisioning, avoids user scrutiny, and survives longer than an active account would. In audit terms, the risk increases sharply when dormancy overlaps with privilege, remote access, or shared administrative functions.
Failure mechanism: The account remains enabled after its operational need has ended, so stale credentials or forgotten access paths can still authenticate and grant entry. Weak offboarding, missed recertification, or incomplete asset ownership makes the account persist until someone actively finds it.
Impact: The result can be unauthorized access, privilege abuse, lateral movement, or a simple but effective foothold that should not have existed. In a regulated or high-trust environment, dormant privileged account can also undermine audit confidence because they show that access control is not tightly aligned to business need.
NHIMG’s Colonial Pipeline ransomware attack is a clear reminder that an unused account can still be the account that matters most if it retains real access. The lesson for auditors is that “unused” is not the same as “safe,” especially when authentication remains possible.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Dormant accounts are an account lifecycle and review issue. |
| IA-5 — Authenticator Management | Dormant accounts may still retain valid passwords, tokens, or other authenticators. | |
| AC-6 — Least Privilege | Dormant accounts become more dangerous when they retain unnecessary entitlements. | |
| Recommendation — Review, disable, and remove inactive accounts on a defined schedule. Rotate or revoke authenticators tied to inactive accounts. Reduce dormant accounts to the minimum access required or remove them. | ||
| CIS Controls v8 | CIS-5 — Account Management | Dormant accounts are an account inventory and removal problem addressed by account management. |
| Recommendation — Maintain an accurate account inventory and disable or remove stale accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Dormant accounts often persist with access that exceeds current need. |
| Recommendation — Restrict dormant accounts to the least privilege necessary or eliminate them. | ||
Practitioner Guidance
What to verify: Confirm that the organisation can produce a current dormancy definition, a last-use timestamp, an owner or sponsor, and a disposal decision for each inactive account. If any of those four items is missing, the control is not yet audit-ready.
Decision rule: If the account can still authenticate and has no current business justification, disable it first and investigate later. If it is privileged or externally reachable, treat it as higher priority than a routine stale user account.
Practitioner takeaway: Dormancy is not just inactivity, it is unattended access. Auditors care less about whether an account has been used recently than whether the organisation can prove that any remaining access is intentional, owned, and still necessary.
Related resources from NHI Mgmt Group
- Who is accountable for dormant account risk when old access remains enabled across the identity stack?
- Who should be accountable when a dormant service account needs to be revoked?
- How should security teams run Azure AD access reviews to reduce excessive permissions and dormant account risk?
- What are the signs that dormant account management is failing in an IAM programme?