Decommissioning orphaned NHIs is a lifecycle governance problem

At a glance

What this is: This is an analysis of why orphaned and stale non-human identities persist, and the key finding is that poor offboarding and visibility turn unused accounts into long-lived security exposure.

Why it matters: It matters because IAM, PAM, and NHI teams must treat decommissioning as a control lifecycle, not an afterthought, or dormant credentials will continue to widen access risk across machine and human programmes.

👉 Read Oasis Security's analysis of decommissioning orphaned and stale non-human identities

Context

Orphaned non-human identities are credentials, tokens, or service accounts that remain active after the work they supported has ended. In practice, they are not just clutter in an inventory. They are live access paths that can outlast the system, vendor, or migration project that created them, which is why NHI lifecycle management is a governance issue rather than a housekeeping task.

The problem grows when ownership is unclear, usage is hard to verify, and decommissioning requires cross-team coordination before anything can be retired. For teams managing service accounts, API keys, and SaaS integrations, the question is not whether stale identities exist, but whether the programme can prove they are identified, reviewed, and removed before they become an attack surface. See the NHI Lifecycle Management Guide for the lifecycle lens behind that work.

Key questions

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. That breaks least privilege, weakens accountability, and gives attackers a trusted foothold that standard user offboarding will not catch. The risk rises when the identity still has sensitive or external access.

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. In cloud environments, that makes them attractive because they can be overlooked by human access reviews, reused for lateral movement, and hard to distinguish from legitimate machine traffic. The result is longer dwell time and a larger blast radius.

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. If any one of those is missing, removal is a change-management decision, not a simple cleanup action. Safe offboarding is evidence-led, not assumption-led.

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.

Technical breakdown

Why orphaned NHIs remain enabled after business change

Orphaned NHIs usually survive because the system that created them is decoupled from the process that should retire them. A migration project ends, a SaaS tool is replaced, or a vendor relationship changes, but the service account, token, or API key remains active because no lifecycle trigger closes the loop. The technical problem is not only credential sprawl. It is that entitlement state, ownership metadata, and actual usage are rarely joined well enough to support safe decommissioning. Without that linkage, removal decisions rely on guesswork, and guesswork is where stale identities persist.

Practical implication: Build decommissioning triggers into change management and offboarding so retiring the business process also retires the identity.

Visibility and dependency mapping for NHI offboarding

Offboarding fails when security teams cannot answer three questions at once: what the identity is for, who owns it, and what breaks if it disappears. Dependency mapping matters because many NHIs sit between applications, storage systems, and third-party services, so an identity can appear idle while still supporting a fragile production dependency. That is why manual inventory work breaks at scale. If ownership, last-use data, and downstream dependencies are not available in one place, teams either leave the NHI enabled or remove it blindly, both of which are operationally expensive.

Practical implication: Require contextual inventory data before decommissioning any NHI that touches production, external services, or sensitive data.

Least privilege after decommissioning is still a control problem

Decommissioning is not only about turning an identity off. It is also about removing the permissions that would allow the same identity class to keep lingering with excessive access elsewhere in the environment. Orphaned NHIs often remain dangerous because they were over-provisioned from the start, so a forgotten account can still reach data stores, APIs, or admin paths. In governance terms, this is where lifecycle management and least privilege meet. If the programme does not reconcile active entitlements against business need, stale identities become a durable exception rather than a retired asset.

Practical implication: Reconcile active permissions against business purpose during every offboarding review, not only at creation time.

Threat narrative

Attacker objective: The attacker aims to reuse forgotten non-human access as a trusted path into systems that should no longer be reachable.

1. Entry occurs when an orphaned NHI remains active after the original business task, vendor relationship, or application has ended, leaving an unattended access path in place.
2. Escalation follows when the stale identity still carries active permissions, allowing an attacker or rogue insider to use it as a trusted foothold without triggering normal user-offboarding checks.
3. Impact comes from long-lived backdoor access into systems, data stores, or APIs, where the forgotten identity extends the attacker’s dwell time and widens the blast radius.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Visibility gaps create identity blind spots that traditional review cycles do not close. The article describes a familiar pattern: teams do not know which NHIs are unused, and they fear breaking dependencies if they remove them. That combination produces default inaction, which means access persists without challenge. This is exactly the kind of problem the NHI Lifecycle Management Guide and NIST Cybersecurity Framework approach through ownership, monitoring, and accountable removal, and practitioners should assume unverified identities are unsafe until proven otherwise.

Orphaned credentials become standing privilege by another name. A dormant identity with active permissions is structurally similar to any other standing access model: it exists outside the current business need, but remains available to anyone who finds it. Identity blast radius: the longer an unused NHI stays enabled, the more likely it is to become an internal backdoor rather than a forgotten record. The implication is that decommissioning must be measured as a control outcome, not a one-time administrative task.

The article exposes a familiar assumption failure in NHI governance: unused means harmless. That assumption was designed for environments where inactivity implied low risk and where ownership could be inferred from the surrounding application context. It fails when an NHI can remain enabled indefinitely, retain privileges, and sit outside traditional review paths. The implication is that programmes need a stronger retirement model for machine identities, because inactivity does not remove attackability.

Safe offboarding depends on proving both usage and dependency before removal. The article is right to emphasise context, because orphaned NHIs are rarely just a credential problem. They are usually a dependency problem wrapped inside an identity problem, which means governance teams need to join security state to operational state. Practitioners should therefore stop treating decommissioning as a simple delete action and instead manage it as a controlled retirement workflow grounded in ownership, usage, and downstream impact.

From our research:

• 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.
• For a broader lifecycle lens, see the NHI Lifecycle Management Guide for how offboarding, rotation, and ownership should fit together.

What this signals

Orphaned identities are becoming a board-level exposure because they sit at the intersection of lifecycle failure and access governance failure. When teams cannot prove that a credential is retired, the identity remains part of the attack surface even if no one remembers why it exists. The operational signal to watch is not just unused account count, but the age of unresolved offboarding exceptions.

Identity retirement debt: this is the gap between identities that should have been removed and identities that are still enabled. Once that debt starts to accumulate, decommissioning turns into a backlog management problem rather than a security control. Teams should watch for migrations, SaaS replacements, and vendor exits that create retirement work faster than IAM can process it.

The practical signal is whether service owners can answer ownership and dependency questions without manual triage. If they cannot, the programme is already dependent on informal memory, which does not scale across NHIs, human accounts, and future autonomous systems. That is the point where lifecycle governance needs to become more automated and more auditable.

For practitioners

• 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.
• Prioritise externally facing and privileged NHIs first Start remediation with identities that touch external services, sensitive data, or administrative paths, because those stale credentials create the highest blast radius if abused.

Key takeaways

• Orphaned NHIs are not dormant records, they are active access paths that can survive well beyond the business reason for existence.
• The scale of the problem is material, with 72% of organisations reporting or suspecting an NHI breach and compromised environments averaging 2.7 incidents.
• The control that matters most is controlled retirement, backed by ownership, usage evidence, and dependency mapping before removal.

Key terms

• Orphaned Nhi: A non-human identity that is no longer needed by the business but is still enabled and able to authenticate or authorise actions. In practice, it usually appears after migrations, vendor changes, or application replacements, and becomes dangerous when no owner is left to retire it.
• Nhi Offboarding: The controlled retirement of a non-human identity, including revoking access, removing credentials, and confirming that no downstream system depends on it. Good offboarding is evidence-led and coordinated, because deleting the wrong identity can break services while leaving the right one behind creates exposure.
• Identity Blast Radius: The amount of damage possible if a credential, token, or service account is abused. For non-human identities, blast radius is shaped by privilege scope, external reach, and how long the identity remains active after it should have been retired.

Deepen your knowledge

Orphaned NHI decommissioning and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a retirement process for service accounts, tokens, and SaaS integrations, it is worth exploring.

This post draws on content published by Oasis Security: Decommissioning orphaned and stale Non Human Identities. Read the original.