Identity sprawl

what it is

Identity sprawl is the condition where a single person has multiple accounts across your IT environment, and those accounts are not centrally coordinated. One account in your main IdP. A direct login to a project management tool that predates your SSO configuration. A separate account in a cloud platform with a personal email address. A legacy username in an older internal system.

Each account is managed independently. The user may not even be aware of all of them. IT certainly doesn't have a consolidated view. When something needs to happen, like an offboarding or an access review, the process only reaches what it can find.

Identity sprawl is a visibility problem. It accumulates from adding tools, changing providers, and connecting systems over time without a central identity layer governing all of them. Individual employees rarely cause it.

why it accumulates

Every time a new application is adopted and doesn't connect through SSO, a new identity island forms. The user gets a separate account with a separate credential. That account is managed by the application, not by your IdP.

This happens fast in environments that grew through tool adoption rather than central IT governance. Teams adopt SaaS products they find useful. Some are connected to the main directory; many are not. Over time, a user can have dozens of separate credentials across different platforms.

The IdP was often configured after many of these tools were already in use. Migrating existing accounts to SSO requires project time and sometimes licensing or platform changes. It gets deferred. The islands persist.

what it costs you

The direct cost is offboarding failure. When someone leaves, the offboarding process closes the accounts it knows about. Accounts outside the main directory, in tools that bypass SSO, don't get closed. That's the mechanics behind why 83% of employees admit they still have access to at least one account from a previous employer (Beyond Identity, 2022, self-reported).

The second cost is access review gaps. An access review that pulls data from your IdP captures users authenticated through it. Users with direct logins to applications that bypass the IdP are invisible to that review. Their permissions accumulate outside any governed process.

There's also a credential risk dimension. Each separate login is another password. Each password is another credential that can be phished, reused from an external breach, or stored insecurely. In environments where users manage many separate accounts, password hygiene often suffers.

what works

The measurement is a comparison run application by application: each app's exported user list against the IdP's active users. Anyone present in an application without a corresponding active IdP entry is either on a direct login or orphaned, and both warrant review. Running that comparison across the whole portfolio also produces the scope document that matters most, a record of which applications connect through SSO and which maintain their own login pages, because the second group is the entire problem.

Migration to SSO follows risk rather than alphabetical order. Applications holding sensitive data, exposing admin functionality, or carrying large user bases come first. SSO migration costs configuration time and sometimes an upgraded license tier, which is why it gets deferred indefinitely in environments that never rank the queue, and why ranking it is how the work actually happens.

Some legacy and local applications will never support SSO, and those need a standing substitute rather than silence: a manual user-list pull on a defined schedule, cross-referenced against active employees, so the island at least gets visited regularly even if it can never be connected.

The forward-looking control is procurement. When SSO support is a requirement, or at minimum a heavily weighted preference, in every new tool evaluation, new identity islands stop forming, and consolidation becomes a shrinking backlog rather than a treadmill.