Reviewers can approve or retain dormant accounts that appear harmless but have stale or exposed credentials. The failure is not the review process itself. The failure is the lack of evidence needed to separate benign dormancy from risky dormancy, especially for privileged identities.
Why This Matters for Security Teams
Dormant accounts are not safe just because they are quiet. Without activity context, reviewers cannot tell whether an identity is truly abandoned, temporarily idle, or still tied to scheduled jobs, integrations, or privileged automation. That gap matters because dormant non-human identities often retain valid secrets, standing access, or hidden dependencies long after their last visible login. NHI Mgmt Group notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, which makes “review by label alone” especially unreliable.
This is where control reviews fail in practice. A dormant account may look harmless in a spreadsheet, yet still be embedded in batch processing, CI/CD, or cross-system integrations, and those paths are often invisible to the reviewer. Security teams that rely on age, owner name, or last login timestamp miss the operational evidence that distinguishes benign dormancy from exposure risk. Current guidance from the NIST Cybersecurity Framework 2.0 emphasizes governance and risk-based decisions, but the operational challenge is collecting enough context to apply that guidance consistently. In practice, many security teams discover the account was still trusted only after the secret was reused or the dependency failed.
How It Works in Practice
Effective dormancy review starts with context, not approval. Reviewers need evidence about what the account was used for, what systems still depend on it, whether secrets are still valid, and whether the identity has a current business or technical owner. For non-human identities, this usually means combining directory data, secret vault telemetry, authentication logs, application references, and job scheduler records. The question is not just “Has it been active?” but “What would break if it were revoked?”
For privileged or service identities, teams should separate static review from runtime proof. That includes checking for:
- recent authentication or token issuance
- secret age and rotation status
- application or pipeline references
- privilege level and inherited access
- evidence of ownership and approval history
In a mature process, a dormant account with no business owner and no observed dependency becomes a strong candidate for disablement. A dormant account with hidden dependencies should trigger remediation before retention is approved, especially if the secret remains valid. NIST guidance supports this risk-based approach, while NHI Mgmt Group’s Ultimate Guide to NHIs highlights how weak visibility and poor rotation practices amplify the exposure window. The practical goal is to avoid treating silence as safety and to avoid preserving access simply because no one has looked closely enough.
These controls tend to break down when accounts are reused across shared services, because activity from one workload can mask ongoing dependency in another.
Common Variations and Edge Cases
Tighter dormancy controls often increase review effort, requiring organisations to balance faster cleanup against the risk of breaking legitimate automation. That tradeoff is especially sharp in environments with legacy service accounts, shared credentials, or scheduled tasks that do not generate clear ownership records. In those cases, current guidance suggests classifying dormancy by risk rather than by inactivity alone.
There is no universal standard for this yet, but a practical model is to treat accounts differently based on privilege, secret exposure, and dependency opacity. A low-risk, unowned account with no recent activity can often be disabled quickly. A high-privilege account with no activity but a valid credential and unclear downstream use requires deeper validation before action. Teams should also be careful with temporary inactivity caused by release freezes, seasonal workloads, or failover paths, where an account may appear dormant while still being operationally necessary.
The best reviews use activity context to ask whether the identity is still part of the system, not just whether it has logged in recently. That distinction matters because dormant does not mean harmless, and in NHI environments it often means unobserved.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Dormant accounts need ownership and lifecycle context to avoid unsafe retention. |
| NIST CSF 2.0 | PR.AC-4 | Access review decisions depend on validating whether access is still justified. |
| NIST AI RMF | Risk governance applies when deciding whether inactivity is safe or misleading. |
Apply risk-based governance to dormant identities using evidence, not inactivity alone.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
