Why Identity Sprawl Is the Hidden Risk in Most Business Environments

In May, I gave a talk at BSides Charlotte 2026 on identity management in modern environments. The audience was cybersecurity practitioners, but the core idea applies to virtually every organization I’ve worked with: where does your actual security risk live?

The short answer: it lives in identity. And in most environments, identity is fragmented across systems that don’t talk to each other. That fragmentation is where modern breaches start.

The full talk is above. The rest of this post is the core argument in written form, with a bit more detail on the practical side for anyone evaluating how identity is managed in their own environment.

The question that exposes the problem

The most useful question I’ve found for diagnosing identity risk in any organization is this: if a user is terminated on Friday, what still works on Monday?

In most environments, the answer is “more than you’d think.” The domain account is disabled. The email is shut off. But the user still has access to the CRM. To the file sharing platform. To the niche project management tool the marketing team adopted last quarter. To the financial system that was never tied into central identity. To the VPN. To a handful of SaaS apps that were set up independently over the years.

None of those systems are broken. They’re just not coordinated. And that uncoordinated access is exactly where modern security failures happen.

What identity sprawl actually looks like

I want to emphasize something from the talk: identity sprawl isn’t chaos. It’s accumulated complexity. Nobody designs it intentionally. It happens because organizations grow, software gets added, people leave, acquisitions happen, and identity systems get layered on top of each other over years.

A typical mid-sized organization has identity living in some mix of: Active Directory or Entra ID for the main domain, Microsoft 365 or Google Workspace for productivity, a CRM, an ERP or financial system, document management or file sharing tools, HR and payroll systems, departmental SaaS tools the central IT team may not even know about, VPN access that evolved separately, and a long tail of niche applications that each have their own user lists.

That’s frequently 15 to 30 systems where identity lives. Each has its own user list. Its own authentication rules. Its own MFA settings, if any. Its own offboarding process. And in most cases, no single source of truth that says “here is every account this person has, across every system, with what level of access.”

Why this is what attackers want

From a malicious actor’s perspective, identity sprawl is incredibly valuable. It creates options. If identity is centralized, there’s one control point. If it’s fragmented, attackers get to choose where to enter — and they generally choose the path of least resistance.

They can find out if MFA is inconsistent across systems. They can test reused credentials everywhere. They can find an account that looks low-risk in one system but has elevated access in another. And because authentication logs across these systems are scattered — different formats, different visibility, different tools — detection slows down and dwell time increases.

Instead of one clear signal, you get fragmented visibility. That’s a worse position to defend from than most organizations realize.

Why this happened

Legacy identity systems weren’t built wrong. The world was just different. Earlier in my career, everyone went to an office. They authenticated to an on-prem domain behind a firewall. Applications were deployed directly to users. There was no SaaS. The network was trusted. All devices stayed behind that firewall and connected to AD with group policies, and life was relatively simple.

That’s not the world we live in today. Users are remote. Environments are hybrid. Most applications live in the cloud. People take devices everywhere. Most access happens over the internet. The environment evolved, but identity often didn’t evolve at the same pace. That mismatch is where most of the risk lives.

What “centralized identity” actually means

The solution isn’t moving identity to the cloud. It’s centralizing control. In practice, that usually means:

• One authoritative identity source — typically Entra ID, Okta, or Google Identity — that owns every user account
• Single sign-on across as many applications as possible, so users authenticate once and authorization flows from one decision rather than each app deciding independently
• MFA enforced everywhere, including for admin accounts, service accounts, and any account that can access sensitive data
• Conditional access policies that restrict sign-ins by location, device compliance, and risk signals — and that are actually enforced, not stuck in report-only mode forever
• Privileged access separated from daily-use accounts (admin credentials aren’t the same as the everyday login)
• Centralized logging so authentication activity across all systems lands in one place

The pattern matters more than the product. You’re not just changing how users log in. You’re changing where control lives, where policy lives, where visibility lives. That’s the important piece.

The mistake most projects make

Most identity projects fail because they’re treated as one-time migrations. “We’ll connect AD to the cloud, and we’re done.” But the problem isn’t where identity exists. It’s where control exists.

If you don’t clean up users and access first, you’re just migrating complexity. If you enable SSO without the right policies behind it, you’ve improved convenience without improving security. If you skip the inventory phase, you’ll discover six months in that there are SaaS apps nobody told you about that bypass the entire model you just built.

The right approach

The sequence we use:

1. Inventory first. Every system, every account, every service account, every local admin. Where does identity actually live in the organization today?
2. Establish the primary identity platform. Usually Entra ID for Microsoft environments, Google Identity for Workspace organizations. Sometimes Okta when complexity warrants it.
3. Bring critical applications under that platform. SSO and SCIM-based provisioning for the apps that support it. Document the rest.
4. Reduce legacy authentication. Disable basic auth where possible. Move toward modern authentication everywhere.
5. Implement conditional access progressively. Start with low-risk policies in report-only, then enforce. Iterate based on what breaks.
6. Document and monitor. Centralize logging. Build the incident response runbook. Test it.

This is a months-long process, not a weekend project. But it’s the work that actually reduces real risk, and it makes everything downstream — incident response, audits, onboarding and offboarding, regulatory compliance — dramatically more tractable.

The hard part isn’t technical

A theme from the talk that bears repeating: in identity projects, the technical work is the easy part. Configuring conditional access, deploying SSO, integrating SCIM — those are well-documented engineering tasks. They have right answers.

The hard part is operational. It’s getting an executive sponsor who understands why MFA exceptions for leadership undermine the entire program. It’s helping a department head understand that her admin account isn’t the same as her daily login. It’s deciding how to handle the legacy application that doesn’t support SSO and seems to keep working fine without it.

That balance — between security and operational reality — is where these projects either succeed or stall. There’s no universal right answer. There’s the answer that fits your organization’s risk tolerance, your operational commitments, and what you can actually sustain.

Why this matters more than it used to

Identity has become the critical control plane in modern business environments. When identity is fragmented, everything else becomes reactive instead of preventative. Incident response slows down because you’re chasing logs across systems. Offboarding is incomplete because you can’t see every access path. Compliance documentation is a scramble because the underlying environment doesn’t match the policies on paper.

Centralized identity flips this. Disable an account once and access is revoked everywhere. See authentication activity in one place. Apply policy consistently. Onboarding and offboarding take minutes instead of hours, with no gaps. That’s a different operational posture, and it shows up in every interaction with security, IT, and compliance from then on.

Closing the gap

If you read the question at the start of this post — “what still works on Monday?” — and weren’t sure of the answer, that’s worth taking seriously. The question is uncomfortable on purpose. It’s the same question I’d want answered if I were evaluating a vendor, a partner, or a firm I was about to share sensitive data with.

If you’d like to walk through how identity is structured in your environment, we’d be happy to do that. No pitch deck. We’ll look at what you have, tell you candidly what’s working and what isn’t, and help you figure out what’s worth tackling this quarter versus this year.