Identity Sprawl Isn't a Bug, It's the Result of Modern IT

Identity sprawl doesn't announce itself. It doesn't break systems or trigger alerts. It quietly expands in the background until an audit, a breach investigation, or a cost review forces someone to actually look.

Identity used to be predictable. Employees joined, accounts were created, access was granted through a handful of centrally managed systems, and if something went wrong, IT knew exactly where to look.

That reality is gone. Identities today get created everywhere: HR systems, SaaS apps, cloud platforms, CI/CD pipelines, vendor portals. Employees, contractors, partners, service accounts, bots, APIs. Some are provisioned automatically, some manually, some bypass IT entirely.

The result is simple and dangerous: identity is growing faster than any organization's ability to track, govern, or clean it up. In a mid-size company with 500 employees, total identity count can easily exceed 2,000 active accounts spread across 50-plus systems, many of them inactive, redundant, or orphaned, with nobody quite sure which ones.

Most IT teams can scale infrastructure. They can standardize devices and centralize logs. What they increasingly can't do with any confidence is answer a basic question: how many identities actually exist in the environment right now, and what can each one actually access?

That gap is where identity sprawl lives. It isn't about having too many users. It's about having too many unmanaged identity paths, accounts, roles, tokens, and permissions accumulating because the organization is moving faster than its controls can keep up.

And unlike shadow IT, identity sprawl doesn't announce itself. When it finally surfaces, IT usually gets blamed for a lack of governance, even though the real pattern looks like this:

• Contractors who left six months ago still holding admin privileges in critical SaaS tools
• Service accounts from a short-lived integration still active across multiple environments
• A team unable to answer an auditor's simple question about who has access to sensitive financial or patient data

The real issue runs deeper. Modern identity is event-driven, distributed across dozens of systems, and additive by design, with very few reliable removal paths built in. Identity sprawl isn't a tooling failure or a process miss. It's a built-in byproduct of how modern IT actually operates.

Identity Growth Is Event-Driven. Identity Control Isn't.

Modern identity doesn't wait for IT's schedule. It appears the moment a business event happens. A new hire starts Monday morning, and by lunch they have accounts in the HR system, email, Slack, Salesforce, and maybe three other SaaS apps. A contractor gets onboarded for a two-week project and is granted temporary admin privileges in Jira, the CI/CD pipeline, and a cloud environment. A new integration spins up a service account for automation.

Each of these identities gets created instantly, across multiple systems, often with nobody controlling the full lifecycle end to end.

Now consider what governance actually looks like on the other side. Reviews and cleanup run on schedules: quarterly access reviews, annual audits, monthly reconciliations. Even with the best intentions, there's a lag of weeks or months between when access gets granted and when anyone questions or removes it.

That lag is where sprawl breeds:

• Day 1: Access gets granted. Everything works fine.
• Month 2-3: Some of that access is no longer needed, but IT doesn't notice, because there's no automated alert or continuous review flagging it.
• Month 6: Temporary accounts have become permanent by accident. Service accounts have proliferated. OAuth tokens have accumulated. None of it has been revoked, because permissions in most systems are additive by default.

By the time the next review cycle arrives, the identity landscape has changed so much that the quarterly process feels like chasing a moving target. The faster an organization grows, the faster new identities appear. The slower governance moves relative to that pace, the more sprawl accumulates.

Speed creates identities. Delay creates sprawl. If access control can't move at the pace identity creation does, sprawl isn't a risk, it's a guarantee.

Identity Is Fragmented Across Systems, So Sprawl Hides in Plain Sight

Most organizations know where employee email lives and know their HR system tracks every hire. Far fewer can say with confidence everywhere else an employee's identity actually exists.

Modern organizations run on a patchwork of identity stores, each one acting as though it's authoritative:

• HRIS is the source of truth for employees, but contractors, vendors, and temporary staff frequently bypass it entirely.
• Identity provider or SSO handles authentication, but doesn't reliably track local accounts inside SaaS apps or legacy systems.
• SaaS applications often maintain their own independent user directories, Slack, Salesforce, Jira, each capable of holding users who were never synced with the central identity provider. This is frequently where the fragmentation actually starts, and it traces back to the same ungoverned SaaS adoption that drives most other sprawl types too.
• Cloud IAM and service accounts hold roles, permissions, and automated identities for CI/CD pipelines, APIs, and bots, frequently ungoverned by anything resembling a formal process.

Because identity is fragmented this way, visibility can't help but break down. Every system believes it's authoritative, but none of them sees the full lifecycle. An account created in one system may never get removed in another. Temporary or project-based access in one environment lingers well past its intended expiration, because nothing outside that specific system is tracking it.

The result: orphaned identities, duplicate accounts, and hidden privileges, not as mistakes anyone made, but as the natural byproduct of a fragmented, additive system. These hidden identities inflate risk silently. They don't trigger alerts and don't show up in audit dashboards, until an auditor or a security incident forces a review, at which point they're suddenly high-risk gaps that should have been caught months earlier.

An organization can't govern what no system fully sees. Fragmentation is what hides sprawl in plain sight, turning every scattered identity into a potential blind spot.

Non-Human Identities: The Sprawl IT Rarely Tracks

When identity sprawl comes up, it's easy to picture employees and contractors first. But the fastest-growing source of unmanaged identity today is non-human: accounts, tokens, and roles created for systems, automation, and integrations, largely invisible to IT by default.

Service accounts get created for automation, batch jobs, or admin tasks, frequently with nobody clearly accountable for them once the immediate need is solved. CI/CD pipeline identities multiply because every build, deployment, or script may require its own dedicated identity with elevated permissions. OAuth apps and API tokens generated by integrated apps, bots, and external services rarely have any expiration built in at all.

These identities escape control for reasons specific to how they're created:

• They aren't tied to HR events. When someone leaves, the service accounts and tokens they set up often stay active with no trigger prompting anyone to check.
• Expiration policies are rare. Once created, these identities persist until someone manually discovers and revokes them, which frequently never happens.
• Ownership is team-based, not system-based. IT doesn't automatically see or manage them at all.
• Permissions get over-provisioned for reliability. Engineers routinely grant broad roles specifically to avoid breaking automated processes later.

Most access reviews focus almost entirely on human users, which leaves exactly the population carrying the highest risk unexamined. Ignoring non-human identities doesn't make them safer. It just means the sprawl compounds silently until it eventually triggers an incident or an audit finding.

Additive Access Models Make Sprawl Permanent

Modern access is designed to be easy to grant and hard to remove. That isn't an accident, it's a deliberate trade-off organizations make in favor of speed and reliability over strict revocation, and the direct result is a one-way ratchet of permissions. Once access is granted, it rarely disappears on its own.

Access accumulates through a few consistent patterns:

• Promotions add new roles without removing old ones. An engineer who moves from junior to senior gains new access while legacy privileges from the earlier role often persist untouched, unused but still active years later.
• Project access lingers indefinitely because there's no automated trigger to revoke it once the project ends.
• Temporary access quietly becomes default access. Contractors and consultants often retain elevated privileges long after their engagement ends, simply because removing access is treated as risky or not worth the effort.

Revocation rarely happens by design, not indifference:

• Teams worry that revoking a permission might break a workflow or disrupt a critical process.
• Granting access is a single click, while removing it usually requires coordination across teams and approvals, so it gets postponed indefinitely.
• There's frequently no clear owner for the removal decision at all. IT, the manager, and the business owner all quietly assume someone else will handle it.

The result is identity as a permission ratchet that only moves in one direction. Access accumulates and rarely decreases, and every new hire, project, or integration adds one more layer to the pile. Without structural changes, automated lifecycle enforcement, clear ownership for revocation, and continuous visibility, permissions will always outpace any organization's ability to control them. This accumulation pattern is its own distinct problem worth understanding on its own terms, covered in depth in access sprawl.

Access Reviews Stabilize Sprawl Instead of Reducing It

Access reviews are supposed to control sprawl: catch orphaned accounts, reduce unnecessary permissions, enforce least privilege. In practice, they frequently freeze sprawl in place rather than reducing it.

The pattern shows up consistently in how reviewers actually behave:

• They approve what they don't fully understand. A manager asked to review 47 AWS users, faced with roles like IAM:PassRole or EC2:FullAccess with no real sense of what each one means, finds it easier and safer to approve everything than risk breaking production over something they don't fully understand.
• They favor continuity over correctness. Revoking someone's access might disrupt a project or trigger an escalation, so the path of least resistance is simply to approve.
• They normalize whatever got approved last time. Once excess privileges get approved once, they become the new normal, since future reviewers treat previously approved access as legitimate by default and continue the same cycle.

The unintended result is that sprawl becomes sanctioned. Access that should have stayed temporary becomes permanent, and unknown, orphaned, or redundant access gets legitimized simply by surviving a quarterly review process that was never actually equipped to catch it. Traditional access reviews don't shrink identity sprawl. Without better context, continuous visibility, and automated remediation behind them, they cement it, creating the appearance of governance while excess access keeps quietly accumulating underneath.

The Day-to-Day Cost of Identity Sprawl for IT Teams

Identity sprawl isn't just a theoretical security risk. It drains real time, energy, and resources from IT teams on an ongoing basis. Every unmanaged account, every orphaned service identity, every lingering temporary permission adds friction to daily operations.

Incident response slows down. Tracing the access lineage of a user or service account during a security incident can take hours or days when identity is scattered across dozens of fragmented systems, time spent investigating who had access rather than actually mitigating the threat.

Audit prep becomes a manual scramble. Quarterly access reviews generate evidence scattered across spreadsheets, emails, and chat threads, and IT ends up spending entire weeks compiling it just to satisfy auditors, reconciling dozens of SaaS applications by hand for a single report.

Cleanup backlogs only grow. Temporary access granted months ago is often still active. Contractors who left weeks ago still hold privileges. Each review cycle adds new remediation work on top of whatever didn't get finished from the last one, and the backlog grows faster than anyone can work through it.

Licenses tied to inactive identities quietly cost real money. Every unused account still consumes a license somewhere. In a typical 500-employee company, a meaningful share of SaaS licenses, commonly in the range of 10 to 15 percent, are tied to inactive or orphaned accounts nobody's actively using.

Why Identity Sprawl Breaks Zero Trust Before Security Even Starts

Zero Trust assumes an organization knows every identity, understands its access, and can revoke privileges instantly. Its core promises, continuous verification, least-privilege enforcement, dynamic access decisions, depend entirely on identity data that's accurate, complete, and current. Identity sprawl undermines all of that before a single policy ever gets enforced.

Sprawl breaks Zero Trust in three specific ways:

• Identity certainty. Fragmented, orphaned, or unmanaged accounts make it genuinely impossible to answer basic questions like who has access to what, or which accounts are even still active. Zero Trust controls require reliable data to function, and sprawl guarantees exactly the gaps that make that data unreliable.
• Least-privilege enforcement. Sprawl favors additive access by nature: temporary permissions linger, service accounts accumulate privileges, project roles persist indefinitely. Zero Trust policies can't enforce a minimal baseline when the actual baseline is already inflated well past it.
• Real-time access decisions. Dynamic policies assume access can be evaluated and revoked on demand. If identities aren't being continuously monitored, revocation lags behind reality, and risk gets baked in long before any enforcement mechanism has a chance to act on it.

Think of Zero Trust as a fence around a garden, and sprawl as the network of weeds already growing underneath the soil. The fence might catch some intruders at the perimeter, but the weeds keep spreading regardless, because the actual problem was never at the fence line. Zero Trust cannot compensate for identity chaos. The model assumes the organization already has visibility, ownership, and control over every identity. Without addressing sprawl first, enforcement ends up reactive, incomplete, and in some cases close to meaningless.

Containing Identity Sprawl Requires Systemic Change

Identity sprawl isn't a glitch that gets patched. It's a direct byproduct of modern IT: additive access, distributed systems, and event-driven account creation working together. Treating it like a project to clean up once a quarter doesn't work. Containing it actually requires changing how identities get managed, monitored, and enforced.

What genuinely helps:

Continuous identity inventory. Real-time visibility into every identity, human and non-human, across every connected system. Not a spreadsheet and not a quarterly report, an automated, always-on inventory tracking creation, modification, and deactivation as it happens.

Lifecycle-driven access enforcement. Access tied directly to events, onboarding, role changes, project completion, offboarding, rather than a fixed calendar, so permissions automatically expire or get reviewed the moment the context that justified them actually changes.

Clear ownership for every access decision. Every account and role needs someone accountable for reviewing and revoking it. Without a defined owner, the decision simply gets deferred indefinitely, which is functionally the same as never making it.

Event-based governance instead of calendar-based cleanup. Waiting for the next quarterly review creates a window where sprawl grows completely unchecked. Governance triggered by the actual event, a hire, a transfer, a project ending, corrects access close to real time instead of months later.

What doesn't help nearly as much:

• More policies without operational enforcement behind them, which mostly just adds paperwork on top of sprawl that's still there
• Bigger review spreadsheets, which amplify manual burden and human error rather than reducing excess access
• Annual or quarterly campaigns generally, which are reactive by design and, by definition, always behind the pace at which new identity actually gets created

Sprawl behaves like a river that naturally overflows its banks. Policies and spreadsheets are sandbags: they might slow the water down temporarily, but they don't stop it. What actually works is re-engineering the channel itself, continuous monitoring, lifecycle management, and clear ownership, so growth gets contained before it turns into a flood. Containment beats cleanup. Sprawl isn't eliminated through effort. It's managed through systems, processes, and accountability that run continuously rather than episodically.

Identity Sprawl Is Inevitable. Losing Control Over It Isn't.

Identity sprawl isn't a failure on IT's part. It's a natural outcome of modern, distributed, fast-moving environments. Every new hire, every cloud integration, every service account creates a new identity. Every temporary access request, every project role, every automation token adds another layer to a growing web of accounts.

The question was never whether sprawl would happen. It will, reliably, in any organization operating at modern pace. The real question is whether it can actually be contained.

Sprawl is the direct cost of growth: additive access, event-driven identity creation, and distributed systems together guarantee that accounts accumulate faster than traditional, calendar-based governance can remove them.

Control comes from visibility, ownership, and automation working together, continuous identity inventory, lifecycle-driven enforcement, clear accountability, and event-based governance, which is what turns sprawl from an invisible, compounding threat into a manageable operational reality. And perfection was never the bar. Eliminating every orphaned service account or revoking every temporary token immediately isn't the goal. Continuous correction, addressing sprawl proactively and systematically before it accumulates, is.

How Zluri Fits Into This

Zluri's discovery model pulls identity signals from eight distinct sources rather than depending on any single system's incomplete record, which is what closes the specific fragmentation gap this piece covers: an identity created outside HR's normal flow, or a service account nobody logged anywhere formal, gets surfaced regardless of which channel first reveals it.

User Merge runs continuously rather than as a one-time cleanup, consolidating the same person's fragmented, duplicate records the moment they're detected, instead of waiting for the next scheduled audit to catch them.

Account Type classification separates employee, external, and service identities into real, trackable categories, and Service Account Exposure specifically flags accounts with no clear individual owner, exactly the population this piece identifies as growing fastest and getting tracked least. Orphaned Access and Dormant Account detection catch identities still technically active with no ongoing justification, closing the gap that additive, rarely-revoked access creates by default.

None of this replaces the systemic changes this piece argues for, event-based governance, clear ownership, continuous inventory. It's the operational mechanism that makes those changes actually executable, rather than a policy that exists on paper while sprawl keeps accumulating underneath it. For the fragmentation-specific side of this problem, see how Zluri contains it. For how this connects to access, group, and SaaS sprawl more broadly, see saas chaos is patient zero for every type of sprawl you have.

Frequently Asked Questions

Is identity sprawl caused by poor governance, or is it inherent to how modern IT operates?

Inherent, primarily. Modern identity creation is event-driven and happens across dozens of distributed systems, while governance runs on fixed schedules like quarterly reviews. That mismatch in pace guarantees a lag where access accumulates faster than anyone questions or removes it, regardless of how well-intentioned the governance process is.

Why do quarterly access reviews often fail to reduce identity sprawl?

Because reviewers frequently approve access they don't fully understand rather than risk disrupting production, and once excess access gets approved once, it becomes the accepted baseline for future reviews. The review process ends up legitimizing sprawl rather than reducing it, creating an appearance of governance without the actual reduction.

Why are non-human identities considered higher risk than human accounts?

Because they aren't tied to HR events that would normally trigger review, rarely have expiration policies, are typically owned by teams rather than tracked centrally by IT, and are often granted broad permissions specifically to avoid breaking automated processes. That combination means they accumulate fastest and get caught slowest.

How does identity sprawl affect a Zero Trust security model specifically?

Zero Trust depends on accurate, complete, and current identity data to enforce continuous verification and least-privilege access. Identity sprawl breaks all three prerequisites at once: fragmented accounts make basic access questions unanswerable, additive permissions inflate the baseline Zero Trust is supposed to minimize, and monitoring gaps mean revocation lags behind actual risk.

What actually reduces identity sprawl if periodic cleanup projects don't work?

Systemic change rather than periodic effort: continuous, always-on identity inventory across every system, access enforcement tied to real lifecycle events rather than a calendar, clear ownership for every access decision, and governance triggered by the event itself rather than the next scheduled review. Cleanup projects produce a clean baseline that starts drifting again immediately. Continuous systems don't.

‍