Orphan accounts: how to find and remove them

Orchid Security's Orphan & Local Accounts report (August 2026) defines orphaned accounts as 'user or service accounts left active after owners depart or change roles', and local accounts as 'credentials stored directly on systems/applications, often unmanaged and unmonitored'. The two overlap: a local account is not tied to the identity provider, so when its owner leaves nothing disables it, and it becomes an orphan.

NIST SP 800-53 Rev. 5 AC-2(3) names the conditions under which accounts should be disabled: when they have expired, are no longer associated with a user or individual, are in violation of policy, or have been inactive for a defined period. An orphan account meets at least one.

• The application is not connected to the IGA, so no automatic deprovisioning reaches it.
• The account is local to the app and was never linked to the directory identity.
• The account was named for a role or a vendor (admin, svc_billing, vendor_support), not a person, so it matches nobody in HR.
• The owner moved rather than left, so no leaver event fired.
• Offboarding tickets for disconnected apps were raised and never closed.

1. Build the application list. Include apps outside SSO: the CMDB, finance records of software spend, and discovery tools are the usual sources.
2. Pull every account from every app. Connected apps: from the IGA. Disconnected apps: export, or use a tool that reads accounts inside the app.
3. Reconcile to HR. Match each account to a current employee or contractor by a stable attribute (employee ID, email). Microsoft's Entra account discovery report is an example: it lists application users that match no Entra ID user.
4. Flag the rest: no match, matched to a leaver, or no activity for your inactivity threshold.
5. Assign an owner to every non-human account. If nobody claims it, treat it as orphaned.

1. Disable, do not delete. Some orphan accounts run scheduled jobs or integrations.
2. Notify the app owner and wait a fixed period (for example 14 days) for claims.
3. Assign an owner to any account that is claimed and still needed; rotate its credentials.
4. Delete the rest and record: account, app, date, approver.
5. Fix the cause: connect the app, or add it to the leaver ticket template.

At least as often as your access reviews, and continuously where tooling allows. DORA's technical standard requires access rights to be reviewed at least once a year for staff with access to ICT assets supporting critical or important functions (EU 2024/1774, Article 21); many organizations reconcile quarterly. Tools that watch accounts continuously (Orchid, Veza, Lumos identity analytics) shorten the time an orphan account stays open.