Why do dormant non-human and human accounts create such a high-risk identity signal?

Dormant accounts are risky because their first sign-in after long silence stands out sharply from baseline behavior. If credentials remain valid and access stays enabled, an attacker can reuse them without triggering obvious policy violations. The account history gives defenders a strong contrast signal, so reactivation, not just login success, should drive scrutiny.

Why Dormant Accounts Are Such a Strong Identity Signal

Dormant accounts matter because they create a clear behavioral baseline: long silence, then sudden activity. That contrast makes reactivation far more suspicious than an ordinary login failure. If the account is still enabled and its secrets still validate, an attacker can inherit prior trust without needing to break policy in an obvious way. NHIMG research shows how often compromised identities drive real incidents, including the Ultimate Guide to NHIs finding that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

This is especially important because dormant human accounts and dormant NHI service accounts fail in different ways but produce the same operational risk: hidden access that still works. Security teams often focus on failed logins, impossible travel, or privilege escalation, yet dormancy bypasses those indicators by preserving legitimate access paths. That is why lifecycle state, not just authentication success, should be treated as a first-class signal. Current guidance from NIST Cybersecurity Framework 2.0 and 52 NHI Breaches Analysis points to continuous asset and identity visibility as the only reliable way to surface this risk. In practice, many security teams encounter dormant-account abuse only after an unexpected reactivation has already produced access, not through deliberate review.

How the Risk Works in Practice

The core problem is that dormant accounts preserve trust while shedding scrutiny. For human identities, the account may still be tied to old group memberships, application entitlements, or service desk exceptions. For non-human identities, the situation can be worse: API keys, certificates, tokens, and service accounts often outlive the workload that originally justified them. If those credentials remain valid, an attacker does not need to create a new identity artifact. They only need to use an old one.

Defenders should treat dormancy as a combined identity and secrets-management issue. That means checking whether the account is enabled, whether the credential is still valid, whether the privilege set is still appropriate, and whether the workload or employee still exists. In NHI environments, the highest-value control is not just periodic review but automated offboarding, revocation, and rotation. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how poor visibility and weak rotation practices keep old identities usable long after they should have been retired. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls reinforces the need for access review, credential management, and revocation discipline.

• Flag reactivation after prolonged inactivity as a higher-risk event than ordinary sign-in.
• Separate identity review from credential validity review, because one can be stale while the other still works.
• For NHIs, verify the workload still exists before preserving any token, key, or certificate.
• Use access recertification to remove inherited privileges that accumulate over time.

These controls tend to break down in environments with shared service accounts, embedded secrets in code, or weak ownership, because no one can confidently prove who should still have access.

Where the Standard Answer Breaks Down

Tighter dormancy controls often increase operational overhead, requiring organisations to balance faster revocation against application continuity and support burden. That tradeoff is real, especially when a dormant account belongs to a brittle legacy system or a long-running integration that lacks a clean owner. Best practice is evolving, but there is no universal standard for how long inactivity alone should justify disabling an account.

Edge cases matter. Some human accounts go quiet because of seasonal work, parental leave, or project pauses, while some NHIs are intentionally idle until a scheduled job or failover event. In those cases, dormancy cannot be interpreted in isolation. Context has to include ownership, purpose, expected cadence, and whether the identity is bound to a critical process. The safest approach is to classify dormant accounts by business criticality and then apply different review windows and revocation thresholds. NHIMG’s Top 10 NHI Issues and the research in the 2024 ESG Report: Managing Non-Human Identities show why visibility gaps and weak governance turn old identities into durable attack paths. In mature environments, the real control is not merely detecting inactivity, but proving whether continued access is still justified.

Related resources from NHI Mgmt Group

• Why do accounts without MFA and excessive privilege create such a high-risk path for lateral movement in identity environments?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why do credentials on developer machines create disproportionate non-human identity risk?