Multi-cloud identity governance is breaking under cloud sprawl

At a glance

What this is: This is an analysis of why multi-cloud identity governance breaks down as organisations spread access controls across AWS, Azure, and GCP.

Why it matters: It matters because IAM teams have to govern human users, privileged cloud roles, and machine identities consistently even when each cloud provider models access differently.

Context

Multi-cloud identity governance is the control layer that keeps access, entitlements, and audit evidence consistent across cloud providers. The problem is not cloud adoption itself, but the fact that each platform defines roles, bindings, service accounts, and inheritance differently, which makes central oversight harder as environments scale.

The article’s core governance gap is fragmentation: security teams can no longer rely on a single IAM model to describe who or what has access across AWS, Azure, and GCP. That affects human IAM, NHI governance, and cloud compliance at the same time, because privilege review and lifecycle control have to work across all three without losing policy consistency.

Key questions

Q: What breaks when cloud identities are not centrally governed?

A: Shadow accounts, orphaned credentials and inconsistent role definitions emerge because no single process can see the whole access picture. That breaks least privilege, complicates incident response and makes compliance evidence harder to prove, especially when workforce and service identities are managed separately.

Q: Why do excessive permissions become more likely in multi-cloud environments?

A: Because teams often use broad roles for speed, then leave those permissions in place as workloads, projects, and providers multiply. Different cloud models make cleanup harder, so temporary access becomes durable access. That increases the chance of unauthorized access and lateral movement if one identity is compromised.

Q: How do security teams know whether cloud access policy is actually working?

A: They should test whether policy decisions are traceable from discovery to approval to revocation. If a team can see apps but cannot prove who owns the integration, what data it can touch, and how it is removed, then the policy is only partially working. Effective governance produces evidence, not just alerts.

Q: What should IAM teams do when service accounts have no clear owner?

A: Treat that as a governance defect, not an administrative nuisance. Unknown ownership means the account cannot be reviewed, rotated, or offboarded with confidence, which leaves residual access in place. Teams should require ownership assignment before the identity is allowed to retain privilege in production.

Technical breakdown

Why multi-cloud entitlement models create governance drift

AWS, Azure, and GCP do not express privilege in the same way. AWS leans on IAM policies and roles, Azure on role assignments and managed identities, and GCP on IAM bindings and service accounts. When those models are managed separately, entitlement logic drifts across platforms, so a permission that looks temporary in one cloud can become persistent in another. The technical problem is not just scale, but semantic mismatch: teams are trying to compare unlike structures with different inheritance paths, admin scopes, and default trust relationships.

Practical implication: Treat entitlement governance as a cross-cloud translation problem, not a per-platform admin task.

How orphaned cloud identities and service accounts accumulate

Orphaned identities appear when lifecycle events are not tied to offboarding, project closure, automation changes, or workload decommissioning. In multi-cloud estates, that includes service accounts, automation identities, and privileged workload accounts that stay active after the business need is gone. Because machine identities often support CI/CD, APIs, and cloud-native workloads, they are easy to overlook and hard to inventory without ownership and activity data. The result is residual access that survives long after the original requestor, project, or application has moved on.

Practical implication: Tie cloud identity lifecycle controls to authoritative ownership and deprovisioning triggers.

Why access reviews fail without centralized audit evidence

Access reviews only work when reviewers can see the full entitlement graph, including inherited permissions, privileged roles, third-party access, and non-human identities. In a fragmented multi-cloud model, evidence is scattered across account consoles, native logs, and platform-specific role structures, so certifications become partial and inconsistent. That weakens least privilege because reviewers cannot reliably tell which permissions are still required. It also creates audit risk, since the organisation may have controls in place on paper without being able to prove them coherently across providers.

Practical implication: Build access certification around unified evidence, not separate cloud-native review cycles.

Threat narrative

Attacker objective: The likely objective is to exploit governance fragmentation to gain broader cloud access than intended and move through cloud environments with less resistance.

1. Entry occurs through routine cloud expansion, where teams distribute workloads across AWS, Azure, and GCP faster than governance can unify their access models.
2. Privilege escalation follows when broad IAM roles, unmanaged service accounts, and inherited entitlements accumulate beyond the original business need.
3. Impact arrives as excessive permissions, orphaned identities, and fragmented audit evidence that weaken least privilege and increase the chance of unauthorized access.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-cloud identity governance fails when platform-specific IAM models are treated as if they were interchangeable. AWS, Azure, and GCP each express privilege through different structures, inheritance rules, and admin boundaries. That means central visibility has to normalize meaning, not just aggregate logs. The implication is that governance programmes need a cross-cloud entitlement model, not a patchwork of native console reviews.

Orphaned identities are not an edge case in multi-cloud environments; they are a lifecycle failure mode. The article correctly points to employee departures, contractor offboarding, automation changes, and resource decommissioning as common sources of residual access. Once service accounts and workload identities outlive their business owner, accountability breaks. Practitioners should treat ownership and offboarding as the primary control plane for cloud identity hygiene.

Overprivilege is the dominant cloud identity risk because convenience-driven role assignment becomes durable policy. In practice, teams grant broad permissions to keep delivery moving, then rely on informal cleanup that never fully happens. That produces permission creep, cross-account trust sprawl, and inherited access paths that are difficult to unwind. The security lesson is that least privilege in multi-cloud is a governance state, not a one-time provisioning choice.

Centralized audit evidence is now part of access control, not just compliance reporting. If certifications, provisioning records, and policy violations live in separate provider silos, the organisation cannot prove continuous governance across its cloud estate. That weakens audit defensibility and hides where access review coverage is incomplete. Practitioners should measure governance by evidence continuity as well as by entitlement count.

Identity blast radius is the right named concept for this problem. As cloud sprawl increases, every unmanaged role, service account, and inherited permission expands the number of places where a single governance miss can matter. The more clouds and workloads an identity touches, the larger the blast radius of a certification gap or orphaned credential. Teams need to manage that blast radius as a first-class governance metric.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Identity blast radius: Multi-cloud sprawl increases the number of places where a single access decision can create exposure, so governance has to be measured by how far an identity can reach, not just by how many identities exist.

Access reviews that do not include service accounts, workload identities, and inherited permissions will miss the identities most likely to outlive their business purpose. That is why multi-cloud programmes need unified entitlement evidence before they can claim mature governance.

For practitioners

• Standardize cloud entitlement policies Define one governance standard for provisioning, privileged access, reviews, logging, and service account ownership across AWS, Azure, and GCP.
• Bind lifecycle workflows to authoritative events Connect onboarding, role change, temporary access expiry, and offboarding to HR and platform ownership data so cloud identities do not persist by default.
• Inventory and classify machine identities Build ownership, credential rotation status, and activity monitoring for service accounts, workload identities, and automation accounts.
• Certify privileged cloud roles continuously Review global administrators, root-equivalent permissions, cross-account roles, and Kubernetes admins on a fixed certification cadence.
• Centralize evidence for audit and remediation Unify provisioning activity, entitlement changes, review outcomes, and policy exceptions so auditors can see one control story across all clouds.

Key takeaways

• Multi-cloud identity governance fails when different cloud IAM models are managed as separate silos instead of one entitlement system.
• Orphaned identities, broad roles, and unmanaged service accounts are the recurring failure modes that expand cloud access risk.
• The practical answer is centralized visibility, lifecycle enforcement, and evidence-driven access review across every cloud provider.

Key terms

• Multi-cloud identity governance: Multi-cloud identity governance is the control of who and what can access resources across more than one cloud environment. It coordinates identities, roles, policies, approvals, and reviews across separate platforms so access remains consistent, auditable, and least privilege. It also covers lifecycle management, segregation of duties, and policy enforcement across clouds.
• Orphaned Identity: An orphaned identity is a service account, token, or other machine credential that no longer has a clear owner, purpose, or retirement path. These identities create compliance and security risk because they are easy to forget, difficult to review, and often remain active long after they should have been removed.
• Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
• Service account ownership: Service account ownership is the assignment of accountable control for a non-human identity to a named business or technical owner. Without ownership, review, rotation, and revocation become inconsistent, which creates blind spots in both security and compliance evidence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.