Notifications
Clear all
Topic starter
11/08/2026 3:25 pm
TL;DR: Orphan accounts persist because manual deprovisioning cannot keep pace with disconnected apps, legacy admin consoles, and business-owned systems, according to Redblock’s analysis and cited breach examples. Periodic cleanup leaves stale access alive long enough to become a standing breach path, so continuous lifecycle enforcement matters more than another review cycle.
NHIMG editorial — based on content published by Redblock: Orphan accounts were always a known problem. They were just too hard to fix
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.
Questions worth separating out
Q: How should security teams handle orphan accounts in disconnected applications?
A: Treat disconnected applications as a lifecycle control problem, not a one-off cleanup task.
Q: When does orphan-account cleanup fail in practice?
A: It fails when cleanup depends on manual exports, ticket follow-up, or application owners remembering to act.
Q: What do identity teams get wrong about orphan accounts?
A: They often treat orphan accounts as an audit finding instead of an operational control gap.
Practitioner guidance
- Inventory orphan-prone applications Identify every system that still relies on manual review, export-based reconciliation, or separate admin action for account removal.
- Tie offboarding to verified removal Define offboarding as complete only when the account is removed or disabled in the target application, not when a ticket is raised or a request is approved.
- Measure cleanup as a continuous control Track orphan-account detection frequency, time to revocation, and the share of applications still outside automated coverage.
What's in the full article
Redblock's full blog covers the operational detail this post intentionally leaves for the source:
- The pipeline-style workflow Redblock describes for aggregating accounts, roles, entitlements, and configuration data across disconnected applications
- How the article frames automated offboarding without human intervention in target systems
- The example of how Redblock structures findings, timestamps, and remediation logs for auditability
- The product-level explanation of how continuous orphan-account checks are intended to replace campaign-based cleanup
👉 Read Redblock's analysis of orphan accounts and continuous lifecycle enforcement →
Orphan accounts: what IAM teams need to do differently now?
Explore further
11/08/2026 3:34 pm
Orphan accounts are a lifecycle failure, not an exception case. Identity programmes often treat them as an edge condition because they appear in different forms across user, admin, shared, and service access. In practice, they are the predictable outcome of incomplete offboarding across fragmented application estates. The practitioner conclusion is that orphan-account control belongs in core IAM and IGA governance, not in an occasional cleanup project.
A few things that frame the scale:
- From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: What should organisations do if offboarding cannot be automated everywhere?
A: Prioritise the systems with the highest privilege and the weakest governance first. Where automation is not possible, create strict manual controls with ownership, deadlines, and evidence of completion. The programme should measure how much stale access remains, not just how many cases were opened.
👉 Read our full editorial: Orphan accounts expose the limits of manual IAM cleanup
