How should teams govern identity across multiple cloud platforms?

Why This Matters for Security Teams

Multi-cloud identity governance fails when teams assume each provider’s native controls add up to a single access model. They do not. Different entitlement formats, token lifetimes, vault behaviours, and revocation paths create gaps that attackers can exploit, especially where service accounts, workload identities, and API keys are spread across AWS, Azure, GCP, and SaaS. The governance problem is broader than directory sync: it is about consistent policy intent, evidence, and lifecycle control.

The scale of the issue is not hypothetical. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into service accounts in the Ultimate Guide to NHIs, which means most teams are already making access decisions without a complete inventory. That breaks auditability, complicates offboarding, and makes revocation look successful in one platform while quietly failing in another. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames identity as a continuous governance function, not a one-time provisioning task. In practice, many security teams encounter multi-cloud identity failures only after a revoked credential still works somewhere else.

How It Works in Practice

Effective multi-cloud governance starts by treating identity as a policy layer above the platforms, not as a directory that each cloud must mirror. Teams define common intent for who or what can act, under which conditions, and for how long, then translate that intent into provider-specific controls. This is where standardised naming, consistent entitlement mapping, and shared lifecycle states become essential.

A practical operating model usually includes:

• A single inventory for NHIs, workload identities, agents, secrets, and their owning service.
• Policy-as-code to express access intent once, then evaluate it across cloud accounts and subscriptions.
• JIT credential issuance so high-risk access is time-bound and revoked automatically after task completion.
• Central logging for grant, use, rotation, and revocation events so audit evidence is portable.
• Automated checks that verify revocation truly removed access from keys, tokens, vault entries, and trust relationships.

This approach aligns well with the lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with NIST’s identity and governance expectations in the NIST Cybersecurity Framework 2.0. For organisations using autonomous tools or AI-driven workloads, this becomes even more important because the access pattern is dynamic rather than human-shaped. Static RBAC alone is usually too blunt; current guidance suggests pairing RBAC with context-aware checks and short-lived credentials. These controls tend to break down when each cloud has different token semantics and different revocation latency, because the policy may be consistent while enforcement is not.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations must balance control strength against deployment speed and platform autonomy. That tradeoff matters most in hybrid estates, merger environments, and teams running platform engineering across multiple cloud tenants.

One common variation is federation-first architecture: rather than centralising every identity into one directory, teams trust a common issuer and map that trust into each cloud. That works well for workload identity, but it still needs guardrails for secret storage, rotation, and emergency revocation. Another edge case is vendor-managed automation or third-party integrations, where the identity owner is unclear and offboarding gets missed. NHI Mgmt Group’s Top 10 NHI Issues and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce that visibility and accountability are usually the weakest links, not the cloud provider itself.

There is no universal standard for multi-cloud identity normalisation yet, so best practice is to standardise your control objectives first, then allow each platform to implement them differently. That is especially true where secrets live in CI/CD, agents request access on the fly, or a cloud-native service cannot support identical policy expressions. In those cases, governance should prioritise measurable outcomes: least privilege, timely revocation, and proof that access decisions are enforced consistently across every connected environment.

Related resources from NHI Mgmt Group

• How should public sector teams govern hybrid identity security across cloud and on-prem systems?
• How should security teams govern service accounts and API keys across cloud platforms?
• How should security teams govern SSO across multiple enterprise applications?
• How should security teams govern non-human identities in cloud environments?