Mid-Market Identity Sprawl: What Three Common AD-Plus-Cloud Setups Reveal About Real Attack Surfaces

6 min read

In mid-sized companies, identity sprawl is the norm—not the exception. Lay three typical setups side by side—Active Directory with Entra ID sync and parallel SaaS, hybrid hyperscaler roles, a fragmented IdP landscape with legacy systems—and you’ll quickly spot where documentation and actual permissions diverge. Attackers see the same gaps, only sooner.

Key takeaways

Identity sprawl stems from legacy Active Directory setups, uncoordinated SaaS adoption, and incomplete hyperscaler role assignments.
In mid-sized companies, documented permissions rarely match real-world access rights.
Kerberoasting, Pass-the-Hash, and Golden Ticket attacks exploit these exact gaps.
The critical metric isn’t the number of accounts, but the delta between intended and actual access.
Centralized IAM with strict lifecycle management measurably reduces the attack surface.

The assumption that identities are centrally managed rarely holds up under scrutiny. Employee departures, project shifts, SaaS trials, service accounts for abandoned integrations—each routine leaves artifacts across identity systems. The sum of these artifacts defines the real attack surface, not the org chart.

Three anonymized setups from typical mid-sized environments reveal the pattern. All are generic templates, not outliers. If any look familiar, it’s time to audit your own checks—before someone else does. Status as of April 2026.

What is identity sprawl?

Identity sprawl describes a state where user and service identities grow across multiple disconnected systems without a unified lifecycle process to maintain consistency. Each system—Active Directory, Entra ID, individual SaaS tools, cloud IAM—manages a subset. Few, if any, have full visibility of the entire landscape.

Setup 1: Active Directory, Entra ID Sync, and Unmanaged SaaS

The most common pattern in mid-sized companies: a local Active Directory as the primary system, Entra ID (formerly Azure AD) synced via Entra Connect, and Microsoft 365 as the productivity backbone. Alongside this, a SaaS landscape grows—one that no one has fully inventoried.

Documentation states: AD is the source. Offboarding disables the AD account, sync removes the Entra user, and Microsoft 365 access is revoked. In reality, parallel SaaS tools exist with local users, tools with Google logins for the marketing team, a CRM with its own password login—still active three years after testing. Offboarding never reaches these systems.

3 out of 4

Mid-sized companies don’t know all the SaaS services their employees actively use (Shadow IT).

Source: Bitkom, Digitalization in Mid-Sized Companies, 2024

Then there’s a technical detail AD admins know well: accounts with Service Principal Names (SPNs) are prime Kerberoasting targets. In practice, service accounts from legacy ERP integrations or monitoring systems often carry SPNs—and weak passwords from a time when the domain was smaller. Any authenticated domain user can request service tickets and crack them offline.

The mismatch in Setup 1 lies between AD’s clean on/off logic and the SaaS tools that don’t play by those rules. Hardening AD alone only secures half the system.

A pragmatic audit in a typical environment of this size regularly uncovers between eight and twenty SaaS tools that aren’t part of the official portfolio. Marketing automation, design suites, project management tools, time-tracking systems for individual locations—each with its own admin, password policies, and no connection to the AD lifecycle. When employees leave, licenses stay active. When tools are replaced, old data remains accessible.

Setup 2: Active Directory with Hybrid Hyperscaler Roles

More ambitious mid-sized companies also run workloads in AWS or Azure. Developers get roles, DevOps teams automate deployments, and service accounts interact with cloud resources via access keys or managed identities.

Documentation claims: Cloud access runs through Entra ID or AWS SSO, with roles scoped minimally. In reality, engineers retain temporary roles meant for a 2024 migration sprint. An access key has sat in a build server script for two years. A cross-account role created for a former contractor was never removed.

The critical weak point is the transition layer. If an AD account can assume an Azure role via Entra ID—and that role has access to KeyVaults or storage accounts—it creates a pathway rarely fully mapped. Pass-the-hash or token theft on a local machine opens doors in this setup that extend far beyond the traditional AD perimeter.

Another cloud-specific quirk often overlooked in AD audits: permissions are role-based but tied to workloads that have their own identities. A virtual machine with a managed identity, a pipeline with OIDC tokens, a function with a system-assigned identity—these aren’t users in the traditional sense, but they still have access rights. Fail to inventory these workload identities, and you miss an entire class of potential attack surfaces. Compliance audits against ISO 27001 or NIS2’s access control requirements rarely address this layer explicitly.

Setup 3: Fragmented, Multiple IdPs, Legacy Service Accounts

This third pattern often emerges after acquisitions, reorganisations, or organic vendor sprawl. A local AD for the core organisation, a second AD from an acquired subsidiary, a separate IdP for production, plus Okta or Google Workspace for one business unit.

Documentation typically labels this setup as “temporary.” Reality stays this way for years. Trusts between AD domains were set up once and never revisited. Service accounts exist in both directories, with overlapping permissions and often identical passwords. Privileged groups like “Domain Admins” contain accounts whose original purpose no one can reconstruct any more.

Centralised IAM vs. Fragmented Status Quo

Dimension	Centralised IAM	Fragmented Status Quo
Offboarding	Single process, cascaded to all systems	Manual per system, patchy
Visibility	One console for all identities	Multiple admin portals, no reconciliation
Audit	Consolidated log, comparable events	Log fragments in every system
Setup effort	High, requires process and tool discipline	Low, arises from indecision
Attack surface	Clearly defined, can be hardened selectively	Unwieldy, recurring legacy issues

The biggest risk factor in Setup 3 is not fragmentation itself, but the assumption that it is temporary. As long as no lifecycle process reduces the legacy load, the number of orphaned service accounts grows year after year.

Centralised IAM – Pros

Consolidated view of all identities
Offboarding cascades to every system
Audit trails are fully traceable
Privileged access can be hardened selectively

Fragmented Status Quo – Pros

Low initial setup hurdle
Teams can work autonomously
Local tool changes possible
No central dependency

Centralised IAM – Cons

High initial implementation effort
Requires cross-departmental process discipline
Single point of failure if the system goes down
Licensing costs for IAM platforms

Fragmented Status Quo – Cons

Growing number of orphaned accounts
No consolidated audit view
Offboarding gaps with every staff change
Attack surface scales over time

What attackers routinely find

The techniques used to exploit these vulnerabilities are well-documented and have remained stable for years. Kerberoasting against service accounts with weak passwords. Pass-the-Hash via locally cached credentials. Golden Ticket attacks once an attacker gains access to the krbtgt account. None of these require zero-days—just a domain where lifecycle discipline has eroded over time.

A typical attack path can be reconstructed. It starts inconspicuously and ends with access to systems that were never in the initial scope.

Typical attack path in identity sprawl environments

T0 – Initial access: A phishing email or a compromised session on a laptop. The attacker is now inside the environment as a regular domain user.

T+1 day – Enumeration: Listing domains, groups, and Service Principal Names. Tools like BloodHound or similar techniques map out paths to privileged accounts.

T+2 days – Kerberoasting: Requesting service tickets for SPN-enabled accounts and performing offline brute-force attacks against weak passwords. Several service accounts are compromised.

T+3 days – Lateral movement: A compromised service account provides access to a jump host. Pass-the-Hash or cached tokens extend the attacker’s reach.

T+5 days – Cloud pivot: An account with hybrid roles enables a leap into the cloud environment. Access keys in scripts or forgotten roles accelerate progress.

T+7 days – Objective reached: Access to file storage, databases, or backup systems. From the attacker’s perspective, the environment is now fully mapped.

The timeline is generic but realistically scaled. Anyone who fails to detect the T+3 stage will likely only notice the T+7 stage after data has already been exfiltrated.

In practical terms, the situation can be summarized like this: The attack surface in typical mid-sized environments isn’t Active Directory alone, but the sum of AD, synchronized cloud identities, unmanaged SaaS applications, and legacy service accounts. If you don’t inventory each of these layers, you’re not securing your actual environment—you’re just updating documentation.

Concretely, this means for day-to-day operations: A complete inventory across all identity sources is the prerequisite for any further action. For each source, maintain three columns: Account, last login, owner. If you can’t fill in the second column, you don’t have control over the first. If you can’t name the third, you have no point of contact for offboarding. The greatest leverage lies precisely in this simplicity—and also the point at which most projects fail, due to a lack of permanently assigned responsibility.

The second layer is hardening already inventoried accounts. Service accounts with SPNs: passwords of sufficient length and complexity, rotated at documented intervals. Privileged groups: regular access reviews, Tiered Admin models where feasible. krbtgt account: dual reset every six months. Local administrator passwords: LAPS or equivalent solutions. None of these measures are new; all are well-documented, yet many fail during daily operations.

Order matters: Inventory comes before hardening. Hardening an account that should no longer be in use is wasted effort. Hardening an account whose existence is unknown won’t happen at all. Both scenarios are more common in mid-sized companies than the assumption of a clean account landscape would suggest. An honest assessment typically yields more insights than deploying a new tool.

The third layer involves cloud transitions. Conditional Access in Entra ID, Privileged Identity Management for temporary roles, no permanent cross-account access in AWS, workload identities instead of long-lived access keys. Again, the concepts are documented—the implementation requires sustained attention over multiple quarters.

The pragmatic takeaway isn’t launching a major IAM project at year-end. It’s a simple inventory: Which identities exist, who created them, who last used them, and what permissions do they currently hold? When honestly maintained, this list determines the gap between target and actual state—and thus defines the real attack surface.

Frequently Asked Questions

What exactly is Identity Sprawl?

Identity Sprawl refers to the uncontrolled proliferation of user and service identities across multiple systems without a central lifecycle process to maintain consistency. Typical drivers include unchecked SaaS adoption, legacy Active Directory structures, and parallel hyperscaler roles. The term is used in both BSI-aligned publications and international IAM discussions.

How does Identity Sprawl differ from Privilege Creep?

Privilege Creep describes the gradual accumulation of permissions per account over time. Identity Sprawl takes it a step further: it’s the growth in the number of identities and the systems where they exist. In practice, both phenomena often occur together and reinforce each other.

Why isn’t a central AD enough?

An Active Directory governs what’s documented and integrated. But SaaS tools with local logins, cloud roles without full Entra integration, and legacy systems from acquisitions often fall outside its control. The real permissions landscape is far larger than what’s visible in AD.

What’s the quickest way to reduce the attack surface?

Start with a thorough inventory of all service accounts, followed by password rotation and the removal of unnecessary accounts. At the same time, review the “Domain Admins” group and other highly privileged groups. Both steps can be done without tool investments and target the most common real-world attack paths.

How relevant are Kerberoasting or Pass-the-Hash today?

Both techniques have been well-documented for years and remain standard in penetration testing. They don’t work because they’re new—they work because the underlying AD vulnerabilities persist in many environments.

Editor’s Picks