Account states: active, dormant, orphan, local, disabled and removed

ILM Reference editors · Published 2026-09-29 · 3 minute read

TRACK: BASICS · LESSON 3 OF 11

SUMMARYREV. 2026-09

Every account in every application is in one of a few states: active with a valid owner, dormant, orphaned, disabled or removed. Local is not a state but a location: an account stored in the application itself, which can be in any of those states. Knowing the state tells you the action: keep, review, assign an owner, disable or delete.

§ 01

What are the states?

Account states and the usual action for each.
State	What it means	Usual action
Active, owned	In use and linked to a current employee, contractor or named owner	Keep; include in periodic review
Dormant	Has an owner but has not been used for a defined period	Confirm need with the owner; disable if not needed
Orphan	Active but no longer linked to a current valid owner	Assign an owner or disable, then record the decision
Disabled	Cannot be used, but still exists with its access	Delete after the retention period, or re-enable only through a request
Removed	Deleted from the application	Keep the record of who removed it and when

The same account can move through several states. A leaver's account that was not disabled becomes an orphan. An orphan found in a review becomes disabled. A disabled account that is re-enabled without a request is an audit finding.

§ 02

Where does local fit?

A local account is one created and stored inside an application rather than in the central directory. Orchid Security's Orphan & Local Accounts report defines local accounts as credentials stored directly on systems or applications, and orphaned accounts as accounts left active after their owners depart or change roles. The two overlap often: when a person leaves, the identity provider disables their directory account, but a local account in a disconnected application stays active and becomes an orphan.

§ 03

What does NIST say about disabling accounts?

NIST SP 800-53 control enhancement AC-2(3), Disable Accounts, asks organizations to disable accounts within a period they define when the accounts have expired, are no longer associated with a user or individual, are in violation of policy, or have been inactive for a defined period. The second condition describes an orphan account; the fourth describes a dormant one. See the AC-2 lesson.

§ 04

How do tools label these states?

Vendors use their own words for the same states. Veza describes detecting dormant accounts and revealing local, machine and service accounts. Lumos says its identity analytics surfaces dormant accounts. Okta Identity Governance identifies inactive app users and reclaims unused licenses. Microsoft Entra ID Governance account discovery shows application users that match no Entra ID user, which is the starting list for orphan review. Orchid Security describes surfacing orphaned and local accounts inside the applications it discovers. When you compare tools, ask which states each one can detect in which applications.

§ 05

What is the habit to build?

Record a state for every account at every review, not only a keep or revoke decision. A register of states over time shows whether orphan and dormant counts are falling, which is the question an auditor or a CISO will eventually ask.