What breaks when organisations keep managing cloud identities separately in each hyperscaler?

Separate cloud identity management breaks revocation discipline, access review consistency, and auditability. Teams must repeat governance work in multiple consoles, often with different terminology and controls, which increases manual effort and the chance of missed entitlements. It also makes it harder to control workload credentials, especially when static keys or long-lived service accounts are copied into pipelines.

Why This Matters for Security Teams

Managing cloud identities separately in each hyperscaler turns identity into a set of local exceptions instead of a single control plane. That creates drift in revocation, review cadence, naming, and evidence collection, which is exactly where attackers and auditors find gaps. The issue is not just administrative overhead. It is a loss of trust in whether a permission was actually removed, whether a workload still needs it, and whether the same control means the same thing across environments.

NIST treats access control, auditability, and continuous monitoring as foundational security outcomes in the NIST Cybersecurity Framework 2.0, but multi-cloud identity sprawl makes those outcomes harder to prove in practice. NHIMG research on lifecycle management shows why identity governance has to follow the workload across its full lifespan, not stop at the boundary of a single provider. See the NHI Lifecycle Management Guide and the Top 10 NHI Issues for the operational patterns that keep repeating in real environments.

In practice, many security teams encounter over-permissioned workloads and stale access only after an incident review exposes that each cloud was governed differently from day one.

How It Works in Practice

The practical failure mode is fragmentation. AWS, Azure, and GCP each expose different identity primitives, review workflows, and terminology, so teams often compensate with spreadsheets, manual approvals, and local exceptions. That works until a workload moves, a pipeline is cloned, or a secret is reused in another account. At that point, revocation in one hyperscaler does not guarantee revocation everywhere, and access reviews become a set of partial snapshots rather than a reliable inventory.

For non-human identities, the better model is to treat the workload as the unit of governance and bind access to what the workload is allowed to do right now. Current guidance suggests combining workload identity, short-lived credentials, and policy-as-code so permissions are evaluated at runtime, not copied forward indefinitely. Standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls support least privilege, account management, and audit logging, while NHIMG’s analysis in the 2024 Non-Human Identity Security Report shows that multi-cloud consistency is one of the top reported challenges. In practice, teams reduce drift by standardising on a single lifecycle: create, bind, scope, rotate, attest, and revoke.

• Use one inventory of non-human identities across all clouds, including service accounts, tokens, and federation trust relationships.
• Prefer ephemeral credentials and workload identity over copied static keys, especially in CI/CD and automation.
• Map entitlement reviews to business service ownership, not to the cloud account where the identity first appeared.
• Automate revocation so decommissioning a workload removes access in every connected hyperscaler.

These controls tend to break down when organisations rely on shared admin teams and ad hoc exceptions because no single team owns the full identity lifecycle.

Common Variations and Edge Cases

Tighter central governance often increases onboarding friction and exceptions handling, so organisations have to balance consistency against platform autonomy. That tradeoff is real, especially where each hyperscaler supports different native features or where legacy workloads cannot yet move off long-lived service accounts.

Best practice is evolving, but current guidance suggests avoiding a “one console per cloud” operating model for anything that can become a cross-cloud credential dependency. In mature environments, the main edge case is not the cloud provider itself but the workload path: build systems, secret stores, and federated identities often span multiple accounts and even multiple identities per application. That is why NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives both emphasize evidence quality and lifecycle consistency over provider-specific convenience.

There is no universal standard for this yet, but the direction is clear: federate where possible, shorten credential lifetime, and make revocation verifiable across every platform. Organisations that keep separate identity governance in each hyperscaler usually discover the weakest link only when an access review, incident, or audit forces the identities to be reconciled under pressure.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities in cloud environments?
• How can organisations reduce the blast radius of compromised agent identities?
• What is the difference between managing human accounts and non-human identities?
• What breaks when organisations rely on point-in-time access reviews for cloud identities?