Introduction

The perimeter is gone. Everyone knows this. What has not been fully internalized is what replaced it. The answer is identity. Every access decision in a modern enterprise, whether a user logging into a SaaS application, a service account calling an API, a Lambda function accessing an S3 bucket, or a CI/CD pipeline pushing a container image, is mediated by an identity. That identity is the perimeter now.

The problem is that identity in 2026 is not a single system. It is a sprawling, fragmented, inconsistently governed collection of identity providers, role definitions, permission policies, API keys, service accounts, OAuth tokens, and federated trust relationships spread across multiple cloud providers, dozens of SaaS platforms, and legacy on-premises systems. No single team owns it. No single tool sees all of it. No single policy governs it.

This report examines how multi-cloud identity sprawl creates exploitable blind spots, how attackers leverage the gaps between identity systems, and what organizations need to do to regain control of the identity layer before the attacker does it for them.

The Anatomy of Identity Sprawl

A mid-size enterprise in 2026 typically operates identity across at least the following systems: an on-premises Active Directory domain (often multiple forests from acquisitions), Azure Entra ID (formerly Azure AD) for Microsoft 365 and Azure workloads, AWS IAM for Amazon cloud workloads, GCP IAM if Google Cloud is in the mix, Okta or Ping Identity as a centralized SSO provider, and between 40 and 200 SaaS applications that each maintain their own user directories, role models, and API credential stores.

Each of these systems defines identity, authentication, and authorization differently. AWS IAM uses policies attached to users, groups, and roles with a JSON policy language. Azure uses role-based access control (RBAC) with role assignments scoped to management groups, subscriptions, resource groups, or individual resources. GCP uses a combination of IAM roles and organization policies. SaaS applications define their own permission models with no standardization across vendors.

The result is that a single human user may have five or more distinct identity representations across the enterprise, each with its own credentials, permissions, and governance model. A single service or application may have even more. The organizational challenge is that no one has a unified view of what any given identity can actually access across all of these systems.

The Federated Trust Problem

Federation was supposed to solve this. SAML and OIDC allow organizations to centralize authentication in an identity provider (Okta, Entra ID, Ping) and extend trust to downstream applications. The user authenticates once, and the identity provider issues assertions that downstream services honor.

In practice, federation creates a new class of risk: the identity provider becomes a single point of catastrophic failure. Compromise the IdP, and the attacker inherits trust to everything federated through it. The Okta breaches of 2022 and 2023 demonstrated this at scale. When the IdP was compromised, every federated application trusted the attacker's forged assertions.

Federation also creates trust relationships that are difficult to audit. When Organization A federates with Organization B's IdP for a partner portal, Organization A is trusting Organization B's identity governance, authentication strength, and incident detection capabilities. If Organization B is compromised, Organization A's partner portal is accessible to the attacker, and Organization A may not know about the compromise until long after the attacker has used the access.

Service Account Proliferation

Human identities are only part of the sprawl. Machine identities, including service accounts, API keys, OAuth client credentials, managed identities, and workload identity federation tokens, now outnumber human identities by a factor of 10 to 45 in most enterprise environments. These identities are created by developers, DevOps teams, and automation platforms, often without centralized governance.

Service accounts in AWS IAM are routinely created with AdministratorAccess policies because the developer needed broad permissions during development and never scoped them down for production. API keys for SaaS integrations are generated, embedded in configuration files, committed to Git repositories, and forgotten. OAuth tokens for inter-service communication are granted with scopes far broader than the integration requires because the documentation was unclear and "it works with full scope" was the path of least resistance.

The lifecycle management problem is acute. When a human employee leaves, their Active Directory account is disabled and their SSO sessions are revoked. But the service accounts they created, the API keys they generated, the OAuth integrations they configured, and the IAM roles they defined often persist indefinitely. No one knows who created them, what they are used for, or whether they are still needed. Disabling them risks breaking production systems. So they persist, with their permissions intact, as orphaned credentials waiting to be discovered by an attacker.

How Attackers Exploit Identity Sprawl

Identity sprawl is not just an operational inconvenience. It is an attack surface. Adversaries have adapted their techniques to target the gaps between identity systems, and their approaches are increasingly sophisticated.

Credential Stuffing Across Identity Boundaries

When a user reuses their corporate password on a SaaS application that is not federated through the corporate IdP, a credential compromise on one system propagates to the other. Attackers harvest credentials from data breaches, test them against corporate VPNs and SSO portals, and use valid credentials to bypass authentication entirely. MFA mitigates this for interactive logins, but many SaaS applications support API access with username/password or API keys that are not protected by MFA.

OAuth Token Abuse

OAuth consent phishing has emerged as one of the most effective techniques for gaining persistent access to cloud environments. The attacker registers a malicious OAuth application with a name like "Security Audit Tool" or "IT Compliance Scanner," then sends the target a legitimate OAuth consent URL. When the user grants consent, the attacker's application receives an OAuth token with whatever scopes the user approved. This token persists independently of the user's password and MFA, and it is not invalidated by password resets.

The Midnight Blizzard (APT29) campaign against Microsoft in early 2024 used OAuth application abuse to maintain persistent access to Microsoft's own email systems for months. The technique works because OAuth consent is a legitimate platform feature, the tokens are issued by the trusted identity provider, and most organizations do not monitor which OAuth applications their users have authorized or what scopes those applications hold.

Cross-Cloud Privilege Escalation

In multi-cloud environments, the boundaries between cloud providers create seams that attackers can exploit for privilege escalation. A common pattern: an attacker compromises a low-privilege AWS IAM role that has access to an S3 bucket containing Terraform state files. Those state files contain Azure service principal credentials that were embedded during infrastructure deployment. The Azure service principal has Contributor access to a subscription that contains a Kubernetes cluster. The Kubernetes cluster uses workload identity federation with GCP, granting access to a BigQuery dataset containing customer PII.

No single cloud provider's IAM system sees this full chain. AWS IAM sees a role accessing an S3 bucket. Azure sees a service principal accessing a subscription. GCP sees a workload identity accessing BigQuery. Each step looks normal within its own context. The cross-cloud privilege escalation is invisible to any single provider's detection and logging.

Targeting the IdP Directly

Sophisticated adversaries increasingly target the identity provider itself. The Okta breaches demonstrated the value. The SolarWinds attack included Golden SAML forgery against ADFS, allowing the attacker to forge authentication assertions for any user to any federated service. The attack on Microsoft by Midnight Blizzard targeted the OAuth infrastructure that mediates trust across the Microsoft ecosystem.

When the IdP is compromised, the blast radius is total. Every federated application, every SSO session, every SAML assertion, and every OIDC token issued by the compromised IdP is suspect. The attacker can impersonate any user, access any federated service, and do so with tokens that look legitimate to every downstream system. Detection requires the downstream services to independently verify trust, which most do not do because the entire point of federation is to outsource that verification to the IdP.

The Visibility Gap

The most damaging aspect of identity sprawl is not the sprawl itself. It is the visibility gap. Most organizations cannot answer basic questions about their identity posture.

How many identities exist across all systems? Most cannot produce a count that includes service accounts, API keys, and SaaS-local accounts in addition to Active Directory and IdP users.

Which identities have excessive permissions? In AWS alone, Wiz and Ermetic research has shown that over 90% of cloud identities use less than 5% of their granted permissions. The other 95% is unnecessary attack surface.

Which credentials are stale? API keys that have not been used in 90 days, service accounts whose last authentication was six months ago, OAuth tokens that were granted and never revoked. These are the credentials attackers find first because they can be used without displacing a legitimate user's session.

What are the cross-cloud trust relationships? Which AWS roles can assume Azure identities? Which GCP service accounts have access to resources in other clouds? Which SaaS applications have been granted access to cloud storage or email via OAuth? These questions require visibility across every identity system simultaneously, which no single tool provides natively.

Recommendations

Establish a unified identity inventory across all clouds and SaaS platforms. This is the foundational step. You cannot govern what you cannot see. Use tools like CIEM (Cloud Infrastructure Entitlement Management) platforms from Wiz, Ermetic (now Tenable), CrowdStrike, or similar to build a cross-cloud view of all human and machine identities, their effective permissions, and their usage patterns. Supplement with SaaS security posture management (SSPM) tools for SaaS application identity visibility.

Implement least privilege as a continuous process, not a one-time project. Right-size permissions based on actual usage. If an IAM role has 47 permissions but uses 3, reduce it to the 3 it needs. Apply this continuously. Permissions drift over time as new features are added and old integrations are left in place. Automated permission right-sizing tools can baseline usage and recommend reductions without requiring manual analysis of every policy.

Eliminate long-lived credentials wherever possible. Replace static API keys with short-lived tokens issued via OIDC workload identity federation. Replace service account passwords with managed identities (Azure) or IAM roles with temporary credentials (AWS STS). Every static credential is a time bomb. The shorter the credential lifetime, the smaller the window of exploitation if it is compromised.

Monitor OAuth consent grants and third-party application access continuously. Maintain an inventory of every OAuth application your users have authorized, what scopes each application holds, and when each authorization was granted. Revoke access for applications that are no longer needed. Alert on new OAuth consent grants for applications that have not been pre-approved by your security team. This is the primary defense against OAuth consent phishing campaigns.

Harden the identity provider as critical infrastructure. The IdP is the highest-value target in a federated identity architecture. Apply the same rigor to IdP security that you apply to domain controllers: phishing-resistant MFA for all IdP administrators, privileged access workstations for IdP management, continuous monitoring of IdP configuration changes, and incident response procedures specifically for IdP compromise scenarios. If your IdP is compromised, everything downstream is compromised. Protect it accordingly.

Conduct identity-focused penetration testing. Traditional penetration tests focus on network and application vulnerabilities. Identity-focused testing specifically targets the gaps between identity systems: credential reuse across boundaries, OAuth token abuse, cross-cloud privilege escalation paths, federation trust exploitation, and service account compromise. If your pen test scope does not include identity, it is missing the most commonly exploited attack surface in cloud environments.

Key Takeaway

  • Multi-cloud identity sprawl is not a future risk. It is the present reality for every organization that uses more than one cloud provider or more than a handful of SaaS applications. The identity layer is the most fragmented, least visible, and most exploited surface in the modern enterprise. Attackers have adapted. They do not need to find a vulnerability in your application. They need to find one credential, one over-permissioned role, one stale API key, or one OAuth consent grant that gives them the access they need. Regaining control of the identity layer is not a security project. It is the security project.