Why do dormant service or legacy accounts still matter after a compromise?

Why This Matters for Security Teams

Dormant service and legacy accounts are dangerous because compromise does not have to start with an active employee account. A forgotten account can still authenticate to old hosts, management planes, CI/CD systems, or connected SaaS tools, which makes it a durable bridge for post-compromise movement. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service account, and that visibility gap is exactly what keeps dormant identities alive long after they should have been removed.

The problem is not just the account itself, but what it can still reach. Attackers routinely look for stale keys, old admin paths, and forgotten integrations because those paths often bypass modern controls and monitoring. NIST’s SP 800-53 Rev. 5 treats identity lifecycle and access enforcement as core security controls, which reflects a simple reality: if an account still authenticates, it still matters. In practice, many security teams discover dormant-account exposure only after a breach has already used it to pivot.

How It Works in Practice

Security teams should treat dormant accounts as assets that require active proof of death, not just assumptions based on inactivity. That means inventorying service accounts, correlating them to owners and systems, and testing whether each one can still authenticate, authorize, or trigger downstream actions. The account may be “unused” in one system yet still function as a valid bridge into another. NHIMG’s 52 NHI Breaches Analysis shows why this matters: compromised non-human identities repeatedly appear as the entry point or persistence mechanism in real incidents.

A practical workflow usually includes:

• Map every dormant or legacy account to its owner, purpose, and last known dependency.
• Check whether the credential is still valid in vaults, code, scripts, schedulers, and third-party integrations.
• Revoke or rotate secrets first, then disable the account and confirm no service breaks.
• Verify logs, backups, and failover systems for hidden reactivation paths.

Where possible, pair this with short-lived secrets, explicit offboarding, and periodic attestations so the organisation can prove an account is dead rather than merely quiet. Current guidance suggests that the safest approach is to remove standing trust as early as operationally feasible, then reintroduce access only when a real dependency is confirmed. These controls tend to break down in environments with unmanaged scripts, embedded credentials, and shadow IT because no one can reliably tell what still depends on the account.

Common Variations and Edge Cases

Tighter dormancy controls often increase operational overhead, requiring organisations to balance faster deprovisioning against the risk of breaking legacy jobs or vendor integrations. That tradeoff is real, especially in manufacturing, regulated finance, and hybrid environments where old service accounts may be the only surviving path to a brittle system.

There is no universal standard for what counts as “dormant” across every environment. Some teams use 30, 60, or 90 days of inactivity, but that threshold is only a starting point. A credential can be inactive from a login perspective and still be highly dangerous if it can mint tokens, call APIs, or authenticate through automation. Organisations should also beware of service accounts that are intentionally low-touch but still privileged, because inactivity does not reduce the blast radius.

The cleanest answer is evidence-based retirement: prove the account has no live dependencies, remove its secrets, and validate that no scheduled task, integration, or backup process can resurrect it. Where that evidence is missing, the account should be treated as live until proven otherwise.

Related resources from NHI Mgmt Group

• Why do still-valid secrets matter after public disclosure?
• What are common vulnerabilities associated with service accounts in AI deployments?
• Who should be accountable for service accounts and tokens after a compromise?
• Why do non-human identities create more risk than many human accounts?