In July 2019, a former AWS employee exploited a misconfigured ModSecurity WAF on an EC2 instance to reach the instance metadata service, pulled temporary IAM credentials the WAF's role had no business holding, and used them to pull data from more than 700 Amazon S3 buckets belonging to Capital One — 106 million customer records in one incident. The root cause was not a single exotic bug; it was an overly permissive per-workload identity combined with a metadata service (IMDSv1) that handed out credentials to anything that could ask. That breach is directly credited with accelerating industry-wide adoption of IMDSv2, which requires a session token bound to the request before it releases credentials. It's also a clean illustration of why multi cloud security gets harder, not easier, once an organization runs workloads across AWS, Azure, and GCP simultaneously: each provider has its own identity model, its own network primitives, and its own policy language, and gaps between them are where attackers live. This post lays out three foundational controls — unified identity, network segmentation, and policy-as-code — that close those gaps, and grounds each in a real standard, breach, or dataset rather than vendor marketing.
Why does identity fragmentation matter more in multi-cloud than single-cloud environments?
Identity fragmentation matters more in multi-cloud because every provider issues its own credentials, on its own lifecycle, with its own blast radius, and none of them natively know about the others. AWS IAM roles, Azure AD (Entra ID) service principals, and GCP service accounts are three separate trust stores; a security team enforcing "no long-lived static credentials" has to implement that rule three times, in three different consoles or IaC templates, and verify it three separate ways. Verizon's 2024 Data Breach Investigations Report found that compromised or stolen credentials were the initial access vector in roughly 38% of breaches analyzed — more than any other single category, including exploited vulnerabilities and phishing. Multiplying identity systems multiplies the places a static, long-lived secret can leak: a Terraform state file, a CI/CD variable, a developer's laptop. Federating identity through a single trust broker — using workload identity federation so a workload authenticates once and receives short-lived, scoped tokens per cloud — collapses three credential lifecycles into one policy to audit, rather than three to reconcile after the fact.
What does zero trust actually require for cross-cloud workload access?
Zero trust, as formally defined by NIST Special Publication 800-207 (published August 2020), requires that no request is trusted by default based on network location — every access decision is made per-session, based on the identity of the requester, the state of the device, and the sensitivity of the resource, regardless of whether the request originates inside or outside a traditional perimeter. NIST extended that model specifically for multi-cloud in SP 800-207A, "A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments," which addresses how policy enforcement points should authorize service-to-service calls when those services live in different cloud accounts and even different providers. The practical requirement is a policy enforcement layer that sits above AWS security groups, Azure NSGs, and GCP firewall rules individually, evaluating identity and context rather than only source IP or VPC membership. Without that layer, a workload's effective trust boundary is whatever the weakest of the three providers' native controls allows — which is exactly the gap the Capital One SSRF path exploited inside a single cloud, and which repeats at every additional provider boundary.
How should network segmentation work when workloads span three different providers?
Network segmentation across three providers should be designed around workload identity and data sensitivity rather than around each provider's native network topology, because AWS VPCs, Azure VNets, and GCP VPC networks do not share an addressing or peering model and will never line up cleanly. The practical pattern is to treat each cloud's network as an enforcement boundary for a common, centrally defined segmentation policy — for example, "payment-processing workloads may only receive inbound traffic from the API gateway tier, on this port, over mTLS" — expressed once and translated into AWS security groups, Azure NSGs, and GCP firewall rules by tooling, rather than hand-written three times and inevitably drifting apart. Service mesh technologies (mTLS-based sidecar proxies) extend this further by enforcing segmentation at the workload level instead of the subnet level, so a compromised pod or instance in one segment cannot reach a database tier in another even if the underlying cloud network path is technically open. The goal mirrors the lesson from Capital One: a single overly broad allow rule, IAM role, or route table entry can undo segmentation that looks correct on paper in every other respect.
Why can't AWS IAM, Azure RBAC, and GCP IAM be governed with one native tool?
They can't be governed with one native tool because each provider's policy language is purpose-built for its own resource model and has no interoperability with the others: AWS uses IAM policies and Service Control Policies (SCPs) scoped to accounts and organizations, Azure uses role-based access control (RBAC) plus Azure Policy scoped to management groups and subscriptions, and GCP uses IAM bindings plus Organization Policy scoped to projects and folders. A rule written as an AWS SCP has no equivalent syntax in Azure Policy, and neither compiles to a GCP Organization Policy constraint — there is no shared grammar. This fragmentation is the direct, well-documented rationale behind policy-as-code frameworks such as Open Policy Agent (OPA), which uses the Rego language to express a guardrail like "no publicly readable storage buckets" once, then evaluates it against AWS S3, Azure Blob Storage, and GCP Cloud Storage configurations independently through provider-specific input data. HashiCorp Sentinel takes the same approach inside Terraform runs, blocking a plan that would create a non-compliant resource in any provider before it applies. The point of policy-as-code is not a nicer syntax — it's a single, version-controlled, testable source of truth that no longer depends on three security teams manually keeping three consoles in sync.
Where does this fit alongside software supply chain security?
Cloud infrastructure security — identity federation, segmentation, and policy-as-code across AWS, Azure, and GCP — governs how workloads authenticate and communicate once they're running. It is a distinct control layer from software supply chain security, which governs what code and dependencies go into those workloads before they ever run. Safeguard's own focus sits in the latter category: SBOM generation, software composition analysis, and reachability-aware vulnerability findings that tell a team whether a CVE in a transitive dependency is actually exploitable in their deployed code. A policy-as-code gate that blocks a public S3 bucket and a policy gate that blocks a build containing a critical, reachable CVE are complementary controls, not substitutes — an organization needs both a well-segmented, identity-governed cloud estate and a verified software supply chain feeding into it, because a hardened network perimeter does nothing to stop a vulnerable dependency shipped inside it.
What's the practical first step for a team running all three clouds today?
The practical first step is inventory, not tooling: map every long-lived credential, every wide-open security group or NSG, and every place a provider-native policy exists without an equivalent in the other two clouds, before introducing a federation layer or a policy-as-code framework on top of an unmapped estate. NIST 800-207A's model assumes an organization can enumerate its workloads and their required communication paths; skipping that step and deploying OPA or a service mesh onto an undocumented environment tends to produce policy that's either too permissive to catch real gaps or too strict to deploy without breaking production. Teams that start by federating identity for their highest-privilege workloads — the ones equivalent to that EC2 instance's IAM role in 2019 — get the fastest reduction in blast radius per hour invested, before expanding unified policy to the rest of the estate. Multi cloud security matures the same way it degrades: one identity boundary at a time.