Account dormancy period is the length of time an account has gone inactive before a suspicious event occurs. In fraud analysis, older inactive accounts can be attractive targets because customers may not notice changes quickly and value may have accumulated. Dormancy is most useful when combined with other risk signals such as device change or password reset.
Expanded Definition
Account dormancy period describes how long an account remains inactive before later activity is treated as higher risk. In NHI and IAM operations, the concept is used to separate ordinary inactivity from the kind of dormant account that may have been forgotten, abandoned, or preserved for abuse. Definitions vary across vendors and fraud teams, but the practical test is consistent: the longer an account goes unused, the less likely a legitimate user will notice unexpected changes. In Non-Human Identity programs, dormancy is especially relevant for service account, API keys, and automation identities that may continue to exist long after their original purpose has ended.
Standards do not define a universal dormancy threshold, so organisations usually set their own time window based on business criticality, access scope, and expected usage patterns. That window should be paired with review of last login, last token use, password resets, device changes, and privilege changes. NIST guidance on access control and account management provides the governance baseline, while NHI-specific lifecycle controls are covered in the Ultimate Guide to NHIs. The most common misapplication is treating dormancy as proof of safety, which occurs when inactive accounts remain enabled without periodic validation.
Examples and Use Cases
Implementing account dormancy rigorously often introduces review overhead, requiring organisations to balance faster detection of account abuse against the operational cost of investigating legitimate but infrequent access.
- A customer account that has not been used for months receives a password reset request followed by a device change, triggering fraud checks because the inactivity window makes compromise harder to spot.
- A service account used only by a quarterly batch job is flagged as dormant, then revalidated against the job schedule so the team can distinguish expected inactivity from abandonment.
- An API key last seen six months ago is still present in a CI/CD pipeline, and its dormancy signals the need to confirm ownership, rotate the secret, or revoke it if the integration is no longer active. See Ultimate Guide to NHIs.
- Security teams compare dormancy with access logs and account metadata to identify accounts that are inactive but still authorized, especially where privileged access was never formally removed.
- Account review workflows map dormant identities to NIST SP 800-53 Rev 5 Security and Privacy Controls account management expectations so unused access does not persist indefinitely.
Why It Matters in NHI Security
Dormant accounts are dangerous because they create a long window in which access can be forgotten, credentials can age, and monitoring can weaken. In NHI environments, that risk is amplified by machine accounts that often outlive the teams or applications that created them. NHIMG research shows that 71% of NHIs are not rotated within recommended time frames and only 5.7% of organisations have full visibility into their service accounts, a combination that makes dormancy a practical indicator of hidden exposure rather than a simple housekeeping metric. The same visibility gap appears in broader guidance on lifecycle management and secret hygiene in the Ultimate Guide to NHIs.
When a dormant account is reactivated or discovered during an incident, it often reveals deeper weaknesses such as poor offboarding, weak ownership records, or stale secrets stored outside controlled systems. NIST account management controls and periodic review expectations are relevant because dormant access is only obvious if the organisation can prove who owns the account and why it still exists. Organisations typically encounter the true impact of dormancy only after a suspicious login, a fraud event, or a breach investigation, at which point the dormant account becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle governance and stale NHI exposure that dormancy helps detect. |
| NIST CSF 2.0 | PR.AA-04 | Identity and access controls require unused accounts to be governed and reviewed. |
| NIST SP 800-63 | IAL2 | Reactivation of an inactive identity should be tied to reliable identity proofing. |
| NIST Zero Trust (SP 800-207) | 5.2 | Zero Trust requires continuous evaluation, not trust based on old account state. |
Set dormancy thresholds, validate account necessity, and disable unused access on a fixed review cycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
