Access, secrets, and integrations that remain active after an application is no longer in active business use. The term captures the security gap between commercial retirement and technical decommissioning, where permissions persist longer than accountability.
Expanded Definition
Identity residue is the leftover security footprint of an application after business owners have stopped using it but technical assets still exist. That footprint can include service accounts, API keys, certificates, OAuth grants, inbound integrations, and cloud entitlements that were never revoked. In NHI governance, the concept sits between application retirement, access lifecycle management, and decommissioning discipline. It is broader than “orphaned access” because the problem often includes active dependencies that no longer have a clear owner. The Ultimate Guide to NHIs treats lifecycle control as a core requirement, while NIST Cybersecurity Framework 2.0 frames this as a governance and asset-management problem that must be addressed before residual access becomes exposure. Definitions vary across vendors on whether identity residue must be fully active to count, or whether dormant but unreclaimed artifacts are included, so the operational boundary should be set by policy. The most common misapplication is treating application retirement as equivalent to access revocation, which occurs when business sign-off happens before technical teardown is completed.
Examples and Use Cases
Implementing identity residue controls rigorously often introduces shutdown complexity, requiring organisations to balance fast application retirement against the effort needed to find and revoke every connected identity and secret.
- A decommissioned internal reporting app still has a cloud service principal that can read storage buckets, even though the front-end is no longer reachable.
- A customer portal is sunset, but its OAuth refresh tokens continue to renew access to downstream billing APIs until the integration owner manually revokes them.
- A CI/CD pipeline for an old product branch still contains long-lived deployment keys, creating residual access long after the product has been discontinued. The pattern is consistent with findings highlighted in the Top 10 NHI Issues.
- A third-party analytics connector remains active after a SaaS contract ends, leaving shared secrets and webhook permissions in place until a post-termination review catches them. This is one of the patterns examined in the 52 NHI Breaches Analysis.
- An inactive batch job account persists in RBAC groups because no offboarding workflow ties application retirement to entitlement removal, an issue that aligns with identity lifecycle principles in NIST guidance.
Why It Matters in NHI Security
Identity residue matters because attackers rarely need a new foothold when a retired system still has valid credentials, permissions, or integrations waiting to be reused. In NHI environments, this is especially dangerous because non-human identities are often over-privileged and poorly inventoried. NHIMG reports that 71% of NHIs are not rotated within recommended time frames, and only 20% of organisations have formal processes for offboarding and revoking API keys, which makes residue a durable control gap rather than a one-time cleanup issue. That gap becomes more severe when secrets are embedded in code, configs, or automation paths, where teardown is easy to miss and audit trails are weak. Residual access also complicates incident response because teams must determine whether a compromise is tied to an active workload or to an abandoned dependency. The Ultimate Guide to NHIs and the JetBrains GitHub plugin token exposure illustrate how overlooked machine credentials can persist past their intended purpose. Organisations typically encounter identity residue only after a breach review, an audit finding, or a failed application shutdown, at which point the term becomes 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-04 | Covers lifecycle and offboarding failures that leave residual NHI access behind. |
| NIST CSF 2.0 | ID.AM | Asset management requires knowing what identities and integrations still exist after retirement. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes access must be continually verified, not left behind after system retirement. |
Revoke dormant machine access and revalidate every remaining integration before trusting it.
