1. The Known Risk That Keeps Reappearing

Every identity and security team knows orphan accounts exist.

They can appear when employees leave, contractors roll off, teams reorganize, projects end, or applications change ownership. What remains is stale access: user profiles, admin accounts, shared credentials, service accounts, and application-specific users that no longer have a clear owner or valid business purpose.

The risk is obvious: access remains active after the reason for that access is gone.

The data backs up what identity teams already see in practice. In a 2022 Beyond Identity study, 83% of respondents said they continued accessing accounts from a previous employer after leaving, and 56% said they had used that continued access to harm a former employer. [1] 

‍

Years earlier, OneLogin found that deprovisioning failures had already crossed from just being an operational gap to a breach contributor, with 20% of organizations saying failure to remove employees from applications had contributed to a data breach. [2]

That is what makes orphan accounts so frustrating. This is not a new category of identity risk. It is not a mysterious attack technique. It is one of the most familiar problems in identity security.

But eliminating orphan accounts at enterprise scale has been nearly impossible.

2. Why Cleanup Efforts Fall Short

For well-governed applications, identity teams have made real progress. Access can often be created, updated, and removed as employees join, move, or leave the organization.

The problem is the long tail of applications that sit outside that coverage: business-owned SaaS tools, legacy systems, admin consoles, local user stores, and applications with limited or unusable APIs.

That is where orphan accounts survive.

Cleaning them up still depends on manual work: logging into applications, exporting account lists, matching users against the workforce directory, deactivating accounts, and documenting the result.

Across hundreds of applications, that work becomes expensive, inconsistent, and difficult to repeat. As a recurring control, it is nearly impossible to sustain manually.

So orphan account cleanup becomes a campaign instead of a continuous process. Teams run a review, remove what they can, defer what needs investigation, and may skip applications that are too costly or difficult to include. The cleanup is never truly complete.

The risk is not theoretical. In 2024, Tile/Life360 reported a large data breach and it was later confirmed that the hacker used login credentials that belonged to a former Tile employee to access Tile’s customer support systems. [3]

The details matter less than the pattern: an account that should no longer have provided access was still usable inside a real business application. That is exactly why orphan accounts are dangerous. Old access does not need to look suspicious to become an active breach path.

The lesson is simple: old access that still works can become an active breach path.

This is why orphan accounts keep coming back. The problem requires a way to continuously inspect application state, compare accounts against trusted identity data, and remove stale access before it becomes a standing risk.

3. How Redblock Changes the Model

Redblock changes the scale of orphan account detection by changing how application coverage works.

Redblock’s AI Agents are deployed directly on disconnected applications. This lack of reliance on APIs or connectors allows the agents to perform any and all identity operations that currently take days of manual work to perform. The agents can aggregate accounts, roles, entitlements, status’s, and configurations across 100s of applications at the same time. Pipelines can be configured to automatically structure the data in any desired format and piped directly into any identity system, while also simultaneously checking it against the organizations HR systems.

Accounts that no longer map to an active employee or owner can be flagged as potential orphans. Because the process can run frequently, Redblock can identify existing orphan accounts, detect new ones, and also complete the remediation by off-boarding the user without any need for human intervention.

Auditability is also built into the execution process. Each run generates a full activity record, including findings, remediation actions, timestamps, and logs. Identity teams can review which applications were checked, which accounts were flagged, and what action was taken.

‍

This turns orphan account cleanup into a repeatable control instead of a recurring project.

4. From Cleanup Project to Continuous Control

The goal is not another orphan account report.

Reports are useful, but they do not remove access. Reviews are useful, but they often happen after risk has already accumulated. Tickets are useful, but they still rely on someone completing the action in the target application.

The real shift is moving from awareness to execution.

Orphan accounts should not be treated as a cleanup project that restarts every quarter or every audit cycle. They should be continuously checked, remediated, and prevented from rebuilding in the background.

That is what Redblock enables: a way to move orphan account management from periodic discovery to continuous control.

Orphan accounts were always known.

Now they can be found, removed, and controlled continuously.

‍

References

[1] Beyond Identity: https://www.beyondidentity.com/resource/former-employees-admit-to-using-continued-account-access-to-harm-previous-employers

[2] MSSP Alert: https://www.msspalert.com/research-article/onelogin-study-many-orgs-struggle-with-ex-employee-app-deprovisioning?

[3] Engadget: https://www.engadget.com/a-hacker-obtained-tile-customers-personal-information-171632302.html