How should teams decide whether a dormant account can stay enabled?

How teams should decide whether a dormant account can stay enabled

A dormant account is not automatically safe to keep, because the right decision depends on whether there is a current, documented reason for it to remain reachable and whether that reason survives scrutiny. Teams should treat “still enabled” as an exception that must be justified by business need, legal hold, return-to-work expectations, or an explicit emergency access model.

What needs to be true before a dormant account stays live

The first question is whether the account still has an owner and a purpose. If the answer is vague, delayed, or delegated to memory, the account is already a governance problem. The practical test is simple: can a manager, system owner, or control owner explain why the account must remain active today, and can they name when that need expires?

That decision should also consider the account’s reach. An enabled dormant identity with old memberships, standing privileges, or connected tokens has a much larger blast radius than a dormant login that is already stripped down. If the account must remain enabled for a short period, reduce what it can do immediately rather than waiting for the next review cycle. IAM and IGA Basics is a useful reference point for how entitlement, provisioning and review decisions fit together.

When enabling a dormant account is justified, and when it is not

Keeping the account enabled can be reasonable when there is an active legal hold, a verified contractor return date, a documented break-glass role, or another narrow operational reason that would be harmed by deprovisioning. It is not reasonable when the account is being left open “just in case,” when ownership is unclear, or when the only argument is convenience. That is especially true if the account can still authenticate to production systems, remote access, or sensitive support paths.

For teams managing identity posture as a programme, a dormant account should be handled as a measurable exception rather than a special case hidden in a spreadsheet. A strong posture review asks not only whether the account is dormant, but whether it is also overprivileged, tied to stale memberships, or carrying long-lived access paths that outlast the business need. Identity Security Posture Management (ISPM) Guide helps frame those checks as part of continuous identity hygiene.

When the account is only needed for remote access or contingency access, treat the decision even more strictly. Dormant remote-access identities are a common source of unnecessary exposure because they tend to accumulate weak controls over time and are easy to overlook during normal operations. Remote Access Identity Guide is a good lens for assessing whether the access path still deserves to exist.

What should happen if the answer is no

If none of the legitimate retention reasons apply, the account should be disabled and cleaned up in the same lifecycle action. That means removing or revoking tokens, licences, group memberships, and other standing access paths rather than leaving them in place for later. The point is to remove the account as an active control surface, not merely to make logon harder while the surrounding access remains intact.

Teams should also preserve evidence of why the account was disabled, who approved the action, and what downstream entitlements were removed. That record matters because dormant-account decisions often get revisited after an incident, an audit, or a staffing change. If the account is reactivated later, it should come back through the same ownership and approval path, not through an informal re-enable request.

Risk and Threat Considerations

Dormant accounts are attractive to attackers because they often combine weak monitoring, forgotten ownership and stale privilege. If an old password, token or session path still works, the account can become a low-noise entry point that avoids the scrutiny applied to active users.

Failure mechanism: The account remains enabled after its business purpose has expired, so an attacker or insider can abuse forgotten access, old memberships or long-lived tokens before anyone notices the account should have been closed.

Impact: The result can be unauthorized access, privilege abuse, lateral movement or delayed detection, especially when dormant accounts were never fully stripped of the access they once needed.

Practitioner Guidance

What to verify: Require a named owner, an expiry condition, and a current access purpose before accepting any request to keep a dormant account enabled. If the justification cannot be written down in one sentence, the account is already past due for disablement.

Decision rule: If the account has no active business purpose, no legal hold, and no documented return plan, disable it and remove its tokens, memberships and licences in the same change. If any temporary exception is approved, time-box it and record the review date up front.

Common mistake: Teams often leave dormant accounts enabled because they treat them as harmless or “needed someday,” but that logic preserves exactly the kind of standing access that attackers and auditors both look for first.

Practitioner takeaway: The safest default is to disable dormant accounts unless a current, auditable reason exists to keep them live, and any exception should be narrow, time-bound and cleaned up at the same time as the account state.

Related resources from NHI Mgmt Group

• How can teams decide whether an identity task should stay in the console?
• How should teams decide whether an AI control plane needs to stay self-hosted?
• How should security teams decide whether a discovered privileged account needs vaulting or a different control?
• How do security teams decide whether to use OIDC federation or service-account keys for MCP access?