Multi-cloud identity governance is the real security control plane

At a glance

What this is: This analysis argues that multi-cloud security breaks down at the identity layer, where human and non-human access must be governed consistently across providers.

Why it matters: It matters because IAM, NHI, and PAM teams can no longer treat cloud boundaries, service accounts, and human access reviews as separate problems if they want unified attribution and containment.

By the numbers:

• 55% of organizations are now multi-cloud by design, with some managing deployments across as many as five cloud providers.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.

👉 Read Orca Security's analysis of multi-cloud identity governance and cloud security

Context

Multi-cloud security is the discipline of governing identity, access, logging, and response across more than one cloud provider. Once workloads, SaaS platforms, CI/CD systems, and identity services span different clouds, the real question is not which provider is in use, but whether the organisation can still trace who or what acted, from where, and with which privileges.

This article frames multi-cloud as an identity governance problem first. Human accounts, service accounts, and machine identities all become part of the same attack surface when access can cross provider boundaries, making least privilege, attribution, and unified visibility the practical controls that matter most.

For teams building that operating model, NHIMG’s Top 10 NHI Issues and the NHI Lifecycle Management Guide are useful reference points for aligning access scope, visibility, and offboarding across cloud environments.

Key questions

Q: How should security teams govern identities across multiple cloud providers?

A: Treat multi-cloud as one identity problem with several control planes. Build a unified inventory for human and non-human identities, map each principal to an owner and purpose, and standardise logging so access can be traced across AWS, Azure, and GCP. Without that baseline, attribution and containment will stay fragmented.

Q: Why do service accounts increase risk in multi-cloud environments?

A: Service accounts often carry the permissions that matter most, yet they are reviewed less consistently than human accounts. In multi-cloud estates, that creates a standing-privilege problem: one compromised or over-entitled principal can move between platforms and reach sensitive assets faster than defenders can separate normal from abnormal behaviour.

Q: What breaks when cloud-native security tools are used in isolation?

A: Investigation quality breaks first. Native tools can show activity inside one cloud, but they rarely provide a full identity story when an incident crosses provider boundaries. That leaves teams with partial logs, delayed correlation, and weaker decisions about whether access was legitimate or abused.

Q: Who should own multi-cloud identity governance?

A: Ownership should sit with the identity and cloud security functions together, because the issue is both access design and operational visibility. If platform teams manage cloud posture without identity governance, or IAM teams ignore provider-specific control planes, the organisation will keep missing cross-cloud attack paths.

Technical breakdown

Why identity becomes the control plane in multi-cloud

In multi-cloud environments, the dominant security question is not where the workload runs, but which identity can act across environments. Human users often authenticate through SSO, while service accounts and workload identities carry the permissions that actually move data, deploy changes, and reach sensitive systems. If those identities are not mapped back to a clear owner and purpose, attribution breaks down and lateral movement becomes easier. This is why cloud-native telemetry alone is insufficient: logs without identity context tell you what happened, but not whether access was appropriate or even expected.

Practical implication: build a cross-cloud identity inventory that ties every human and non-human principal to an owner, purpose, and privilege scope.

Unified visibility across AWS, Azure, and GCP

Each cloud provider offers strong native telemetry, but native tooling tends to stop at its own boundary. That creates blind spots when an attacker pivots from one provider to another or when a legitimate identity spans several environments. Unified visibility means correlating identity, configuration, and event data across clouds so that investigations can reconstruct the full path of action rather than isolated fragments. The architecture challenge is less about collecting more logs and more about normalising identity signals so that one principal can be traced consistently across multiple control planes.

Practical implication: normalise cloud identity telemetry into one investigation workflow so analysts can follow a principal across providers without switching consoles.

Exploitability matters more than raw vulnerability counts

Traditional vulnerability management overweights CVE counts and patch SLAs, but multi-cloud incidents often start with weak identities, over-permissioned roles, or exposed management paths. Exploitability changes the triage model by asking whether a weakness is reachable, whether it is attached to a critical asset, and whether it sits on a path to higher privilege. That reframes remediation from compliance-driven backlog reduction to attack-path reduction. In practice, the most urgent issue is not the largest list of findings, but the finding that can be abused to cross an environment boundary or touch a crown jewel.

Practical implication: prioritise reachable identity and configuration flaws that create cross-cloud attack paths ahead of low-exposure findings.

Threat narrative

Attacker objective: The objective is to turn one cloud foothold into broader access across the organisation’s multi-cloud estate.

1. Entry begins when an attacker obtains access through a weak identity, over-permissioned role, or misconfiguration in one cloud provider.
2. Escalation follows when that identity is used to pivot laterally across environments, exploiting inconsistent identity mapping and fragmented visibility.
3. Impact occurs when the attacker reaches crown-jewel systems or sensitive data before defenders can correlate the activity across cloud boundaries.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Identity sprawl is the real multi-cloud blast-radius multiplier. Multi-cloud itself is not the root problem; inconsistent identity ownership is. When the same organisation runs AWS, Azure, and GCP with different access models and different review cadences, the effective blast radius becomes a function of the weakest identity control chain. That means IAM, NHI governance, and PAM can no longer be treated as separate workstreams. The practitioner conclusion is that cross-cloud identity mapping is now a baseline control, not an optimisation.

Cloud-agnostic visibility is an attribution requirement, not a dashboard preference. Native tooling is useful, but it rarely gives investigators a complete identity narrative across provider boundaries. Without unified correlation, security teams are left reconstructing incidents from partial logs and incomplete principal context. That weakens response quality and obscures whether an identity behaved as designed or crossed into unintended privilege. The practitioner conclusion is that identity telemetry must be normalised before response maturity can be claimed.

Exploitability-based triage is the only rational way to govern multi-cloud risk at scale. The article’s core lesson is that many serious incidents come from reachable identities and misconfigurations rather than abstract vulnerability counts. Identity blast radius: the usable space an attacker can expand into once one principal is compromised or over-entitled. That concept matters because multi-cloud systems amplify small privilege mistakes into cross-environment exposure. The practitioner conclusion is to rank identity-driven attack paths above static issue totals.

Service identities deserve the same governance discipline as human users. The article correctly treats cloud “domain admin” as an identity problem, not a platform problem. Service accounts do not take vacations, but they do accumulate privilege, survive team changes, and outlive the context in which they were created. That puts lifecycle control, owner clarity, and least privilege on the same footing for humans and machines. The practitioner conclusion is to govern service identities as first-class principals, not infrastructure residue.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• The 2024 Non-Human Identity Security Report shows that only 19.6% of security professionals feel strongly confident managing workload identities, which is why NHI Lifecycle Management Guide belongs in the same conversation as multi-cloud visibility.

What this signals

Identity governance will become the convergence layer for multi-cloud and AI-era infrastructure. The organisations that can unify human IAM, NHI governance, and provider-specific cloud controls will be the ones that can still answer who acted, why, and with what privilege when incidents cross boundaries. That is a programme design issue, not a tooling preference.

Access scope will matter more than platform preference. As multi-cloud estates expand, teams will increasingly need to evaluate whether an identity can reach a crown jewel, not simply whether a control exists in a given cloud. The practical shift is toward attack-path reduction, not policy sprawl.

With 70% of organisations already 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 over-entitlement pattern that weakens multi-cloud security is now appearing in agentic systems too. That means cloud, IAM, and AI governance teams need one entitlement standard, not three separate ones.

For practitioners

• Build a cross-cloud identity inventory Map every human, service, and workload identity to a named owner, business purpose, and privilege scope across AWS, Azure, and GCP so investigators can trace action to principal without guessing.
• Normalise identity telemetry into one workflow Ingest authentication, authorisation, and privilege-change events into a single investigation path so analysts can correlate activity across providers instead of toggling between consoles.
• Prioritise reachable identity risk Rank exposed roles, misconfigurations, and over-permissioned service identities by whether they can reach crown jewels or move laterally, rather than by CVE count alone.
• Apply least privilege to machine accounts Review service identities with the same scrutiny used for human administrators, then remove standing access that is broader than the task actually requires.

Key takeaways

• Multi-cloud security fails when identity ownership is fragmented across providers and teams.
• Attackers exploit the gap between cloud-native visibility and unified identity context, which makes lateral movement harder to spot.
• Practitioners should prioritise cross-cloud identity inventory, unified telemetry, and exploitability-based triage over isolated platform controls.

Key terms

• Multi-cloud identity governance: The discipline of controlling human and machine access consistently across more than one cloud provider. It combines ownership, privilege scope, logging, and review so the organisation can still explain who acted and where, even when workloads span AWS, Azure, GCP, and supporting SaaS platforms.
• Identity blast radius: The amount of environment an attacker can reach once a single identity is compromised or over-entitled. In multi-cloud estates, the blast radius expands when principals are reused across providers, ownership is unclear, or access reviews are not aligned across control planes.
• Cloud-agnostic visibility: A cross-provider view that correlates identity, configuration, and event data into one investigative picture. It does not replace native controls, but it reduces blind spots by showing how the same principal behaves across different clouds and where a lateral path begins.
• Reachable exploitability: A way of ranking security issues by whether an attacker can actually use them to move, escalate, or access a valuable asset. It is more useful than raw finding counts in multi-cloud environments because it focuses remediation on weaknesses that can change an incident outcome.

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.

This post draws on content published by Orca Security: multi-cloud security lessons from Cloud Security Live. Read the original.