The time between the end of a relationship or role and the point at which all access has been fully removed. In identity programmes, this is a practical measure of how exposed an organisation remains after offboarding, especially when systems are disconnected or revocation is manual.
Expanded Definition
Identity cleanup lag describes the exposure window that remains after an employee, contractor, workload, or agentic system has moved on but its access has not yet been fully removed. In NHI and IAM programmes, the term is especially important because machine identities, API keys, service accounts, and tokens can persist long after the business relationship ends.
Definitions vary across vendors, but the operational meaning is consistent: measure the elapsed time from offboarding trigger to complete revocation across every connected system. That includes directories, cloud IAM, code repositories, CI/CD tools, vaults, and any downstream systems that cache privileges. The concept aligns closely with the identity lifecycle and least-privilege goals reflected in the NIST Cybersecurity Framework 2.0, even though no single standard governs this term yet.
For NHI governance, the key question is not whether a ticket was closed, but whether the last valid credential, trust relationship, and authorization path have actually been removed. The most common misapplication is treating account disablement in one directory as equivalent to full revocation, which occurs when downstream tokens, keys, or federated grants remain active.
Examples and Use Cases
Implementing identity cleanup rigorously often introduces coordination overhead, requiring organisations to weigh faster offboarding against the cost of synchronising many systems and owners.
- Revoking a departing engineer’s SSO account while also removing long-lived cloud access keys, GitHub tokens, and CI/CD secrets that were never tied to the central directory.
- Ending a contractor engagement but leaving a service account active in a shared vault because the application owner and identity team use different approval paths.
- Decommissioning an AI agent after a pilot ends, yet failing to disable the tool permissions, API tokens, and webhook credentials that still let it act.
- Cleaning up a third-party integration after a vendor contract expires, while downstream systems continue to trust cached certificates and static credentials.
- Using findings from the Top 10 NHI Issues alongside NIST Cybersecurity Framework 2.0 to prioritise high-risk revocations first.
NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which explains why cleanup lag often persists even when human offboarding appears complete. The Ultimate Guide to NHIs is useful here because it frames offboarding as a lifecycle control, not a single ticket status.
Why It Matters in NHI Security
Cleanup lag matters because attacker dwell time and legitimate revocation delay can overlap. Every extra hour of unresolved access increases the chance that a dormant service account, token, or certificate becomes the easiest path back into production. This is especially damaging in NHI environments where privileges are broad, ownership is unclear, and revocation often depends on manual handoffs.
NHIMG research reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly remediation can move when cleanup is not automated. That delay is not just an administrative issue; it is a control failure that can turn an ordinary offboarding event into a breach opportunity, as seen across cases in the 52 NHI Breaches Analysis and the Cisco DevHub NHI breach.
Practitioners should treat identity cleanup lag as a measurable control gap, not a vague after-the-fact concern. Organisations typically encounter the consequence only after a former identity, expired integration, or abandoned agent is used in a post-incident review, at which point the lag has become operationally unavoidable to address.
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-02 | Covers secret and credential revocation gaps that extend identity cleanup lag. |
| NIST CSF 2.0 | PR.AA-01 | Identity assurance and lifecycle controls require timely removal of no-longer-valid access. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust requires continuous verification and immediate invalidation of stale access paths. |
Continuously re-evaluate trust and remove access as soon as the identity relationship ends.
