Security teams should treat each service as a policy enforcement point and verify every request at the point of access. Use identity and context based controls, apply least privilege, and prefer direct access paths over cloud to cloud tunneling. That approach reduces lateral movement, avoids unnecessary latency, and keeps enforcement aligned to the actual application boundary.
Why Zero Trust in Multi-Cloud Fails When Clouds Are Treated as the Trust Boundary
zero trust only works in multi-cloud when the application and service are the enforcement boundary, not the cloud network itself. If teams rely on cloud-to-cloud tunnels, they often recreate implicit trust between environments, which weakens policy precision and makes lateral movement easier. Direct, policy-driven access keeps verification aligned to the request rather than the path.
That distinction matters because a tunnel is usually a connectivity shortcut, not a security decision. Once it exists, it can become a broad transitive trust channel that is difficult to reason about across providers, especially when identity, context, and workload posture differ from one cloud to another.
Teams implementing this pattern should anchor the design to NIST SP 800-207 Zero Trust Architecture and its core idea that access decisions belong at policy enforcement points, not inside blanket network reachability.
What to Build Instead of Cloud-to-Cloud Tunnels
The practical alternative is to expose services through explicit access policies, then evaluate each request using identity, device or workload context, and the requested action. This supports least privilege more cleanly than network-level bridging because permission is tied to a specific service and operation, not to the fact that two clouds can reach each other.
In multi-cloud environments, this usually means keeping services addressable through direct paths, with strong authentication, authorization, and inspection at each boundary. When workloads need to talk across cloud providers, use the narrowest possible trust relationship and avoid making one cloud an automatic extension of another.
For workload-to-workload trust, Guide to SPIFFE and SPIRE is a useful model because it shows how workload identity and attestation can replace broad network trust with cryptographic identity.
Cloud control frameworks also reinforce the same pattern. The CSA Cloud Controls Matrix is helpful for mapping the access-control and cloud-governance pieces that need to stay consistent across providers, while ISO/IEC 27001:2022 Information Security Management supports the broader control discipline around access, privilege, and cloud security.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Directly supports least-privilege access decisions for service requests. |
| Recommendation — Enforce least-privilege authorizations at each service boundary. | ||
| NIST Zero Trust (SP 800-207) | PEP — Policy Enforcement Point | Zero trust access decisions belong at the enforcement point, not the tunnel. |
| least privilege — Least Privilege Access | Cross-cloud paths should not broaden trust beyond required service access. | |
| Recommendation — Place authorization decisions at policy enforcement points for every request. Scope cross-cloud access to the minimum required permissions. | ||
| CIS Controls v8 | 6 — Access Control Management | Multi-cloud zero trust depends on controlling who and what can reach each service. |
| 8 — Audit Log Management | Request-level verification needs logs to validate enforcement and detect misuse. | |
| Recommendation — Review and restrict cross-cloud access paths to approved business needs. Log cross-cloud authorization decisions and service access events. | ||
Practitioner Guidance
What to prioritise: define the service boundary first, then decide what identity and context must be present before a request is allowed. If a cloud-to-cloud tunnel is currently doing the work of policy, replace it with explicit authorization logic and verify that every cross-cloud call still has a clear business owner and approval path.
What to verify: check that no shared network path grants more reach than the application actually needs, and confirm that service accounts, API keys, and workload credentials are scoped narrowly enough to survive a compromise without opening adjacent environments. If the control only works because the tunnel is “private,” it is not zero trust, it is hidden trust.
Practitioner takeaway: the goal is not to eliminate inter-cloud communication, it is to remove implicit trust from inter-cloud communication so that every request is independently authorized at the service edge.
Related resources from NHI Mgmt Group
- How should security teams implement zero trust CNAPP in hybrid and multi-cloud environments without slowing delivery?
- How should security teams implement zero trust IAM in cloud-native environments?
- How should security teams implement AI SIEM in multi-cloud environments without creating new visibility gaps?
- How should security teams implement an AI gateway in multi-cloud environments without creating new lock-in?
