Subscribe to the Non-Human & AI Identity Journal
Architecture & Implementation Patterns

Multi-cloud

← Back to Glossary
By NHI Mgmt Group Updated May 31, 2026 Domain: Architecture & Implementation Patterns

A multi-cloud environment uses two or more public cloud providers at the same time. For security teams, the important issue is not the number of providers but the number of identity systems, policy models, and audit paths that must be governed consistently across them.

Expanded Definition

Multi-cloud is not just a procurement choice or resilience pattern. In security operations, it means identity, access, secrets, logging, and policy enforcement must stay consistent across different control planes that do not share one native trust model. Definitions vary across vendors, but in NHI security the term usually matters most when workload identities, service accounts, and automation agents move between environments.

The practical difference between multi-cloud and hybrid cloud is that multi-cloud splits responsibility across public providers, while hybrid often includes on-premises systems as well. That split creates separate assumptions about NIST Cybersecurity Framework 2.0 alignment, logging fidelity, token lifetimes, and privileged access workflows. NHI programs therefore need to treat each cloud as a distinct identity domain, even when the business experience is meant to feel unified.

The most common misapplication is assuming one cloud IAM policy model can be copied into another without re-validating role structure, secret storage, and audit coverage.

Examples and Use Cases

Implementing multi-cloud rigorously often introduces governance overhead, requiring organisations to weigh portability and resilience against duplicated policy work and more complex incident response.

  • A platform team runs container workloads in AWS and Azure, but centralises service-account inventory so NHI owners can review every workload identity before it gets production access.
  • An engineering group uses a shared secrets workflow after seeing how credential exposure can escalate quickly in incidents like the Azure Key Vault privilege escalation exposure, then applies the same process across both clouds.
  • A security team maps cloud-native roles to a common least-privilege baseline and validates it against NIST Cybersecurity Framework 2.0 outcomes so that access reviews are comparable across providers.
  • During migration, a company discovers that ephemeral automation tokens are issued differently in each cloud, so it standardises rotation and expiry rules before expanding deployment pipelines.
  • A blue team investigates cross-cloud blast radius after reading about the 230M AWS environment compromise and realises the same operational pattern could exist anywhere secrets are reused.

Why It Matters in NHI Security

Multi-cloud becomes an NHI issue because every additional cloud adds another place where service identities, API keys, certificates, and delegated permissions can drift out of policy. That drift is especially dangerous when automation is moving faster than governance. In the 2024 Non-Human Identity Security Report, 35.6% of organisations said managing consistent access across hybrid and multi-cloud environments was their top NHI security challenge, which shows the problem is operational, not theoretical.

Failure usually appears as duplicate permissions, inconsistent token lifetimes, weak secret handling, or audit trails that cannot be reconciled after an incident. The risk grows when teams rely on cloud-specific exceptions instead of a single entitlement policy for service accounts and agents. The Codefinger AWS S3 ransomware attack and the Snowflake breach both reinforce how quickly cloud access weaknesses can become enterprise-wide exposure when identity controls are fragmented.

Organisations typically encounter multi-cloud as a security problem only after a cross-environment incident or audit failure, at which point consistent identity governance becomes operationally unavoidable to address.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-02Covers secret sprawl and inconsistent workload identity controls across cloud environments.
NIST CSF 2.0PR.AC-4Addresses access permissions and least privilege, which are harder to enforce in multi-cloud.
NIST Zero Trust (SP 800-207)GV.RRZero Trust requires continuous verification across diverse identity and policy planes.

Standardise secret handling and workload identity governance across every cloud provider.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on May 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org