How do you discover dormant non-human identities?

Discover dormant non-human identities by inventorying service accounts, service principals, API tokens, and workload identities, then comparing last use against business ownership and workload schedules. Flag identities with no recent authentication or API activity, and validate before removal. Disable or retire only after checking dependencies, because dormant identities are often forgotten integrations that still support hidden jobs.

How to discover dormant non-human identities without missing hidden dependencies

Dormant NHI discovery works best when you treat it as an inventory and usage-reconciliation exercise, not a simple account cleanup task. Start with a broad scan of service accounts, service principals, API tokens, workload identities, and related secrets, then compare observed activity against business ownership, deployment records, and expected runtime schedules. A quiet identity is not automatically safe to remove if it still supports a legacy job, batch process, or cross-system integration.

Discovery becomes more reliable when the inventory includes both explicit identity objects and the credentials or tokens that let them operate. That means looking for identities that exist in directories, cloud control planes, CI/CD systems, secrets stores, and application configs, then normalizing them into one view so you can tell whether the identity itself is idle or whether only one authentication path has gone quiet. A dormant label should come from evidence, not from the absence of one log source.

Use NHI Lifecycle Management Guide as the broader lifecycle reference when you need to connect discovery to rotation, offboarding, and visibility. The lifecycle view matters because dormancy is often a phase, not a final state, and the same identity can move from active to inactive to retired if ownership and dependencies are understood.

What signals usually distinguish a dormant identity from an unused one?

The most useful signal is not age alone, but the absence of recent authentication, token use, API calls, or workload execution when those events should have occurred under normal operations. Pair that with owner confirmation, change windows, and workload schedules. If a service account has no activity but the application it supports still runs on a fixed cadence, the gap is probably in telemetry or correlation, not in the identity’s usefulness.

Look for mismatches between technical state and operational expectation. A dormant identity may show no recent use, but it can still be embedded in scripts, cron jobs, automation pipelines, external partner integrations, or application configuration. That is why the discovery process should include dependency mapping, not just usage counts. If a team cannot explain what would break after removal, the identity is not ready for retirement.

The ownership question is often the fastest way to separate true dormancy from institutional forgetfulness. When no business or technical owner can explain why an identity exists, how often it should authenticate, or what system depends on it, the identity deserves deeper review. Use NHI Ownership and Accountability Guide to structure that review around accountable ownership rather than vague application names.

How should teams validate and retire dormant identities safely?

Once a candidate identity looks dormant, validate before disabling. The practical test is simple: confirm the absence of expected activity across the systems that should record it, identify the owner, and verify downstream dependencies. If the identity has not been used recently but still appears in configs, pipelines, or integration manifests, treat it as potentially active until the dependency is proven otherwise.

Retirement should be staged. First disable or quarantine in a way that is reversible, then monitor for failed jobs, application errors, or help desk escalation, and only then remove the identity or associated secrets. This matters because dormant identities often survive precisely by being invisible to the team that created them. A controlled disable step is safer than immediate deletion when the environment includes legacy automations or third-party integrations.

For broader detection and inventory patterns, Ultimate Guide to NHIs — What are Non-Human Identities is the most direct reference for the identity types you should include in the scan, while Ultimate Guide to NHIs — Key Challenges and Risks helps explain why stale identities are so often missed in the first place.

Risk and Threat Considerations

Dormant non-human identities are risky because they often retain privileges, trust relationships, or secrets even after the teams that created them stop watching them. If an attacker finds one, the lack of recent legitimate use can make abuse harder to notice, especially when the identity still has access to data, build systems, cloud resources, or partner APIs.

Failure mechanism: The identity falls out of normal review cycles, its usage pattern no longer matches an owner or workload, and the old credential or token remains valid even though nobody is actively monitoring it.

Impact: A forgotten identity can become a low-noise persistence point, an unauthorized access path, or an unexpected dependency that breaks production if removed too early.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Covers lifecycle control of authenticators tied to dormant identities.
	AC-2 — Account Management	Applies to identifying, monitoring, and disabling inactive accounts and service identities.
	AU-6 — Audit Record Review, Analysis, and Reporting	Supports using audit logs to confirm lack of legitimate identity activity.
Recommendation — Review and revoke stale authenticators before retiring dormant non-human identities. Maintain authoritative inventory and disable inactive accounts only after dependency validation. Correlate audit logs to distinguish true dormancy from missing telemetry.
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Dormant identities often persist because offboarding and retirement are incomplete.
	NHI-09 — NHI Reuse	Dormant identities are often reused across hidden jobs and integrations.
	NHI-10 — Human Use of NHI	Owner checks help expose identities that people still rely on informally.
Recommendation — Retire dormant NHIs through controlled offboarding with dependency checks. Detect reused NHIs before disabling them to avoid breaking hidden dependencies. Validate whether humans still depend on the identity before decommissioning it.
CIS Controls v8	CIS-5 — Account Management	Directly addresses finding and removing inactive or unnecessary accounts.
	CIS-6 — Access Control Management	Supports validating access paths before disabling dormant identities.
Recommendation — Inventory all accounts and remove inactive ones only after confirming business need. Limit and revoke access for dormant identities after confirming they are unused.

Practitioner Guidance

What to verify: Confirm dormancy against multiple evidence sources, including authentication logs, API telemetry, scheduler records, CI/CD activity, and app owner statements. One silent system is not enough; you need a cross-check before labeling an identity inactive.

Decision rule: If the identity can still authenticate to production or supports a business process that is not fully understood, quarantine it first rather than deleting it. If no owner can explain its purpose, treat that as a governance issue as much as a cleanup issue.

Practitioner takeaway: Dormant NHI discovery is really dependency discovery, and the safest retirements happen only after usage evidence, ownership, and hidden integrations all agree.