How do you find dormant accounts before they become an access risk?

What counts as “dormant” in a way that is operationally useful?

Dormancy is only actionable when it is defined against the real business context, not a generic calendar rule. The threshold should reflect how often a role, function, or system actually needs to authenticate, and it should be different for employees, contractors, administrators, service accounts, and emergency access paths. That is why an identity programme should treat inactivity as a governance signal, not a binary label.

For that reason, the first question is whether the account is expected to be used at all in the period you are measuring. An account can be “inactive” from a sign-in perspective and still be legitimate if it is reserved for break-glass, seasonal work, or a recovery function. The better test is whether the account should have authenticated and whether there is a current owner who can justify keeping it enabled.

Practical discovery works best when sign-in data is paired with ownership, role and entitlement context. A dormant account with no owner is materially different from a dormant account attached to an active employee on leave, because the remediation path and urgency are not the same.

Which dormant accounts create the highest access risk first?

Not all dormant accounts deserve the same response. The highest-risk candidates are enabled accounts with administrative privilege, access to sensitive data, or broad trust relationships, because those accounts can be abused immediately if credentials are still valid. Accounts with no clear business owner, shared use, or no recent review deserve similar priority because they are harder to defend and easier to miss.

Discovery should therefore sort accounts by blast radius, not just age. An old low-privilege account is a hygiene issue; an old privileged account is a direct exposure path. That distinction matters because attackers routinely look for valid accounts that defenders have forgotten, and auditors will also focus on whether the organisation can prove it knows who still has access.

When you analyse dormancy, include the account types most likely to be overlooked: admin users, legacy integration accounts, remote access accounts, and accounts created for projects or third parties that have since ended. If those accounts remain enabled, they are still a live authentication path even when nobody is actively using them.

How do you turn dormant-account discovery into a repeatable control?

The control should combine inventory, last-authentication data, and exception handling. That means establishing a complete account list, checking whether each account has authenticated within the agreed window, and separating truly unused accounts from accounts that are inactive for a justified reason. Orphaned and Dormant Accounts is the most direct guide for building that process around reliable sign-in evidence and safe retirement.

Once discovery is in place, the operational question becomes how quickly you can disable or reauthorise the account after review. Delay is the common failure mode: organisations identify dormant accounts but leave them enabled while waiting for confirmation, which preserves the access risk. A useful control is one that moves from detection to action quickly, with clear criteria for reactivation if the owner later proves a legitimate need.

The same discipline should apply to service and automation identities, even if the discovery mechanics are different. Dormancy in a machine context often means no observable use, no owner, or no current dependency, but the risk remains the same if the credential can still authenticate. For deeper handling of those cases, NHI Dormancy Detection is useful for understanding last-used signals, quarantine steps and reactivation alerts.

Risk and Threat Considerations

Dormant accounts become dangerous when inactivity is mistaken for safety. If an attacker obtains valid credentials, an old enabled account can bypass many frontline controls because it already exists, may still authenticate, and often escapes normal monitoring until it is used. The risk is highest where the account has elevated privilege or legacy access that was never fully retired.

Failure mechanism: The organisation keeps an unused but enabled account in the directory, the credentials remain valid, and the account is later used for unauthorised access, privilege escalation, or persistence.

Impact: This can expose sensitive data, undermine audit assurance, and give an attacker a legitimate-looking entry point that is harder to distinguish from normal activity.

Practitioner Guidance

What to prioritise: Start with enabled accounts that have administrative privilege, access to sensitive systems, or no clearly assigned owner. Those are the accounts where dormancy translates most directly into exposure.

What to verify: Use sign-in data as the primary evidence, but confirm whether the account is still expected to exist. If the account is dormant only because a process is seasonal, break-glass, or recovery-related, treat it as an exception with an owner and review date, not as a routine inactive account.

Decision rule: If the account can still authenticate and there is no current business justification, disable it first and resolve reactivation later. If the account is tied to a service, vendor or recovery workflow, validate the dependency before removal so you do not trade access risk for an outage.

Practitioner takeaway: Dormant-account management is effective only when discovery is tied to fast disposition, because the real risk is not that an account exists, but that it stays enabled after its business need has disappeared.

Related resources from NHI Mgmt Group

• How should security teams reduce the risk from dormant SaaS accounts before they become an attack path?
• How should security teams govern dormant Office 365 accounts before they become exposure paths?
• How should organisations manage dormant IAM accounts before they become a security and cost problem?
• How should security teams find and remove shadow administrator accounts before they become a breach path?