Teams should treat both as lifecycle risks, not administrative leftovers. Define inactivity thresholds, require ownership, and route unused accounts, application access, and privileged objects into disablement or attestation workflows. That approach reduces standing privilege and makes it harder for attackers to exploit credentials that remain valid long after their original purpose ended.
Why This Matters for Security Teams
Unused non-human identities and dormant application access are not just hygiene issues. They are a persistence path, especially when service accounts, API keys, certificates, and privileged objects remain valid after the business need has ended. The risk is amplified because NHIs often outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. The practical problem is ownership: if no one can answer who depends on the identity, disablement is delayed and attackers get a larger window to reuse it.
Current guidance from the OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs — Key Challenges and Risks is to treat these identities as lifecycle-managed assets, not static records in a directory. That means defining inactivity thresholds, assigning accountable owners, and tying dormant access to attestation or disablement workflows. In practice, many security teams discover dormant access only after a breached token or abandoned integration has already been used to move laterally.
How It Works in Practice
Effective handling starts with an inventory that distinguishes between an unused identity and a temporarily quiet one. A service account used only at month-end may be dormant for 29 days and still legitimate, while an API key with no known owner and no recent telemetry should be treated as a candidate for revocation. The operational answer is to combine ownership, last-seen activity, scope, and business criticality into a review workflow rather than relying on a single inactivity timer.
Teams usually implement this in three steps:
- Define inactivity thresholds by identity class, environment, and criticality, not one global number.
- Require an owner or application steward before any NHI can remain active past the threshold.
- Route the object into disablement, rotation, or attestation based on dependency checks and change windows.
This approach aligns with the lifecycle and offboarding themes in the 52 NHI Breaches Analysis, where abandoned access and excessive validity repeatedly turn into breach enablers. It also fits the zero trust direction described in the Ultimate Guide to NHIs: trust should be continually verified, not assumed because an identity was created long ago. For implementation detail, the OWASP Non-Human Identity Top 10 reinforces that stale secrets, weak offboarding, and poor visibility need automation, not periodic spreadsheet reviews.
Where possible, pair review workflows with short-lived secrets, token expiration, and telemetry from the workload itself so that inactivity can be validated rather than guessed. These controls tend to break down in legacy batch systems and tightly coupled vendor integrations because the dependency map is incomplete and disablement can interrupt hidden production jobs.
Common Variations and Edge Cases
Tighter disablement often increases operational overhead, requiring organisations to balance security gains against the risk of interrupting critical workloads. That tradeoff becomes sharper in environments with shared service accounts, hard-coded credentials, or third-party integrations that were never designed for clean offboarding. Current guidance suggests moving those cases into a more controlled exception process rather than letting them bypass lifecycle governance entirely.
One common edge case is a dormant account that is intentionally paused for seasonal or disaster-recovery use. Best practice is evolving here: some teams keep the identity disabled and re-enable it through a privileged workflow, while others prefer JIT provisioning for the duration of the task. Another edge case is application access embedded in code or CI/CD pipelines. Even if the workload appears idle, the credential may still be live in build tooling, backup jobs, or downstream automation.
The key is to distinguish inactivity from irrelevance. If an identity is dormant but still mapped to a known business function, place it under attestations and expiration controls. If it is dormant with no owner, no recent use, and no validated dependency, treat it as an incident-ready removal candidate. The JetBrains GitHub plugin token exposure is a reminder that long-lived access often survives exactly because nobody expects a development toolchain credential to matter after its original task. OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs — Key Challenges and Risks both point to the same operational conclusion: dormant access is safest when it is either formally justified or formally removed.
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 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-03 | Addresses stale NHI credentials and offboarding gaps. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access reviews fit dormant application access management. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continual validation rather than trusting old access. |
Set expiry, rotate, or revoke dormant NHIs through automated lifecycle controls.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams govern just-in-time access for non-human identities?
