Who should own multi-cloud identity governance?

Why This Matters for Security Teams

Multi-cloud identity governance fails when ownership is split by control plane instead of by attack path. Cloud teams can harden configurations, but they rarely have the identity context needed to spot over-privileged service accounts, shared secrets, or cross-account trust drift. Identity teams can define policy, but they often lack visibility into provider-specific roles, managed identities, and workload-to-workload access.

The result is a gap between design and operations. NHIMG research on Ultimate Guide to NHIs shows the lifecycle and governance burden is not theoretical, especially when identity sprawl crosses environments. The NIST Cybersecurity Framework 2.0 makes clear that identity governance belongs inside enterprise-wide risk ownership, not as a side task for platform engineering alone.

A practical ownership model usually gives one function accountable for policy and review, while another owns the cloud-specific implementation and telemetry. In practice, many security teams encounter cross-cloud privilege chains only after an incident review reveals that no single group was watching the full identity path.

How It Works in Practice

The strongest operating model is a shared one with clear decision rights. Identity security should own the standards for authentication, authorization, secrets lifecycle, JIT access, and workload identity. Cloud security or platform security should own the provider-native enforcement, logging, and remediation workflows. This split works because multi-cloud identity governance is both a policy problem and an engineering problem.

For human and non-human identities alike, the governing team should define baseline controls for RBAC, privileged access management, and secret handling, then validate them against each cloud provider’s native constructs. For non-human identities, that means treating workload identity as the primitive, not a long-lived secret. NHIMG’s Top 10 NHI Issues research reflects how often governance breaks down when credentials, ownership, and lifecycle are distributed across teams. Current best practice also aligns with NIST Cybersecurity Framework 2.0 outcomes that require consistent asset, identity, and access oversight.

A workable pattern usually includes:

• One accountable identity governance owner for policy, exceptions, and audit evidence.
• One cloud operations owner for account structure, roles, telemetry, and control-plane enforcement.
• Shared reviews for cross-cloud trust relationships, service-to-service access, and inherited permissions.
• Automated checks for stale secrets, over-broad roles, and unmanaged workloads.

At the implementation layer, organisations should use cloud-native logs, identity inventories, and policy-as-code to detect drift across providers. The key is that no team should be able to change identity exposure without a visible approval path. These controls tend to break down when mergers, shadow cloud accounts, or autonomous workloads create identity sprawl faster than ownership maps can be updated.

Common Variations and Edge Cases

Tighter identity governance often increases coordination overhead, requiring organisations to balance speed of cloud delivery against review depth and exception handling. That tradeoff is real, especially in regulated environments where each cloud platform has different administrative boundaries and audit evidence requirements.

In small organisations, a single security leader may own both identity and cloud governance until scale forces separation. In larger enterprises, the better model is usually a federated one: a central identity authority sets standards, while cloud domain teams enforce them locally. Best practice is evolving for multi-cloud Kubernetes, serverless, and managed AI services, because there is no universal standard for governance ownership in those areas yet.

The hardest edge case is the autonomous workload. When AI agents or orchestration systems can request access, chain tools, or make changes across clouds, static approvals stop being enough. That is where the conversation shifts toward runtime policy, short-lived credentials, and workload identity governance rather than annual access recertification alone. NHIMG’s 230M AWS environment compromise demonstrates why ownership failures become material when cloud identity paths are not continuously governed.

Related resources from NHI Mgmt Group

• Who should own identity and device governance in a consolidated work platform?
• Who should own privileged access governance in an identity programme?
• Why do multi-tenant identity platforms increase governance risk if they are not well controlled?
• Who should own AI identity governance in an organisation?