Ask a platform engineer how many clouds their company runs, and the honest answer is rarely "one." A 2023 Flexera survey found 89% of enterprises operate across multiple public clouds, and the average organization now juggles workloads across roughly 2.6 public clouds plus private infrastructure. Each cloud arrived for a defensible reason — an acquisition that came with its own AWS account, a data team that standardized on GCP's BigQuery, a compliance requirement that pushed a workload to Azure Government. No single decision was wrong. But nobody added up the compounding cost.
That cost shows up as a security tax, not a single visible expense. It's the extra hour spent translating an IAM policy from AWS's ARN syntax to Azure's RBAC model. It's the container image that passed a scan in one registry and skipped it entirely in another. It's the on-call engineer pulling up three different consoles at 2 a.m. trying to figure out which cloud actually owns the compromised resource. This post breaks down where that tax gets paid and what closing the gap actually requires.
Why do 89% of enterprises now run multi-cloud, and why does that number keep climbing?
Because multi-cloud is rarely a strategy — it's an accumulation. Flexera's 2023 State of the Cloud report put multi-cloud adoption at 89% of enterprises, up from 76% just five years earlier, and the drivers are structural rather than deliberate: mergers inherit foreign cloud footprints, individual teams pick the platform with the best-fit managed service (Snowflake on AWS, Vertex AI on GCP, Cognitive Services on Azure), and procurement negotiates multi-cloud commitments to avoid vendor lock-in pricing leverage. None of these are security decisions, yet each one adds a distinct identity system, a distinct logging format, and a distinct set of default configurations that a security team now has to understand equally well. A company that started with "just AWS" in 2019 frequently finds itself running production workloads across three or four providers by 2024 without ever holding a meeting titled "let's go multi-cloud."
What does it actually cost engineering teams to secure three different IAM models?
It costs disproportionately more than securing three times one IAM model, because the systems don't compose — they conflict. AWS IAM, Azure RBAC, and Google Cloud IAM each use different primitives (policies vs. role assignments vs. bindings), different scoping hierarchies (accounts/OUs vs. management groups/subscriptions vs. organizations/folders/projects), and different defaults for what "least privilege" even means out of the box. A security engineer who can write a tight AWS permission boundary in fifteen minutes may need an hour to achieve equivalent restriction in Azure, simply because the mental model has to be rebuilt from scratch. In practice, this means teams either hire specialists per cloud — tripling headcount for the same coverage — or they let one team "own" IAM everywhere and watch policy quality degrade on the clouds that aren't their specialty. Neither option is cheap, and both show up as either budget line items or, worse, as the overly permissive service accounts that show up in nearly every cloud breach post-mortem.
How do container images become a blind spot across AWS, Azure, and GCP?
They become a blind spot because most scanning and admission control tooling was built cloud-first, not registry-agnostic, and coverage quietly drops at the seams. A container built in a GitHub Actions pipeline and pushed to Amazon ECR might pass through a well-tuned vulnerability scanner and an OPA-based admission policy before it ever reaches an EKS cluster. The same image, mirrored to Azure Container Registry for a disaster-recovery region or pulled by a partner team running AKS, frequently skips that same scanning step entirely — because the policy was written against ECR's event structure, not ACR's. Multiply that by GCP's Artifact Registry and a self-hosted Harbor instance for air-gapped environments, and a single vulnerable base image (say, an outdated python:3.9-slim with a known OpenSSL CVE) can be verified as remediated in one environment while running unpatched in three others, invisible to any single dashboard. Teams don't lack scanning tools; they lack scanning that follows the artifact everywhere it goes.
Why do misconfigurations multiply instead of average out across clouds?
Because each additional cloud adds its own default-open settings rather than diluting the risk of the others. A publicly readable S3 bucket, an Azure Storage container with anonymous access enabled, and a GCS bucket without uniform bucket-level access are three separate ways to leak the same category of data, and a team has to explicitly know and disable all three defaults — there's no shared control that fixes them at once. Palo Alto Networks' Unit 42 has repeatedly found misconfigured storage and identity settings among the top initial access vectors in cloud incidents, and the pattern holds across providers because the failure mode is structural: more platforms means more places for "we'll harden that later" to quietly become permanent. A team that spends a quarter locking down AWS Config rules to a solid baseline often discovers that Azure Policy and GCP Organization Policy were never given the same attention, not from negligence but because the hardening effort has to be repeated, tool by tool, cloud by cloud, with no shared muscle memory.
What happens when incident response spans multiple cloud consoles?
Response time stretches from minutes to hours because the first job during an incident becomes figuring out which cloud you're even looking at. A lateral-movement attempt that pivots from a compromised CI/CD credential in one cloud to a Kubernetes cluster in another requires correlating CloudTrail logs, Azure Activity Logs, and GCP Audit Logs — three different schemas, three different retention defaults, three different query languages — often stitched together manually in a spreadsheet or a hastily built Splunk query under pressure. IBM's Cost of a Data Breach research has consistently shown that breaches in hybrid and multi-cloud environments take longer to identify and contain than single-environment breaches, and the mechanism is exactly this: every additional log format and console is another translation step between "something happened" and "we know what happened." Teams that have practiced tabletop exercises against a single cloud often discover, mid-incident, that their runbook simply doesn't have a step for "now do this again in the other two consoles."
Is the answer to just standardize on one cloud?
No, and treating consolidation as the fix usually creates a new set of problems without solving the underlying one. Migrating off a cloud a business unit depends on for compliance, cost, or a specific managed service is often more expensive and riskier than managing the multi-cloud footprint well — Gartner has noted that forced cloud consolidation projects frequently stall or get abandoned once teams hit contractual, latency, or data-residency walls. The realistic goal isn't fewer clouds; it's a security layer that treats "which cloud" as a detail rather than a fork in the process. That means one policy definition that compiles down to IAM, RBAC, and IAM bindings correctly on each platform, one vulnerability view that tracks an image regardless of which registry it landed in, and one incident timeline that normalizes CloudTrail, Activity Logs, and Audit Logs into a shared format before a human has to read them.
How Safeguard Helps
Safeguard is built around the premise that the multi-cloud tax should be paid by tooling, not by engineers. Instead of asking teams to maintain separate scanning and policy configurations per cloud, Safeguard tracks container images and their dependencies across the full path — from the CI/CD pipeline that builds them, through every registry they're pushed or mirrored to (ECR, ACR, Artifact Registry, or self-hosted), to the clusters that actually run them. A vulnerability found in one location is immediately visible everywhere that image exists, closing the gap where the same artifact is "fixed" in one cloud and vulnerable in another.
On the policy side, Safeguard normalizes configuration and identity risk across AWS, Azure, and GCP into a single model, so a security team can define least-privilege intent once and see where each cloud's native controls fall short of it — rather than manually re-deriving equivalent policies in three different syntaxes. And because supply-chain provenance is tracked at the artifact level rather than the cloud-account level, incident response starts with "here is everywhere this compromised component exists" instead of three separate investigations that have to be reconciled after the fact.
The goal isn't to make multi-cloud simple — it's to stop making engineering teams pay, cloud by cloud, for complexity that a shared security layer should be absorbing instead.