How do I manage NHI security in a multi-cloud environment?

Why This Matters for Security Teams

Multi-cloud security becomes an NHI problem fast because every cloud exposes different identity primitives, secret stores, logging patterns, and default trust assumptions. The risk is not just inconsistency. It is drift: one cloud may be using managed identity, another static API keys, and a third a separate vault workflow with different rotation rules. That fragmentation makes it hard to prove who or what accessed a workload, when credentials were issued, and whether privilege was appropriately bounded. The 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which closely matches what many teams experience operationally. A resilient program therefore needs a single identity and policy model, not three cloud-specific ones. The control objective is consistency: the same baseline for discovery, entitlement review, secret lifecycle, and audit evidence across all providers. For implementation guidance, the NIST Cybersecurity Framework 2.0 is useful because it pushes organisations toward repeatable governance, asset visibility, and access control outcomes rather than provider-by-provider exceptions. In practice, many security teams encounter cross-cloud NHI sprawl only after a leaked secret or over-permissioned workload has already crossed one boundary into another.

How It Works in Practice

Start with a unified NHI inventory that aggregates discovery from every cloud into one authoritative view. That inventory should capture workload identity, attached secrets, token lifetimes, privilege scope, and the systems each identity can reach. From there, standardise workload authentication on cryptographic identity rather than cloud-specific trust alone. In practice, Ultimate Guide to NHIs is the right foundation for understanding why non-human identities must be managed as first-class identities, not as an operations afterthought. A practical multi-cloud pattern usually includes:

• SPIFFE/SPIRE or equivalent workload identity so each service proves what it is before it gets access.
• Centralised secrets management that federates to each cloud vault, while keeping rotation, TTL, and revocation policy consistent.
• RBAC for baseline entitlements, with JIT access for elevated operations and short-lived credentials for sensitive paths.
• Policy-as-code for request-time authorisation so the same intent-based rules apply across clouds.
• Central logging and correlation so identity events can be investigated across provider boundaries.

The operational goal is not to make every cloud identical. It is to make the security decision model identical even when the platforms differ. That is why the NIST Cybersecurity Framework 2.0 aligns well with multi-cloud NHI governance: it supports repeatable identity, protect, detect, and respond controls across environments. Where teams also manage secrets-heavy cloud services, the Top 10 NHI Issues is useful for mapping the recurring failure patterns that show up in real deployments. These controls tend to break down when each cloud team is allowed to define its own identity lifecycle, because that creates policy drift faster than central governance can detect it.

Common Variations and Edge Cases

Tighter central control often increases operational overhead, requiring organisations to balance standardisation against cloud-team autonomy and release speed. The biggest exception is when a provider offers a mature managed identity service that is safer than the organisation’s shared alternative. In those cases, current guidance suggests using the cloud-native identity mechanism where it exists, but translating its output into a common governance model for review, logging, and access expiration. That avoids forcing every workload into one tooling pattern while still preserving uniform control outcomes. Another edge case is cross-cloud disaster recovery or migration, where identities may temporarily exist in two providers at once. Best practice is evolving here, and there is no universal standard for this yet. A pragmatic approach is to issue short-lived credentials only for the migration window, isolate elevated access behind JIT approval, and revoke old bindings immediately after cutover. The more sensitive the workload, the less acceptable long-lived shared secrets become. For background on why secret handling and lifecycle discipline matter, see the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the 52 NHI Breaches Analysis. Multi-cloud governance also becomes harder when third-party integrations span more than one cloud, because vendor access reviews often stop at the first platform boundary rather than the full trust chain.

Related resources from NHI Mgmt Group

• What are cloud managed identities and how do they help NHI security?
• What is phishing-resistant authentication and how does it relate to NHI security?
• What is the first step in building a modern NHI security programme?
• Why is ownership assignment critical for NHI security?