TL;DR: Cross-cloud visibility, runtime protection, data security and provider-native policy layers each solve a different part of multi-cloud security, according to Native, and no single tool covers the whole stack. Enforcement becomes the deciding layer because it keeps one intent consistent across AWS, Azure, Google Cloud and OCI when conditions drift.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Native's blog post: Multi-cloud security is a stack of distinct control layers, and policy stays consistent across clouds when enforcement, not visibility alone, is used.
Why it matters: IAM, cloud security and NHI teams need to separate discovery from enforcement because identity context, policy drift and cloud-specific control planes can make cross-cloud coverage look complete when it is not.
Context
Multi-cloud environments create a governance problem before they create a tooling problem: each cloud exposes different policy primitives, different telemetry and different control planes. When teams try to manage them as one environment, gaps appear between what is visible, what is detected and what is actually enforced. Cloud security only becomes coherent when those layers are treated separately and then joined under one operating model.
The article is especially useful because it treats multi-cloud security as a control-stack question rather than a product shortlist. That framing matters for identity because who or what can reach a resource, and under which cloud-specific policy, determines whether segmentation and baseline controls survive drift.
Key questions
Q: What is the difference between visibility and enforceable access control in cloud security?
A: Visibility shows what is happening, but enforceable access control changes what is allowed to happen. A cloud access tool that can report activity but cannot propagate policies quickly or reliably gives teams awareness without sufficient operational authority, which is a weak outcome for governance.
Q: How can identity data improve cloud segmentation decisions?
A: Identity data improves segmentation by showing which users, service accounts and workloads actually need to talk to each other, so network and application segments can be built around real access relationships rather than IP ranges alone. Practitioners use entitlement data, workload identity, communication graphs and least-privilege rules to reduce lateral movement and overbroad trust.
Technical breakdown
Why cross-cloud visibility does not equal control
Cross-cloud visibility tools aggregate posture, identity, runtime and vulnerability signals into one view, but that view is only descriptive. A CNAPP can show an exposed secret, an overprivileged role and a reachable workload on the same graph, yet still rely on separate provider policy engines to stop anything. The architectural gap is between knowing that a risk path exists and changing what AWS, Azure, Google Cloud or OCI will accept. That distinction is why visibility is useful for prioritisation but insufficient for containment. See the Multi-Cloud Identity Guide.
Practical implication: Treat aggregated findings as decision support, not enforcement, and verify which cloud-native policy layer must actually block the action.
How provider-native policy layers keep intent consistent
Provider-native enforcement works because each cloud applies its own policy engine close to the resource. AWS Organizations SCPs and RCPs, Azure Policy, Google Cloud Organization Policy and OCI IAM controls all operate within their own acceptance model. The challenge is not defining intent once, but preserving that intent as resources, identities and workloads change across providers. A control that exists only in one cloud does not automatically translate into equivalent behaviour in another cloud, even when the business objective sounds the same.
Practical implication: Map each control objective to the provider-native mechanism that can enforce it in every cloud where the workload lives.
Why identity context changes cloud enforcement decisions
Identity is not a separate layer in multi-cloud governance. It determines what a workload, service account or operator can reach, which means identity context should shape perimeter, segmentation and baseline controls together. Tools that map identity to resources can expose toxic combinations, but the harder problem is carrying that identity context into the policy decision itself. Without that bridge, teams can find overprivilege without turning it into a blocked path or a tighter boundary.
Practical implication: Use identity context to drive policy scope, not just to label findings after the fact.
NHI Mgmt Group analysis
Multi-cloud enforcement is the control layer that converts discovery into actual risk reduction. Visibility tools can rank exposure, but they do not by themselves change which actions a cloud will allow. The decisive question is whether the policy layer in each provider can hold the same intent after configuration drift, account sprawl and cross-cloud exceptions. Practitioners should treat enforcement as the point where security design becomes real.
Identity-aware cloud governance: the article reinforces that cloud security decisions increasingly hinge on who or what can act, not just on where assets sit. That matters for service accounts, machine identities and operators because cloud policy often fails when identity context is bolted on after the control is defined. Multi-cloud identity is the missing bridge between visibility and consistent enforcement.
Runtime findings only matter when they feed policy selection. A workload alert on its own can show compromise, but the broader governance value comes from using that signal to tighten the boundary before the same pattern is redeployed elsewhere. That shifts cloud security from incident triage toward control design. The practitioner takeaway is to connect detection outputs to the controls that will actually prevent recurrence.
Stack fit is the real buying criterion, not cloud coverage. A tool can span several providers and still be weak if it only solves one layer of the stack. The more useful test is whether a platform supports the gap you need to close now, whether that is visibility, runtime, data security or enforcement. Teams that skip that distinction often buy overlap instead of coverage.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
- Read next: Multi-Cloud Identity Guide
What this signals
Control drift is the hidden failure mode in multi-cloud programmes. A policy that is correct at deploy time can become ineffective after unrelated changes, which means the real question is whether enforcement is revalidated continuously across every provider. That makes cloud governance a state-management problem as much as a design problem.
Identity-aware perimeter design will matter more than broad cloud coverage. As multi-cloud estates expand, the control question moves toward who can reach what, under which cloud-specific policy, and whether those answers remain true after change. Programs that cannot tie identity context to enforcement will keep discovering exposure after the fact instead of preventing it.
Enforcement consistency is the emerging multi-cloud discipline. The operational advantage will go to teams that can prove the same intent is still active after drift, not to teams with the longest list of connected accounts. That is where cloud security, identity governance and workload protection start to converge in practice.
For practitioners
- Define the control layer you are missing first Separate visibility gaps from enforcement gaps before selecting a platform, then choose the tool class that closes the specific control failure you have identified.
- Map identity context into cloud policy design Track which service accounts, workloads and human operators can reach each cloud resource, then use that mapping to shape perimeter and segmentation controls.
- Check whether policy still holds after drift Revalidate cloud policy state after account changes, resource moves and configuration updates so a one-time decision does not become stale in production. See the Cloud Security Guide.
- Use runtime alerts to refine prevention rules Feed workload detections, such as reverse shells or container escapes, back into the policy set that governs the same environment.
Key takeaways
- Multi-cloud security breaks into distinct layers, and visibility alone does not stop risky actions from recurring.
- Identity context matters because it shapes what perimeter and segmentation controls should actually block.
- The practical test for any tool is whether it changes enforcement in the provider, not just the dashboard view.
Related NHI Mgmt Group resources: Cloud Security Guide · Multi-Cloud Identity Guide · Cloud Access Key Leak Playbook
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CSA Cloud Controls Matrix and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity and entitlement scope determine whether multi-cloud policy can be enforced consistently. |
| PR.PS-02 — Identity Management, Authentication and Access Enforcement | The article centers on controls that enforce access decisions across cloud environments. | |
| Recommendation — Map cloud permissions to PR.AA-05 and verify that entitlements match the intended enforcement boundary. Apply PR.PS-02 to ensure cloud access enforcement remains consistent as environments change. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Multi-cloud enforcement depends on identity controls across providers and connected accounts. |
| Recommendation — Use the CCM IAM domain to align cross-cloud identity controls with the policy layer that actually enforces them. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service accounts and cloud identities are part of the enforcement problem the article highlights. |
| Recommendation — Use CIS-5 to govern cloud accounts and revoke access paths that no longer match the intended perimeter. | ||
| MITRE ATT&CK | TA0007;TA0008 — Discovery; Lateral Movement | Multi-cloud exposure and identity paths create the conditions attackers use for discovery and movement. |
| Recommendation — Map cloud exposure paths to ATT&CK discovery and lateral movement techniques and hunt for cross-account traversal. | ||
Key terms
- Multicloud Security: Multicloud security is the practice of protecting data, identities, applications, and infrastructure across two or more cloud platforms. It requires consistent controls for access, configuration, monitoring, encryption, and incident response across different providers, while accounting for shared responsibility, workload mobility, and identity sprawl in distributed environments.
- CNAPP: Cloud-Native Application Protection Platform is an integration model that combines posture, entitlement, workload, data, and runtime signals in one view. Its value depends on the quality of the underlying governance layers, not on correlation alone.
- DSPM: Data Security Posture Management is the discipline of finding, classifying, and protecting sensitive data across storage systems and workflows. In AI environments, DSPM helps teams understand what data exists, where it lives, and whether AI systems can access it appropriately.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It gives practitioners a consistent way to connect identity controls to cloud and access decisions.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org