Orphan accounts expose the limits of manual IAM cleanup

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Redblock's blog post: Manual IAM cleanup breaks down when access lives across disconnected applications and legacy admin surfaces.

Why it matters: It matters because identity teams still inherit stale access they cannot reliably find or remove with periodic reviews, which turns lifecycle gaps into standing breach paths.

By the numbers:

• 83% of respondents said they continued accessing accounts from a previous employer after leaving.
• 20% of organizations said failure to remove employees from applications had contributed to a data breach.

Context

Orphan accounts are access paths that remain after the person, contractor, team, or business process that created them is gone. In identity governance terms, the problem is not discovery alone but the inability to keep account state aligned with workforce and ownership data across every application.

Manual cleanup fails when coverage depends on logging into individual systems, exporting account lists, and matching them against directories by hand. That model can work for tightly governed applications, but it breaks down across long-tail SaaS tools, admin consoles, local user stores, and applications with poor API support.

The result is a recurring lifecycle gap in NHI and human IAM programmes: access outlives its business purpose, then becomes difficult to prove stale before it is abused. That is the operational failure mode this article is trying to surface.

Key questions

Q: What breaks when orphan account cleanup still depends on manual reviews?

A: Manual reviews break because they cannot keep pace with application sprawl, local user stores, and ownership changes. The result is partial deprovisioning, inconsistent documentation, and stale access that remains valid between review cycles. In practice, the control fails when removal is treated as a campaign instead of a continuous lifecycle action.

Q: Why do orphan accounts create breach risk even when teams run access reviews?

A: Access reviews answer whether an account should exist on paper, not whether it was actually removed everywhere it matters. If the target application still accepts the account, stale access remains a live path. The risk grows when privileged or support-facing accounts survive offboarding and can still reach operational systems.

Q: How can IAM teams tell whether orphan account governance is working?

A: Look for evidence that deprovisioning changes application state quickly and consistently across the long tail of systems. Strong programmes can reconcile accounts against trusted source data, remove stale access repeatedly, and show auditable proof of completion. Weak programmes rely on manual exception handling and periodic cleanup.

Q: Who is accountable when former users still retain access?

A: Accountability sits with the identity and application owners who failed to ensure access was removed when the business event occurred. HR may trigger the event, but IAM, IGA, and system owners are responsible for making revocation complete, auditable, and timely. Regulatory frameworks expect that access ends when the need for access ends.

Technical breakdown

Why disconnected applications create orphan account blind spots

Orphan accounts survive where identity governance does not have reliable, real-time control over the target system. Disconnected apps often lack usable APIs, consistent account inventories, or event hooks that would let IAM systems reconcile identity state automatically. That forces teams back into manual exports, spreadsheet matching, and one-off deactivation work. The technical issue is not just coverage. It is that account state becomes a local property of each application instead of a centrally governed lifecycle attribute. Once that happens, stale users, shared accounts, and application-specific identities can remain active long after ownership changes.

Practical implication: build inventory and reconciliation coverage for the applications that cannot currently be governed through standard connector paths.

Why manual deprovisioning becomes a weak recurring control

Manual deprovisioning is a control, but only when it is repeatable enough to stay current. In large estates, the process turns into a campaign because each application requires separate human effort, review, and documentation. That introduces delay, inconsistency, and partial coverage. Controls that depend on people to remember, chase, and document each removal tend to degrade into periodic hygiene rather than continuous governance. In identity terms, the control failure is not absence of intent. It is that revocation is too operationally expensive to keep pace with account creation and change.

Practical implication: measure deprovisioning as a continuous lifecycle control, not as an audit task that happens after risk accumulates.

How stale access becomes an active breach path

A dormant or forgotten account is dangerous because it may still authenticate successfully even when no one remembers why it exists. If the account retains privileged access, application support access, or shared credentials, the attacker does not need novel exploitation. They only need an account that still works. The article’s breach examples illustrate a familiar identity pattern: access survives the organisational event that should have removed it. That turns orphan accounts into standing breach paths rather than theoretical leftovers. The control issue is lifecycle enforcement, not user awareness.

Practical implication: prioritise orphan cleanup in systems where old credentials can still reach customer data, admin tools, or support consoles.

Threat narrative

Attacker objective: The objective is to use still-valid but no-longer-owned access to reach business systems that should have been offboarded.

1. Entry begins when an attacker or former user gains access through an orphaned account that still authenticates inside a live business application.
2. Credential abuse continues because the account remains valid after the original employment or ownership relationship has ended.
3. Impact follows when stale access reaches customer support systems, admin consoles, or other operational tooling that was never removed from the lifecycle path.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Orphan accounts are a lifecycle failure, not a discovery problem. The article correctly shows that the hard part is not knowing orphan accounts exist. The hard part is keeping account state synchronized with real ownership across disconnected applications where revocation cannot be executed reliably. That makes orphan cleanup a governance issue, not just an inventory issue. Practitioners should treat stale access as a lifecycle control gap before it becomes a breach path.

Manual cleanup turns revocation into a campaign, and campaigns are not controls. When deprovisioning depends on human logins, exports, matching, and documentation, the result is partial coverage and uneven timing. The enterprise then accumulates residual access between review cycles. That is why periodic cleanup cannot be the operating model for orphan account governance. Practitioners need continuous enforcement for the applications that most often escape standard lifecycle automation.

Disconnected applications expose the last-mile identity gap. The article is strongest when it points to the long tail of business-owned SaaS, legacy systems, local user stores, and admin consoles. Those systems are where lifecycle promises usually fail in practice. The issue is not exotic exploitation but ordinary access persistence in places central IAM tooling does not reach well enough. Practitioners should assume the weakest governance sits in the least visible apps.

Continuous lifecycle enforcement is the real control boundary. Reports, reviews, and tickets are useful only if they translate into removal in the target system. Once an account can survive across ownership changes, the organisation has lost control of its identity lifecycle. The implication is that offboarding must be measured by effective revocation, not by process completion. Practitioners should design for removal that actually changes application state.

From our research library:

• 74% of organizations report identity-related breaches, and privileged access is a leading cause of lateral movement.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Last-mile identity gap: Orphan accounts persist where the identity programme stops at centrally governed applications and never reaches the systems that hold the most residual access. The real programme test is whether deprovisioning can still change state in business-owned tools, legacy consoles, and local user stores.

The operational lesson is that lifecycle governance has to be measured by successful removal, not by task completion. If access survives the offboarding event, the control has not finished, even if the ticket is closed and the review is documented.

For practitioners

• Map the disconnected application estate Identify business-owned SaaS tools, legacy systems, local user stores, and admin consoles that sit outside normal lifecycle automation. Rank them by access sensitivity and how often ownership changes leave stale accounts behind.
• Reconcile account ownership against HR and directory data Run repeated comparisons between application account lists, HR status, and known application ownership so orphaned users, service accounts, and shared accounts are flagged before quarterly review cycles.
• Automate offboarding where manual removal keeps failing Replace ticket-driven removals with continuous execution paths that can deactivate accounts directly in the target application and produce an audit record for each action.
• Prioritise privileged orphan accounts first Focus remediation on admin consoles, support tools, and applications that can reach customer data or operational controls, because those accounts create the highest blast radius if left active.

Key takeaways

• Orphan accounts expose the gap between identity process completion and actual access removal in the target application.
• The evidence in the article shows that stale access can survive long enough to become a breach path, especially in systems that sit outside standard automation.
• The control that matters is continuous lifecycle enforcement, because periodic cleanup cannot reliably keep up with disconnected applications.

Key terms

• Orphaned Account: An orphaned account is an identity that remains active without a clear owner or business purpose. These accounts are dangerous because they often escape review, retain unnecessary access, and provide attackers with low-friction entry points into otherwise governed environments.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.
• Last-mile Identity Gap: The point where a central identity decision still has to be executed inside each downstream application or trust endpoint. This is where policy becomes operational reality, and where fragmented ownership, manual consoles, and inconsistent workflows most often break assurance.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.