Orphan accounts and disconnected applications: six myths and the facts

Fact: it removes access to applications that rely on the directory or identity provider for sign-on. A local account, stored inside the application itself, is not touched. Orchid Security's Orphan & Local Accounts report describes orphaned accounts as accounts left active after owners depart or change roles, and local accounts as credentials stored directly on systems or applications. The combination of the two is the typical leaver gap.

Fact: single sign-on governs how users log in. It does not create or remove accounts inside the application, and many applications that support sign-on still allow local logins, local admin accounts or internal roles. Provisioning and deprovisioning need a connector or a protocol such as SCIM, and local accounts need to be found separately.

Fact: an IGA platform covers the applications it is connected to. SailPoint's own blog frames the problem as customers often having hundreds or thousands of applications that need to be connected. Microsoft documents a manual procedure for applications that do not support provisioning in Entra ID Governance: export users to CSV, match them to Entra users, then review. Both describe real work for every application outside the connector list.

Fact: a review only covers the accounts loaded into it. If a disconnected application's accounts were never extracted and reconciled, its orphan accounts are not in the campaign, and the review evidence says nothing about them. Account reconciliation before the campaign is what puts them in front of a reviewer.

Fact: former employees are one source. Service accounts, integration accounts and break-glass accounts become orphans when the person who created or owns them leaves. Orchid Security's Identity Gap: 2026 Snapshot states that 67% of non-human accounts are created directly within applications (source), which places many of them outside central provisioning from the start. NIST SP 800-53 control enhancement AC-2(3) asks organizations to disable accounts no longer associated with a user or individual, whatever their type.

Fact: some unmatched accounts are service accounts that a production process depends on. Deleting them first and asking later causes outages, and outages make the next clean-up harder to approve. The safer order is to flag unmatched accounts, find an owner, disable after confirmation, and delete after a retention period, recording each step. The orphan accounts guide covers removal in that order.

Each one treats the connected part of the estate as the whole estate. The fix is the same in every case: an application inventory that includes disconnected applications, an account list from inside each one, and a record of what was done. Tools differ in how much of that they automate; the comparison scores each on disconnected-app coverage and orphan and local account discovery.