Dormant account

What dormant accounts really create in an identity estate

A dormant account is not just an unused login. It is still a live identity with retained access, which means it can remain eligible for authentication, authorization, and lateral movement unless it is found, reviewed, and removed. The security problem is the mismatch between inactivity and authority: the account looks forgotten, but the access path still exists.

Dormancy matters because attackers often prefer accounts that defenders have mentally downgraded. A stale account can bypass normal user attention, survive role changes, and evade casual review if ownership is unclear or the record of why it exists has decayed. That is why dormant access is usually treated as an access-governance problem first, and a licensing problem only second.

Why dormant accounts become a control failure

When accounts are left active after a person stops using them, the organisation accumulates standing privilege that no longer matches current business need. This weakens the basic assumption behind least privilege and makes access reviews less reliable, because the review process may confirm an entitlement that nobody is actively exercising but nobody has formally removed either.

Dormant accounts also create lifecycle ambiguity. They may belong to former staff, shared functions, test users, legacy integrations, or privileged administrators who no longer need the original access pattern. In practice, the longer an account remains unused, the more likely its ownership, purpose, and justification are unclear, which complicates offboarding and entitlement recertification.

In identity governance terms, dormant accounts are often a symptom of incomplete joiner-mover-leaver handling, weak recertification cadence, or poor visibility into which accounts are still real. NHIMG’s IAM and IGA Basics is useful background for how provisioning, access reviews, and entitlement governance should work when accounts are still present but no longer active in practice.

How organisations find dormant accounts

Discovery starts with inventory, not guesswork. Teams need authoritative account records across directories, SaaS platforms, cloud consoles, remote access systems, and privileged repositories, then compare those records with last-used signals, recent sign-in history, and application telemetry. An account should be treated as potentially dormant only after the organisation checks whether the absence of activity is genuine or simply invisible in one log source.

Exposure assessment should also look for accounts that are dormant in one place but still usable elsewhere, such as a directory account that is inactive in the primary IdP but still has access in a SaaS tenant or VPN profile. For that reason, dormant-account discovery is best done as an estate-wide exercise rather than a single-product report. NHIMG’s CIS Control 5 Account Management Guide is a good match for the inventory and review side of this problem.

For machine and service identities, the same logic applies even when the account is not tied to a person. A service principal, API credential, or application account can sit unused while still being valid, so the organisation should verify whether inactivity reflects genuine retirement or simply a missing consumption signal. The practical question is not only “has it been used?” but also “is it still needed, and where would we notice if it were abused?”

Remediation and safe retirement of dormant access

Remediation should be staged rather than abrupt when the account may still be needed for recovery, integrations, or break-glass support. A safer pattern is to verify ownership, confirm business need, quarantine or disable the account, and only then delete it after a short observation period if no legitimate dependency appears. That sequence reduces the chance of breaking a hidden workflow while still closing the standing-access gap.

Where the account is tied to a human identity, remediation often needs to be paired with offboarding actions such as session revocation, token reset, password reset, or MFA re-enrolment for related accounts if compromise is suspected. Where the account is a service or application identity, the organisation should rotate or revoke the secrets that keep it usable, because deleting the account object alone may not remove all practical access paths.

NHIMG’s SaaS deprovisioning and NHI Offboarding and Decommissioning Guide both map well to this retirement phase, because dormant access is often only fully removed when deprovisioning and secret revocation happen together.

Detection, review, and compromise checks

Dormant accounts deserve detective controls because inactivity does not guarantee safety. A dormant account can be reactivated by an attacker using stolen credentials, or it can be discovered later as a persistence mechanism if an adversary has already taken advantage of weak cleanup. After any suspicious sign-in, organisations should review whether the account was ever genuinely required, whether it had unusual privilege, and whether related sessions or secrets need to be invalidated.

Post-incident review should also ask whether the dormant account was simply the easiest available route into a trusted application, remote access service, or cloud control plane. That review is especially important when the account has a role name, a shared purpose, or a history of privileged access, because those attributes make it more attractive for abuse than a freshly created account with minimal rights.

For defenders who need an ATT&CK lens on this behaviour, NHIMG’s MITRE ATT&CK T1078 Valid Accounts Guide helps frame dormant-account abuse as valid-account exploitation, while the VPN and Firewall Log Detection Guide is useful when dormant remote-access accounts are part of the investigation trail.

Risk and Threat Considerations

Dormant accounts create a durable attack opportunity because they combine retained access with low day-to-day visibility. If credentials are stolen, reused, or guessed, the account can become a quiet entry point that defenders are less likely to monitor closely than an active user. The same issue also makes cleanup slower after compromise, because the account’s current business owner or purpose may be unclear.

Failure mechanism: A stale account remains enabled after the user has stopped using it, so an attacker can exploit forgotten credentials or retained privileges without needing to create a new foothold.

Impact: The organisation can suffer unauthorized access, persistence, or lateral movement, and incident response becomes harder because the account’s legitimacy is ambiguous and its access paths may still be live.

Practitioner Guidance

Why practitioners should care: Dormant accounts are a governance problem with direct security consequences, not a housekeeping issue. If the organisation cannot tell why an account still exists, it cannot confidently say the account should keep its access.

What to watch for: Pay attention to accounts with no recent usage, no clear owner, unusual privilege, or a history of access to remote services and admin functions. Those are the accounts most likely to survive reviews unless dormancy is explicitly tracked and acted on.

Practitioner takeaway: Treat dormancy as a lifecycle state that requires decision and action, not as evidence that the account is harmless.

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?