Who is accountable for dormant account risk when old access remains enabled across the identity stack?

Why This Matters for Security Teams

Dormant account risk is not just an access review problem. It is a lifecycle control problem that spans identity governance, privileged access management, and operational ownership. When old access remains enabled, attackers inherit a live trust path that no one is actively watching. That matters because an inactive account often retains group membership, token reach, API access, or delegated privileges long after the original business need has ended.

This is why NHI Management Group treats dormant access as a control failure across the stack, not a single-team oversight. Guidance in the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward lifecycle enforcement, least privilege, and timely revocation rather than passive ownership. The practical issue is that many organisations discover the gap only after an old account is reused, reactivated without challenge, or exploited during an incident review. In practice, many security teams encounter dormant access only after privilege misuse has already occurred, rather than through intentional lifecycle enforcement.

How It Works in Practice

Accountability for dormant account risk usually sits with the team that can enforce disablement, not merely observe it. That means identity operations defines inactivity thresholds, IAM or directory teams implement disablement logic, access governance validates exceptions, and PAM controls the higher-risk accounts that should never remain quietly enabled. For non-human identities and service accounts, the same principle applies: if a secret, token, or certificate is still valid, the account is still usable.

Operationally, the strongest pattern is to combine policy, telemetry, and revalidation. Current practice typically includes:

• defining inactivity by account type, such as employee, contractor, service account, or privileged identity;
• requiring runtime checks before reactivation, including ticket evidence, manager approval, or workload attestation;
• revoking or rotating secrets when an account crosses an inactivity threshold;
• logging disablement and exception handling in the identity governance workflow;
• reconciling directory state, PAM state, and application-specific entitlements so one disabled control is not bypassed elsewhere.

For broader NHI risk, dormant access often behaves like an unattended credential. NHIMG’s Ultimate Guide to NHIs frames these identities as persistent trust objects that need explicit lifecycle control, not informal ownership. If a long-unused account still has a valid API key, cached token, or delegated trust chain, the risk is real even if no human has touched it recently. These controls tend to break down in federated environments where directory disablement does not automatically propagate to SaaS apps, cloud IAM roles, and locally managed service credentials.

Common Variations and Edge Cases

Tighter inactivity controls often increase operational overhead, requiring organisations to balance security gain against business interruption risk. That tradeoff is especially visible when shared mailboxes, service accounts, automation runners, and emergency break-glass accounts are involved. Best practice is evolving here, and there is no universal standard for exactly how long inactivity should be tolerated across every account class.

One common edge case is the reactivated account that appears dormant only because it is infrequently used. Another is the privileged account that is technically active but should be treated as dormant because no recent business justification exists. In both cases, governance should force a fresh approval path and a current need assessment, not just a password reset. For incident context, NHIMG’s 52 NHI Breaches Analysis shows how unresolved identity hygiene becomes exploitable when old trust is left in place.

The most defensible model is shared accountability with clear control ownership: identity lifecycle teams own disablement rules, access governance owns exception review, PAM owns privileged account rigor, and application owners confirm whether an account still has business purpose. If those responsibilities are not written down, dormant access tends to persist across the stack until an attacker, audit, or outage exposes the gap.

Related resources from NHI Mgmt Group

• Who should be accountable for reducing access risk across the full identity stack?
• Who is accountable when high-risk access is approved after a weak identity check?
• Who should be accountable for approving and reviewing non-human identity access across integrated systems?
• Who should be accountable for secure eID access when cloud platforms connect identity, account management, and APIs?