Notifications
Clear all
Topic starter
01/07/2026 2:00 am
TL;DR: Multi-cloud identity governance is becoming harder as AWS, Azure, and GCP each impose different IAM models, service account patterns, and audit requirements, leaving organisations exposed to excessive permissions, orphaned identities, and fragmented oversight. SecurEnds argues that centralized visibility and lifecycle controls are now necessary for consistent access governance across cloud environments.
NHIMG editorial — based on content published by SecurEnds: identity governance for multi-cloud environments
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 service accounts create so much risk in multi-cloud environments?
A: Service accounts create risk because they often have high privilege, weak ownership, and poor lifecycle discipline.
Q: What breaks when access reviews are done separately in each cloud?
A: What breaks is consistency.
Practitioner guidance
- Standardise cross-cloud entitlement inventory Create a normalised inventory of users, roles, service accounts, workload identities, and trust relationships across AWS, Azure, and GCP so reviewers can compare access consistently.
- Attach ownership to every machine identity Require each service account and automation credential to map to a named owner, workload, and retirement trigger.
- Move from periodic review to drift detection Use continuous entitlement monitoring to flag temporary access that never expires, inherited permissions that outgrow their purpose, and cross-account roles that no longer match business need.
What's in the full article
SecurEnds' full article covers the operational detail this post intentionally leaves for the source:
- Platform-by-platform discussion of AWS, Azure, and GCP entitlement models, including roles, bindings, and managed identities
- Examples of cloud identity risks such as wildcard permissions, cross-account trust, and service account sprawl
- Recommended governance checks for access reviews, policy enforcement, lifecycle automation, and audit reporting
- Implementation context for centralised dashboards, cloud connectors, and certification workflows
👉 Read SecurEnds' analysis of multi-cloud identity governance challenges →
Multi-cloud identity governance: what IAM teams need to fix now?
Explore further
01/07/2026 2:18 am
Multi-cloud governance fails when identity models are allowed to stay platform-native. AWS, Azure, and GCP expose privilege through different primitives, but organisations still need one governance outcome: consistent visibility, least privilege, and evidence. The more each cloud is managed as a separate identity island, the more entitlement drift and audit blind spots accumulate. Practitioners should treat cross-cloud translation as a core control requirement, not a reporting convenience.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI, which shows the governance gap is already visible before most programmes have defined controls.
A question worth separating out:
Q: How do cloud teams know if entitlement drift is getting out of control?
A: They should watch for access that remains after projects end, temporary roles that never expire, rising numbers of privileged assignments, and service accounts without clear ownership. If the gap between documented access and actual access keeps widening, governance is lagging behind cloud change instead of controlling it.
👉 Read our full editorial: Multi-cloud identity governance is breaking under cloud sprawl
