Multi-cloud security depends on consistent identity controls

At a glance

What this is: This is an Orca Security analysis of multi-cloud security, with the core finding that cross-provider identity and visibility gaps create the most persistent risk.

Why it matters: It matters because IAM, NHI, and human identity programmes now need one governance model that can survive different cloud permission systems, logging pipelines, and trust boundaries.

By the numbers:

• Orca Security’s 2025 State of Cloud Security Report found that 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.
• Orca Security’s 2024 State of Cloud Security Report found that 67% of multi-cloud environments had at least one misconfigured network control that exposed a workload to the internet unintentionally.

👉 Read Orca Security’s analysis of multi-cloud security challenges and controls

Context

Multi-cloud security is the discipline of applying consistent controls across two or more cloud providers, rather than treating AWS, Azure, and GCP as separate security problems. The primary identity question is whether access, logging, and policy enforcement remain coherent when each provider expresses IAM differently and exposes different native control planes.

That coherence breaks down quickly in practice. A workload identity may be sound in one cloud and over-permissioned in another, while audit evidence is split across three consoles with no native correlation. For teams building cloud governance around NHI and workload identity, the issue is not provider quality but cross-provider consistency, which is why multi-cloud programmes should be evaluated as one identity control surface, not three isolated stacks.

Orca Security’s analysis is typical of what practitioners see in mature cloud estates: resilience gains are real, but so are the governance seams. Once those seams are visible, the security model has to shift from provider-level hardening to federation, entitlement control, and centralised detection.

Key questions

Q: How should security teams govern identities across multi-cloud environments?

A: Start by treating all cloud identities as one policy domain, even when the providers use different native models. Map roles, service accounts, and managed identities to a common entitlement baseline, then validate that logging, review, and revocation work across AWS, Azure, and GCP instead of inside each provider’s console.

Q: Why do multi-cloud environments create more identity risk than single-cloud estates?

A: Because the risk sits in the gaps between providers. Each cloud has different permission semantics, log formats, and trust boundaries, so the same over-privilege or federation mistake can be harder to see and easier to exploit when activity crosses clouds.

Q: What breaks when multi-cloud security relies only on native cloud tools?

A: Cross-provider correlation breaks first. Native tools can show local activity, but they do not automatically connect an AWS event to a matching Azure or GCP event, which leaves lateral movement, drift, and entitlement abuse hidden behind separate consoles.

Q: How do you know if multi-cloud governance is actually working?

A: You should be able to answer three questions quickly: which identities exist, what they can reach across providers, and whether any trust path has escaped review. If those answers require manual stitching across three consoles, the governance model is not working.

Technical breakdown

Why IAM model inconsistency is the core multi-cloud problem

AWS IAM roles, Azure Managed Identities, and GCP Service Accounts all solve workload identity, but each uses different primitives, policy syntax, and trust assumptions. A least-privilege design written for one provider does not translate cleanly to another because the authorisation model, token issuance flow, and resource hierarchy differ. That means teams often think they have a uniform control when they actually have three distinct implementations with different failure modes. In multi-cloud estates, the challenge is not merely access reduction. It is policy equivalence across provider boundaries.

Practical implication: define access policy once at a provider-agnostic level, then map it explicitly to each cloud’s native model.

How visibility fragmentation hides cross-cloud attack paths

Native tooling such as CloudTrail, Azure Monitor, and Google Security Command Center is useful, but each sees only its own provider. When an attacker starts in one cloud and pivots through federated identity into another, the activity often appears as unrelated events unless logs are normalised into a shared schema and correlated centrally. This is why alert fatigue becomes a structural problem in multi-cloud operations. The issue is not lack of telemetry. It is lack of unified interpretation across boundaries.

Practical implication: centralise audit data and normalise event formats before you rely on cross-cloud detection or incident correlation.

Why CIEM and CSPM must work together in multi-cloud estates

Cloud Security Posture Management finds misconfiguration, while Cloud Infrastructure Entitlement Management finds excess privilege. In multi-cloud environments, those problems often reinforce each other because a weak control plane plus an over-broad role creates a ready-made escalation path. Infrastructure-as-code scanning adds a preventive layer by catching bad defaults before deployment, but only if the policy baseline is shared across providers. The architectural point is simple: posture without entitlement visibility leaves privilege blind spots, and entitlement review without configuration context misses the route an attacker can actually use.

Practical implication: use CSPM, CIEM, and IaC scanning as a single governance loop, not as separate point checks.

Threat narrative

Attacker objective: The attacker aims to turn a single cloud foothold into cross-provider reach without triggering unified detection or entitlement review.

1. Entry occurs when a workload credential or federated trust relationship in one cloud is exposed or over-scoped, giving the attacker a foothold in the first provider.
2. Escalation follows when inconsistent IAM models or permissive cross-cloud trust let that foothold be used to reach another provider, where the event may appear unrelated in native logs.
3. Impact is achieved when the attacker moves laterally across provider boundaries, expanding blast radius and evading detection that only sees one cloud at a time.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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 security is fundamentally an identity consistency problem, not a cloud count problem. Once an organisation operates across AWS, Azure, and GCP, the risk comes from how differently each platform expresses entitlement, logging, and trust. The practical conclusion is that security teams must govern the identity layer as a single control surface, or they will keep missing the seams where incidents begin.

Visibility fragmentation is the multi-cloud failure mode that most often turns a manageable issue into a cross-provider incident. Native consoles are useful, but they do not correlate activity across clouds, which means the attacker can look like three small events instead of one chain. That is why unified detection and log normalisation are not optimisation tasks. They are prerequisites for basic accountability.

Cloud Infrastructure Entitlement Management should be treated as the cross-cloud privilege ledger. In multi-cloud estates, over-permissioned roles and cross-account trust are the shortest path from configuration weakness to lateral movement. This is where entitlement review becomes a governance control rather than a hygiene exercise, because the same excessive privilege can exist in different forms across different providers.

Provider-agnostic policy is the only sustainable way to reduce drift across multi-cloud environments. Security rules written separately for each cloud tend to diverge as services, permission types, and defaults change. A shared policy baseline does not remove provider complexity, but it makes that complexity governable. Practitioners should treat translation drift as a structural risk, not an implementation detail.

Blast radius containment only works when federated trust is explicitly scoped and continuously monitored. Multi-cloud architecture can limit damage, but only if the trust paths between providers are narrow enough to be understood and controlled. The practitioner takeaway is that federation is not a one-time design choice; it is an ongoing governance boundary.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• For a broader identity governance lens, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding across non-human identities.

What this signals

Multi-cloud governance will keep converging on the identity layer. The more providers an estate spans, the more value accrues to a shared entitlement model that can explain access consistently across workloads, service accounts, and federated trust relationships. In practice, that means access reviews, policy mapping, and runtime detection need to be designed as cross-cloud controls rather than provider-specific workflows.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the same entitlement discipline now has to extend to autonomous and semi-autonomous workloads as they enter multi-cloud estates.

Identity blast radius: the effective damage boundary is no longer a single cloud account, but the intersection of identity, federation, and logging visibility. Teams that cannot see that boundary will continue to misread where one provider’s incident ends and another provider’s begins.

For practitioners

• Map every cloud identity to one entitlement model Inventory AWS IAM roles, Azure Managed Identities, and GCP Service Accounts in a shared catalogue, then record which permissions are equivalent, overlapping, or unique across providers.
• Normalise logs before you rely on cross-cloud detection Feed CloudTrail, Azure Activity Log, and GCP Audit Logs into a single SIEM or data lake and normalise them to a common schema such as OCSF.
• Tie CIEM findings to IaC review gates Block deployment when templates introduce over-broad roles, missing logging, or cross-cloud trust that was not approved in the policy baseline.
• Review federated trust paths as attack paths Document every trust relationship between providers, then validate that each one has a business owner, scope limit, and revocation path.
• Run multi-cloud access audits on a fixed cadence Audit identities, permissions, and network exposure across all providers together so drift in one cloud is not treated as a separate problem.

Key takeaways

• Multi-cloud security fails most often at the seams between providers, where identity models, logs, and trust paths stop lining up.
• Unified visibility and entitlement control are the difference between resilience and a distributed blind spot.
• Practitioners should govern multi-cloud as one identity system with multiple execution environments, not as separate clouds with separate rules.

Key terms

• Multi-Cloud Identity: Multi-cloud identity is the set of identities, trust relationships, and access policies that operate across more than one public cloud provider. The security challenge is keeping those identities consistent when each provider uses different permission models, logging formats, and federation patterns.
• 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 is the practice of inventorying and analysing cloud permissions to find over-privilege, unused access, and risky trust relationships. In multi-cloud environments, it is the control that reveals how access expands across providers and where entitlement drift creates escalation paths.
• Federated Trust Path: A federated trust path is the chain that allows one identity in one environment to authenticate into another through a shared trust relationship. In multi-cloud security, it is both a resilience mechanism and a potential attack path, so scope and revocation matter as much as the initial setup.

Deepen your knowledge

Multi-cloud identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme has to reconcile access across AWS, Azure, and GCP, this is a strong fit.

This post draws on content published by Orca Security: Multi-cloud security analysis and operational guidance. Read the original.