Topic starter
12/06/2026 12:26 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Navigating the Complexities of Multi-Cloud Security: Key Takeaways from Cloud Security Live”.
By the numbers:
- 55% of organisations are now multi-cloud by design, with some managing deployments across as many as five cloud providers.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Multi-cloud security becomes an identity governance problem as soon as one subject can act across multiple providers.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
12/06/2026 9:41 am
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.
A few things that frame the scale:
- Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.
A question worth separating out:
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.
👉 Read our full editorial: Multi-cloud identity governance is the real security control plane
This post was modified 1 day ago by NHI Mgmt Group