How can security teams tell whether a service identity is truly dormant?

What “dormant” really means for a service identity

A service identity is not dormant just because logs go quiet. Dormancy is a control conclusion, not an observation, and it depends on whether the identity still has an owner, a current business purpose, and evidence of recent authorised use. If those conditions are not met, the identity may be inactive, abandoned, or simply low-traffic, which are different states with different actions.

For security teams, the first task is to distinguish absence of routine activity from evidence that the identity has been retired. A genuinely dormant identity should have no recent approved use, no active dependency in a service map or application inventory, and no remaining operational need to keep its credential valid. If any of those are still true, the identity is not dormant in the practical sense that matters for access governance.

This is why dormant-account checks work best when they combine ownership, usage history, and purpose. In practice, the question is not “has it logged in lately?” but “can we still justify this identity existing at all?” That framing prevents teams from freezing or deleting identities that are quiet only because they run on schedules, batch windows, or infrequent event triggers.

Signals that separate dormancy from low-frequency use

The strongest evidence of dormancy is a cluster of negative signals, not one metric. No named owner, no recent authorised use, no current ticketed dependency, and no documented business function together point toward retirement. By contrast, an identity that only wakes up monthly, quarterly, or during release windows may look dormant in ordinary logs while still being fully legitimate.

Security teams should treat any new API call, unusual source region, or rare user agent as runtime evidence that the identity is active again. Those signals matter because they show the identity is still capable of authenticating and reaching a live service, even if the access pattern is infrequent. That is especially important for service identities that are easy to overlook in broad access reviews.

Bursty, scheduled, or externally triggered activity is a common reason dormant checks fail. A better test is whether the observed activity matches an approved pattern and whether the credential is still tied to an active runbook, integration, or automation owner. If the answer is unclear, the identity should be treated as unverified, not safely dormant.

How to verify dormancy without breaking a working integration

The cleanest approach is to validate dormancy against ownership, inventory, and recent telemetry in that order. Start by confirming who owns the identity, what system depends on it, and whether there is any change record, deployment record, or exception that explains the last legitimate use. Then compare that expected pattern with authentication logs, API request logs, and source characteristics.

Where possible, use a short observation window before any disablement. That window helps avoid taking out credentials that only appear inactive because they support low-volume jobs. For NHIMG's NHI Lifecycle Management Guide, the operational emphasis is the same: lifecycle status should be grounded in ownership, visibility, and offboarding evidence, not a single inactivity threshold.

Once the identity is confirmed as unused, move it into a controlled retirement path rather than deleting it blindly. The practical sequence is to revoke or quarantine the credential, monitor for breakage, and then remove the identity only after the dependent service has been confirmed retired or rekeyed. That sequence preserves both security and service continuity.

Risk and Threat Considerations

Dormant service identities are high-value because they are often overlooked, weakly monitored, and still technically valid. If an attacker finds one, they get a credential that may bypass normal user-facing controls while blending into expected machine-to-machine traffic. The risk is highest when ownership is unclear and the identity has not been reviewed as part of a broader access lifecycle.

Failure mechanism: An identity is assumed to be dormant because it is quiet, but it remains able to authenticate. An attacker or unnoticed dependency then reactivates it through a valid secret, token, or certificate and uses normal-looking API traffic to establish access.

Impact: A dormant credential can become a persistence point, a lateral movement path, or a silent data-access channel. It can also create false confidence in access reviews, because the account appears inactive until it suddenly resumes use.

Practitioner Guidance

What to verify: Before declaring dormancy, verify three things together, owner assignment, current business purpose, and recent authorised use. If any one of those cannot be proven, treat the identity as unresolved rather than dormant.

Decision rule: If the identity has no owner and no approved runtime pattern, move it to retirement or quarantine. If it has a known owner but only sporadic activity, keep it under watch and confirm the schedule or integration before taking action.

What practitioners underestimate: The most common mistake is confusing “not seen often” with “safe to ignore.” For service identities, quiet logs are not enough, the real test is whether the identity still has a legitimate path back into production.

Practitioner takeaway: Dormancy is proven by the absence of justified use, not by the absence of traffic, and any new live request should reset the investigation until the identity’s owner and purpose are re-established.

Related resources from NHI Mgmt Group

• How can security teams tell whether service desk changes are actually helping identity operations?
• How can security teams tell whether a generated auth failure is in the app or in the identity service?
• How can security teams tell whether automation is helping or harming identity governance?
• How can security teams tell whether their identity programme is ready for zero trust?