Why do dormant accounts create a serious access risk in organisations?

Why This Matters for Security Teams

Dormant accounts are not just housekeeping issues. They are persistent trust relationships that can survive job changes, project endings, contractor offboarding, and application retirement. When an account remains active, it can still authenticate, inherit stale group membership, and sometimes retain standing privilege that no longer matches the user’s current role. That makes dormant access a high-value target for credential stuffing, phishing follow-through, and post-compromise persistence.

Security teams often focus on active users and miss the long tail of accounts tied to legacy apps, service desks, shared mailboxes, automation jobs, and former employees. The risk increases when identity governance is fragmented across directories, SaaS platforms, and cloud workloads. Current guidance in the NIST Cybersecurity Framework 2.0 treats identity lifecycle management as a core protection and detection concern, not a one-time provisioning task.

In practice, many security teams encounter dormant accounts only after an alert, audit finding, or breach investigation has already exposed the control gap.

How It Works in Practice

Effective dormant account control starts with inventory, not assumptions. An organisation needs a current view of human accounts, non-human identities, privileged accounts, guest accounts, and application-linked identities across all identity stores. That inventory should include last login time, last password reset, MFA enrollment state, entitlement history, and whether the account can still reach sensitive systems. Where identity is federated, the source of authority matters: disabling an account in one app may not remove access if the upstream directory remains active.

Operationally, teams should define inactivity thresholds by account type and business context. For example, a contractor account may warrant a shorter inactivity window than a regulated archive mailbox or a break-glass account. Best practice is evolving here, and there is no universal standard for this yet, so the policy should be explicit, risk-based, and approved by identity, security, and business owners. NIST guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports account management, access enforcement, and auditability as ongoing control functions.

• Reconcile identity stores regularly to find accounts no longer tied to an active business purpose.
• Disable access first, then investigate whether deletion is appropriate for retention or legal reasons.
• Review entitlements attached to dormant accounts, especially privileged roles and API keys.
• Log and alert on reactivation, failed logins, and privilege changes for aged accounts.

The non-human identity angle matters as well: dormant service accounts, CI/CD credentials, and machine tokens can be easier to miss than employee accounts, and the OWASP Non-Human Identity Top 10 highlights how unmanaged machine identities can become a durable foothold. These controls tend to break down when identity ownership is unclear across mergers, outsourced operations, and SaaS sprawl because no single team can confirm who is responsible for disabling the access.

Common Variations and Edge Cases

Tighter dormant account controls often increase operational overhead, requiring organisations to balance reduced attack surface against the cost of false positives, user reactivation requests, and exception handling.

Shared mailboxes, privileged break-glass accounts, archived user profiles, and machine identities create edge cases where simple inactivity rules are too blunt. Current guidance suggests handling these through explicit ownership, compensating controls, and documented review cycles rather than by exempting them from governance. For example, a break-glass account should stay dormant until needed, but it still requires strong monitoring, protected storage, and periodic validation. Likewise, a dormant account may need to remain for legal hold or financial record retention, but that does not justify leaving interactive login enabled.

The main operational tradeoff is between speed and certainty. Automatically disabling every inactive account may disrupt business-critical workflows, while waiting for manual approval can leave stale access in place for too long. The safest model is usually staged: alert, validate, disable, then archive or delete based on policy. Identity teams should also consider whether an application has its own local account store, because access often persists there even after the central directory record is removed. This is especially important in hybrid environments and fragmented SaaS estates where the directory and the application do not share a single lifecycle control plane.

Related resources from NHI Mgmt Group

• Why does role-based access control create extra risk for service accounts?
• Why do service accounts create so much access governance risk?
• Why do service accounts and automation create hidden data-access risk?
• Why do service accounts create more access risk than many human accounts?