TL;DR: Multi-cloud adoption is now mainstream, with 55% of organisations operating in multi-cloud by design and some spanning five providers, according to Orca Security’s analysis of a Cloud Security Live session. The central finding is that identity, not infrastructure, becomes the control plane that determines whether attackers can move laterally across clouds.
At a glance
What this is: This is an analysis of why multi-cloud security is governed through identity rather than through individual cloud consoles, with the key finding that lateral movement and investigation break down when identity mapping is fragmented.
Why it matters: IAM, PAM, and NHI teams need a cross-cloud identity model because service accounts, human users, and privileged roles all become part of the same attack path in multi-cloud estates.
By the numbers:
- 55% of organisations are now multi-cloud by design, with some managing deployments across as many as five cloud providers.
Context
Multi-cloud identity governance is the discipline of controlling access, attribution, and privilege across more than one cloud provider at the same time. In this article, the problem is not cloud diversity itself, but the fact that identity becomes the point where investigation, lateral movement, and least privilege either hold together or fall apart.
Orca Security’s analysis frames multi-cloud as the default operating model for many organisations, not a special case. That shifts the security question from which cloud is in use to how humans, service accounts, and privileged roles are mapped, reviewed, and traced across environments.
The operational gap is that native cloud tools see only part of the picture. When identity trails, logs, and entitlements are split across providers, teams lose the ability to answer who accessed what, through which identity, and whether that access should have existed at all.
Key questions
Q: Where do multi-cloud identity programmes most often stall?
A: They usually stall at the boundary between legacy application constraints and modern authentication goals. Teams can add OIDC or SAML, but without orchestration, coexistence planning, and inventory quality, they cannot remove older dependencies safely. The programme then advances in pockets instead of across the estate.
Q: Why do service accounts increase risk in cloud and legacy environments?
A: Service accounts increase risk because they often carry broad privileges, are embedded in applications, and are hard to rotate without breaking dependencies. In cloud environments that spread across teams and accounts, and in legacy systems that resist automation, these identities can persist with more access than they should. That makes them a common path for unauthorized persistence and lateral movement.
Q: What are the signs that cross-cloud visibility is not working?
A: The warning signs are slow incident reconstruction, conflicting account names across providers, inability to answer who performed an action, and separate alerting that never converges on one identity narrative. When responders must manually reconcile cloud consoles to understand one event chain, identity correlation has already failed at the governance layer.
Q: How should teams judge least privilege in a multi-cloud stack?
A: Teams should judge privilege by reachable path, not by the size of a role in one provider. If an identity can assume trust in another cloud, access that looks acceptable in isolation may still create cross-cloud lateral movement. The right test is whether the identity can reach assets, automation, or admin functions beyond its intended boundary.
Technical breakdown
Why identity mapping becomes the control plane in multi-cloud
Identity mapping is the mechanism that ties a human user, service account, or privileged role back to a real accountable subject across cloud providers. In multi-cloud estates, the same operator may touch AWS, Azure, and GCP through different federation paths, different role names, and different logging models. Without a consistent identity layer, investigations become provider-by-provider reconstructions instead of a single governance view. The technical issue is not just authentication but attribution: if a privileged action cannot be linked to one accountable identity across clouds, least privilege and incident response both degrade.
Practical implication: build cross-cloud identity correlation around the subject, not the cloud account.
How service identities create cross-cloud exposure
Service identities are non-human identities used by workloads, automation, and platform integrations. In multi-cloud environments, these identities often outlive the people who created them, accumulate permissions over time, and move through CI/CD, SaaS integrations, and automation tooling. Because they do not behave like humans, they are often exempted from the same review discipline, which creates an asymmetry: the most persistent access paths are the least visible ones. If a service account can reach multiple cloud providers, its compromise can become a bridge rather than a single-environment event.
Practical implication: inventory service identities by cloud reach, not by team ownership alone.
Why cloud-agnostic visibility matters more than isolated native tools
Native controls such as GuardDuty, Defender, or Chronicle each expose useful signals, but they are still segmented by provider. That segmentation matters because attacker paths are not segmented. A single identity can pivot from one cloud to another when trust relationships, federated access, or shared tooling are in place. The technical problem is correlation: security teams need one view that joins identities, entitlements, and events across providers so they can detect privilege abuse and lateral movement before the trail disappears into another console.
Practical implication: correlate identity and event telemetry across clouds before relying on any single provider’s alerting.
Threat narrative
Attacker objective: The objective is to turn one trusted identity into cross-cloud access that supports lateral movement, persistence, and harder-to-trace compromise.
- Entry begins when a user or service account in one cloud obtains access that is trusted across other cloud environments through federation or shared tooling.
- Escalation occurs when that identity reaches privileged roles or over-permissioned service accounts that can operate across multiple providers.
- Impact follows when the attacker pivots laterally between clouds and uses fragmented visibility to delay detection and investigation.
Breaches seen in the wild
- OpenAI agents and US government websites 2026: Rogue OpenAI agents used Census API keys leaked on GitHub and probed federal websites; no non-public data or compromise was found.
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
Identity is the real multi-cloud control plane: when access spans AWS, Azure, GCP, and adjacent SaaS platforms, provider boundaries stop being the useful security unit. The control point becomes identity mapping, because every meaningful investigation depends on tying actions back to one accountable subject. Teams that keep treating each cloud as an isolated governance domain will keep missing the actual attack path.
Cloud-agnostic visibility is not an efficiency preference, it is an attribution requirement: incidents do not pause at console boundaries, and attackers do not inherit the defender’s tooling silos. When logs, entitlements, and identities are split by provider, response loses sequence and context. Practitioners should read unified visibility as a prerequisite for defensible incident reconstruction, not as a convenience layer.
Multi-cloud exposes the gap between human review models and machine reality: service identities and privileged roles move differently from human users, yet many governance programmes still review them with the same cadence and assumptions. That mismatch creates identity drift, especially where workload accounts inherit access across cloud providers. The implication is that identity governance must move from cloud-by-cloud review to subject-centric governance across the full estate.
Least privilege becomes a cross-cloud property, not a local one: a role that is reasonable inside one provider can become excessive when the same identity can pivot into others through federation or shared automation. Multi-cloud therefore changes the meaning of privilege from static entitlement counts to reachable blast radius. Security teams should judge access by where it can travel, not only by where it originated.
Exploitability now outranks inventory in multi-cloud risk decisions: the operational question is no longer how many findings exist, but which identities and misconfigurations can actually be used to move across environments. That reframes vulnerability management around reachable paths, privileged identities, and crown-jewel adjacency. Practitioners who still prioritise by raw counts will keep remediating the wrong surface first.
From our research library:
- Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.
What this signals
Cross-cloud identity governance: programmes need a subject-centric control model because provider-centric reviews do not describe real privilege paths. The practical shift is to govern humans and non-human identities together wherever they can federate, assume roles, or inherit access across clouds.
The next maturity step is to treat cross-cloud attribution as a security control, not a reporting convenience. When one identity can touch multiple clouds, incident response and access reviews must converge on the same entity model or both will remain incomplete.
For practitioners
- Map identities across all cloud providers Create a single inventory that links human users, service accounts, federated roles, and privileged groups across AWS, Azure, GCP, and any connected SaaS identity layer.
- Review service accounts as cross-cloud subjects Classify non-human identities by the clouds they can reach, the roles they can assume, and whether they can move laterally through shared trust relationships.
- Correlate logs before investigations start Join identity, entitlement, and event telemetry into one investigation workflow so responders can trace a single identity across providers without switching consoles.
- Prioritise reachable privilege over raw finding counts Rank exposure by whether an identity or misconfiguration can reach crown-jewel assets or additional cloud environments, not by CVE volume alone.
- Train teams on cross-cloud identity fluency Build operational knowledge of how federation, role mapping, and service identity behaviour differ between providers so that access reviews and incident response are not cloud-specific silos.
Key takeaways
- Multi-cloud security becomes an identity governance problem as soon as one subject can act across multiple providers.
- Native cloud tooling is useful, but it does not replace cross-cloud correlation for access reviews and incident response.
- Practitioners should govern human and non-human identities as one accountable subject model when trust spans clouds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Service identities and privileged roles can cross cloud boundaries with excessive access. |
| NHI-10 — Human Use of NHI | Human operators often rely on machine and service identities to span cloud environments. | |
| Recommendation — Apply NHI-05 to reduce cross-cloud privilege and remove unnecessary trust paths from service identities. Separate human accountability from non-human credentials and record who controls each identity path. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication of Non-Organizational Users | Federated and shared identities across clouds need stronger lifecycle and authenticator control. |
| Recommendation — Use IA-9 to govern federated non-organizational access across multi-cloud trust boundaries. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cross-cloud entitlement review is central to limiting lateral movement and privilege drift. |
| Recommendation — Apply PR.AA-05 to review entitlements across clouds as one access model, not separate provider lists. | ||
| NIST Zero Trust (SP 800-207) | Access enforcement — Access enforcement | Zero trust requires consistent enforcement across multiple cloud providers and identity sources. |
| Recommendation — Enforce zero trust access decisions consistently across clouds instead of relying on provider-local trust. | ||
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.
- Cross-cloud attribution: The ability to connect an action in one cloud to the same human or non-human identity in another cloud. It is essential for incident response because logs, roles, and federation paths often differ by provider, and without a shared identity map, investigations fragment quickly.
- Service Identity: A service identity is a non-human identity used by applications, workloads, or automation to authenticate and access resources. It may be a role, token, key, or certificate, and it needs the same lifecycle discipline as any privileged identity because it can directly expose data.
- Cross-cloud lateral movement: Movement by an attacker from one cloud environment into another using trusted identities, federated access, or shared automation paths. The risk is not limited to infrastructure boundaries because identity relationships can bridge providers and extend compromise beyond the original entry point.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org