TL;DR: As organisations extend identity governance across AWS, Azure, GCP, Kubernetes, and SaaS, Apono argues that inconsistent roles, standing privilege, and fragmented audit evidence make multi-cloud access hard to control, while CSA research says three of the top four cloud breach causes are identity related. The core issue is that access reviews and static roles assume stable, platform-local privilege, but multi-cloud reality is cross-system and time-bound.
NHIMG editorial — based on content published by Apono: Multi-Cloud Identity Management: 10 Best Practices
By the numbers:
- three of the top four causes of cloud-related breaches were identity-related: excessive permissions (31%), inconsistent access controls (27%), and weak identity hygiene (27%).
Questions worth separating out
Q: How should security teams govern multi-cloud access across AWS, Azure, and GCP?
A: Security teams should normalise entitlements into one governance model, even if each cloud enforces access differently.
Q: Why do standing privileges become more dangerous in multi-cloud environments?
A: Because each cloud can accumulate excess rights independently, so a role that looks acceptable in one platform may still create lateral movement risk when combined with access in another.
Q: What do organisations get wrong about federated identity lifecycle management?
A: They often assume central authentication means central control over access removal.
Practitioner guidance
- Create a unified entitlement map Aggregate identity and entitlement data across AWS, Azure, GCP, Kubernetes, databases, and SaaS tools so you can see effective access across the full path, not just per platform.
- Replace standing elevation with JIT access Use time-bound access for production, admin, and database tasks, with automatic expiration and explicit approval conditions tied to purpose and duration.
- Govern non-human identities separately Inventory service accounts, workload identities, CI roles, and machine credentials, then scope each to the workload, environment, or pipeline stage it actually supports.
What's in the full article
Apono's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of the 10 best practices for multi-cloud identity management across AWS, Azure, GCP, Kubernetes, and SaaS tools.
- Specific examples of how JIT access, break-glass access, and automated revocation are applied in cloud-native workflows.
- The article's own access-control table showing common multi-cloud problems and the recommended governance response.
- Implementation detail on how the vendor maps access intent to provider-native roles without copying roles between clouds.
👉 Read Apono's multi-cloud identity management best practices →
Multi-cloud identity management: what IAM teams are missing?
Explore further
Multi-cloud identity sprawl is a governance problem before it is a cloud problem. When access is split across AWS, Azure, GCP, Kubernetes, and SaaS tools, the effective entitlement picture is broader than any single provider console shows. That makes least privilege hard to prove and revocation hard to trust. For identity programmes, the practical conclusion is that governance has to operate across the whole access path, not per platform.
A few things that frame the scale:
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to 2024 Non-Human Identity Security Report.
- Another 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which shows how easily NHI governance breaks down once access is decentralized.
A question worth separating out:
Q: Who is accountable when access evidence is spread across multiple clouds?
A: Accountability sits with the organisation, not the individual platform. Teams need one auditable chain that shows who approved access, which identity used it, what actions were taken, and when the entitlement expired. Frameworks such as the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 support that evidence-oriented approach.
👉 Read our full editorial: Multi-cloud identity management needs least privilege and JIT access