Notifications
Clear all
Topic starter
06/06/2026 1:55 am
TL;DR: Orphaned and stale non-human identities can remain enabled with active permissions long after the application, vendor, or task they supported has ended, expanding attack surface and creating backdoors, according to Oasis Security. The governance gap is not just discovery but accountable offboarding, because access that is never retired becomes standing risk.
NHIMG editorial — based on content published by Oasis Security: Decommissioning orphaned and stale Non Human Identities
Questions worth separating out
Q: What breaks when an orphaned NHI is not decommissioned?
A: A forgotten NHI becomes a live access path with no current business owner, which means it can keep reaching systems long after the task or vendor relationship ended.
Q: Why do stale service accounts increase breach risk in cloud environments?
A: Stale service accounts often retain permissions even when the application or workflow they supported is gone.
Q: How do security teams know if an NHI is actually safe to remove?
A: They need three signals together: clear ownership, recent or provable lack of usage, and dependency mapping that shows no business service still depends on the identity.
Practitioner guidance
- Tie identity retirement to business offboarding Add NHI retirement steps to vendor offboarding, application replacement, migration closeout, and employee role-change workflows so stale access cannot survive the process that created it.
- Require ownership and usage evidence before deletion Do not decommission any NHI without a named owner, recent usage confirmation, and a dependency check that shows no production or third-party system still relies on it.
- Reconcile active permissions against the current business purpose Review every dormant or low-activity NHI for privilege scope, and remove any permissions that no longer match the identity's present role or retired function.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- A practical offboarding workflow for stale and orphaned NHIs across vendor exits, migrations, and application replacements
- The visibility and context checks used to decide whether a non-human identity is truly unused before removal
- Risk-based prioritisation logic for privileged, external-facing, and sensitive-data NHIs
- Operational guidance on avoiding business disruption when retiring machine identities
👉 Read Oasis Security's analysis of decommissioning orphaned and stale non-human identities →
Orphaned NHI decommissioning: what IAM teams are missing?
Explore further
06/06/2026 3:17 am
Orphaned NHI decommissioning is a lifecycle control, not a cleanup task. The control failure is not the existence of inactive technology, but the absence of a reliable offboarding state for identities that still hold permission. When a service account or token remains enabled after its business purpose ends, the environment has not merely accumulated clutter. It has preserved an access path that should have been retired, and practitioners should treat that as a governance defect, not an inventory issue.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who should be accountable for orphaned NHI offboarding?
A: Accountability should sit with the system or service owner, with IAM or security enforcing the governance standard and operations confirming dependencies. If no owner can be named, that is itself a control failure because no one can certify the identity's continued need. A retired identity without ownership is a governance gap, not an exception.
👉 Read our full editorial: Decommissioning orphaned NHIs is a lifecycle governance problem
