Multi-cloud security depends on consistent identity controls

At a glance

What this is: This analysis argues that multi-cloud risk is driven less by individual cloud weaknesses and more by inconsistent identity, logging, and policy enforcement between AWS, Azure, and GCP.

Why it matters: IAM, PAM, and NHI teams need a single governance model across providers because provider-native controls do not close the visibility and entitlement gaps created by multi-cloud operations.

By the numbers:

• 84% of enterprise organizations operate in two or more cloud environments, yet fewer than 30% had a unified security tool covering all providers in their estate.
• 67% of multi-cloud environments had at least one misconfigured network control that exposed a workload to the internet unintentionally.

Context

Multi-cloud security is the governance problem that appears when workloads, identities, and data are spread across AWS, Azure, and GCP but controls are still operated as if each environment were isolated. The article's core point is that the risk is not one cloud provider's posture, but the gaps between providers where audit, entitlement, and policy drift accumulate.

That matters for identity programmes because each cloud uses different identity primitives, different logging semantics, and different privilege models. When service accounts, managed identities, and IAM roles are not governed through a common control framework, least privilege becomes provider-specific rather than enterprise-wide.

Key questions

Q: What breaks when identity providers are treated as the only control for securing cloud identities?

A: Identity providers can verify that a credential or session is valid, but they do not control what an authenticated user or attacker does after access is granted. That gap matters when compromised credentials, MFA bypass, or stolen sessions are involved. Security teams need visibility into post-authentication behavior, privilege use, and anomalous application access, because the real risk often begins after the login succeeds.

Q: Why do inconsistent IAM roles and misconfigurations create more risk in multi-cloud environments?

A: Multi-cloud environments multiply the number of identities, policies, and configurations that must stay aligned. When access rules differ across AWS, Azure, and GCP, teams lose consistent visibility and enforcement. That makes it easier for excessive permissions, unvetted access changes, and manual remediation delays to persist, which increases both attack surface and compliance risk.

Q: How do teams know if multi-cloud compliance monitoring is actually working?

A: A working programme produces consistent control coverage, repeatable audit exports, and fast remediation across providers. Teams should be able to map each environment against relevant frameworks, track gaps in a single place, and show that fixes close the highest-risk issues first. If audits still require manual evidence gathering from separate consoles, the programme is not operating effectively.

Q: What should security teams do when cross-cloud federation expands blast radius?

A: Security teams should scope every federation path as if it were a lateral movement route, not a convenience feature. That means confirming who can assume what, from where, and with which conditions. If the trust path is broader than the business use case, the blast radius is already too large.

Technical breakdown

Why visibility fragments across cloud providers

AWS CloudTrail, Azure Monitor, and Google Security Command Center each provide native visibility inside their own cloud, but they do not correlate events across provider boundaries. That means an attacker who uses a compromised AWS credential to reach an Azure subscription through federation may leave two separate traces that never meet in a single workflow. In practice, the detection problem is not the absence of logs, but the absence of normalisation, correlation, and common severity logic across clouds. Unified visibility is therefore a control layer, not a dashboard feature.

Practical implication: Treat cross-cloud correlation as a control requirement and feed all provider logs into one security pipeline.

IAM model inconsistency and least privilege

AWS IAM roles, Azure Managed Identities, and GCP Service Accounts all express authority differently, so a policy written for one provider rarely maps cleanly to another. That creates entitlement drift: the same human or workload can end up with different privilege semantics depending on where it runs. The article correctly ties this to least privilege because privilege cannot be governed consistently when inventory, naming, and permission boundaries differ by platform. CIEM becomes essential because it normalises identities and permissions across environments, making over-privilege visible at scale.

Practical implication: Build a provider-agnostic entitlement model before enforcing least privilege across clouds.

Configuration drift becomes an attack surface

Multi-cloud drift happens when a policy change lands in one cloud but not the others, leaving inconsistent network, logging, or encryption settings in place. The article's example of different security benchmarks across AWS and Azure shows why equivalent controls must be measured by outcome, not by platform-specific implementation. Once drift is accepted as normal, the environment slowly accumulates exposures that are hard to detect because each provider's native tooling only sees part of the picture. CSPM and IaC scanning reduce that gap by checking the same control intent across all providers.

Practical implication: Scan IaC and cloud posture continuously so policy changes do not diverge between providers.

Threat narrative

Attacker objective: The attacker aims to turn one cloud foothold into broader cross-provider access by exploiting inconsistent identity and visibility controls.

1. Entry occurs when an attacker compromises a credential in one cloud environment and begins working through the federated trust path into another provider.
2. Credential access and privilege abuse follow when the same identity model is interpreted differently across platforms, allowing over-privileged access to persist unnoticed.
3. Impact occurs when fragmented monitoring and configuration drift prevent security teams from connecting the cross-provider sequence before the attacker expands access or moves laterally.

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.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cross-cloud identity governance fails when each provider is treated as a separate trust domain. Multi-cloud environments do not simply add more assets; they multiply identity models, logging pipelines, and policy exceptions. The governance failure is that most programmes still certify access and monitor events one provider at a time, even though the attacker moves across them as a single environment. Practitioners should treat provider boundaries as governance boundaries only if they are also control boundaries.

Visibility fragmentation is the most dangerous multi-cloud condition because it breaks correlation before it breaks confidentiality. When AWS, Azure, and GCP each produce valid but isolated telemetry, the security team sees partial facts and delayed context. That means the main failure is not alert volume but the inability to join identity, network, and workload signals into one path of evidence. Multi-cloud security programmes need a normalised control plane for detection, not just better dashboards.

Provider-agnostic policy is now the only defensible way to express least privilege across cloud estates. AWS IAM, Azure identities, and GCP service accounts are different implementations of the same governance problem, but they cannot be managed with three separate policy vocabularies and still be called consistent. This is where CIEM, CSPM, and IaC scanning become governance infrastructure rather than point tools. The practical conclusion is that entitlement management must be written once and enforced everywhere.

Identity blast radius is the right named concept for multi-cloud risk. A compromise in one cloud does not stay local when federation, shared service accounts, and inconsistent audit trails exist across providers. The blast radius is defined less by the initial compromise than by how far the identity can travel before detection or revocation. Security teams should measure their estate by how quickly they can collapse that blast radius, not by how many native cloud controls they have deployed.

Multi-cloud resilience is only real when control consistency matches deployment diversity. Organisations adopt multiple clouds to reduce dependency and improve flexibility, but the security model often stays fragmented. That creates a false sense of resilience: availability may improve while identity governance weakens. The implication is straightforward. Programmes that cannot express the same control intent across AWS, Azure, and GCP should not claim mature multi-cloud governance.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity blast radius: In multi-cloud estates, the meaningful unit of risk is not a single cloud account but the furthest identity path that can be traversed before detection. That is why provider-agnostic inventory and federation review matter more than isolated hardening. Consistent identity controls shorten the distance an attacker can travel across AWS, Azure, and GCP.

Multi-cloud programmes should expect governance pressure to move from control ownership to control equivalence. The operational question is no longer whether each provider is secure on its own, but whether the same entitlement, logging, and review standards survive translation across clouds.

For practitioners

• Standardise cross-cloud identity inventory Create a single inventory of human, workload, and service identities across AWS, Azure, and GCP, then map every entitlement to one governance owner. This is the only reliable way to see over-privilege, orphaned access, and trust relationships that span providers.
• Normalize provider logs before correlation Send CloudTrail, Azure Activity Log, and GCP Audit Logs into one pipeline and translate them into a common schema before detection logic runs. Without normalisation, cross-cloud investigations will always lag behind the attack path.
• Define policies at the provider-agnostic layer Write least-privilege, logging, and encryption requirements once at the policy level, then translate them into each cloud's native controls. This reduces drift and prevents different teams from inventing incompatible interpretations of the same rule.
• Use CIEM to surface entitlement drift Continuously compare actual permissions against intended access across workloads, service accounts, and federated identities. CIEM is the practical control for finding unused access, cross-account trust, and privilege that no longer matches business need.
• Test cross-cloud federation paths Review every trust relationship that allows identities to move from one provider into another, and verify that each path is explicitly scoped and monitored. Cross-cloud federation is where blast radius expands fastest when governance is weak.

Key takeaways

• Multi-cloud security fails most often in the spaces between providers, where identity models, logs, and policy enforcement stop lining up.
• Fragmented visibility and inconsistent entitlements are the two conditions that turn a resilience strategy into a cross-cloud exposure surface.
• The practical fix is enterprise-wide control consistency, with identity inventory, normalised telemetry, and provider-agnostic policy as the baseline.

Key terms

• Multi-Cloud Security Posture: The practice of monitoring and managing security controls across more than one cloud platform from a single operational view. It reduces blind spots caused by separate tooling, inconsistent reporting, and different remediation workflows. In practice, it supports faster detection of misconfigurations and more consistent enforcement of baseline controls.
• Visibility Fragmentation: Visibility fragmentation is the condition where security telemetry exists, but only inside separate provider consoles or tools. In multi-cloud estates, it prevents teams from correlating one provider’s event with another’s and leaves lateral movement or drift hidden in plain sight.
• Cloud Infrastructure Entitlement Management: Cloud Infrastructure Entitlement Management focuses on who has access to what in cloud systems, especially excessive or unused permissions. It helps reveal overprivileged identities, but it does not automatically remove them. In practice, it is most useful when tied to policy enforcement and access expiry mechanisms.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.