# The Multi-Cloud Security Illusion: Why Your AWS Checklist Is Useless on Azure
Three thousand organizations. Three cloud providers. One uncomfortable finding: the security mistakes you make on AWS have almost nothing to do with the ones you'll make on Azure or Google Cloud.
That's the headline from Intruder's 2026 Cloud Security Index, and if you've spent any time trying to build a unified cloud security program, it should land like cold water. The report analyzed misconfiguration data across AWS, Azure, and GCP and found that risk profiles across the three major providers bear almost no resemblance to each other. Which means the multi-cloud security strategy most organizations are running — one framework, applied everywhere — is a polite fiction.
## Each Provider Fails on Its Own Terms
This isn't a story about cloud being insecure. It's a story about cloud being *specifically* insecure in ways that don't transfer.
AWS, Azure, and Google Cloud were built by different engineering cultures, with different default assumptions about who their customers are and what they'll configure. AWS was first to market and shows it — the platform's complexity is legendary, and its misconfiguration surface is enormous partly because it simply has more knobs. Azure grew into enterprise IT through Microsoft's existing relationships, which means its identity and access management integrations are both its strength and its most-abused attack surface. GCP was built by an engineering company for engineering companies, which created its own set of assumptions about defaults that don't always age well when the customer base diversifies.
When Intruder looked at what organizations actually get wrong across these platforms, the patterns diverged sharply by provider. That divergence is the whole story.
## The Checklist Problem
Security teams love checklists. They're auditable, they're delegatable, they create a paper trail. The CIS Benchmarks for cloud providers are well-regarded and widely used. The problem is how they get applied in practice.
A security engineer who is genuinely expert in AWS — who knows which S3 bucket policies bite, which IAM patterns lead to privilege escalation, which CloudTrail gaps leave you blind — does not automatically transfer that expertise to Azure. Azure's permission model is structurally different. Entra ID (formerly Azure AD) introduces identity complexity that has no direct AWS equivalent. The blast radius of a misconfigured Azure service principal looks nothing like a misconfigured AWS IAM role.
What happens in most organizations running multi-cloud? One of three things: they hire separate expertise for each provider (expensive, rare), they stretch their existing team thin across platforms (common, dangerous), or they apply a generic framework that isn't really native to any of the three (most common, false comfort).
The Intruder data suggests the third option is widespread. When misconfiguration patterns diverge sharply by provider across 3,000 organizations, you're not looking at random variation — you're looking at systematic gaps that suggest teams are consistently missing things on platforms they understand less well.
## Who This Actually Hurts
The organizations most exposed to this finding are not startups. Startups tend to pick one cloud and go deep. The multi-cloud problem is an enterprise problem, and it's usually the result of M&A activity, shadow IT that consolidated post-acquisition, or deliberate architectural decisions to avoid vendor lock-in.
That last category — the deliberate multi-cloud adopters — often have the best intentions and the worst security outcomes. The architectural reasoning is sound: diversify your dependencies, negotiate better pricing, keep optionality. The security reasoning doesn't follow. You've just multiplied your attack surface by the number of providers and divided your team's expertise by the same number.
There's also the tooling problem. Most security platforms claim multi-cloud visibility, and many deliver it in the narrow sense of connecting to all three APIs and pulling findings into a single pane. But aggregated visibility isn't the same as provider-native expertise. A CSPM tool that flags misconfigurations across all three clouds is genuinely useful; a security team that treats all three clouds as equivalent because the dashboard does is not.
## What Defenders Should Actually Do
The most useful reframe here is to stop thinking about cloud security as a unified discipline and start thinking about it as three adjacent specializations that share vocabulary but not technique.
In practice, that means a few things:
Audit your team's actual expertise, not their certifications. Cloud security certifications are a reasonable baseline, but the gap between someone who passed the AWS Security Specialty exam and someone who has spent two years responding to AWS incidents is enormous. Know which platforms your team is actually sharp on.
Build provider-specific runbooks. Your incident response documentation should branch by cloud provider. The questions you ask during an AWS identity incident are different from the questions you ask during an Azure identity incident. Generic playbooks create hesitation at exactly the wrong moment.
Treat misconfiguration data as provider-specific signal. If your CSPM is telling you about GCP misconfigurations, the people reviewing those findings should have GCP context, not just general cloud security awareness. Triaging a GCP finding without understanding GCP's resource hierarchy and IAM model is an exercise in false precision.
Prioritize depth over breadth in hiring. A team with two genuine AWS experts and one genuine Azure expert will outperform a team of five generalists in most incident scenarios. Breadth is a planning asset; depth is an operational one.
---
## HackWire Analysis
The Intruder report is valuable data, but the more important subtext is what it reveals about the state of cloud security maturity across the industry.
We've spent a decade telling organizations they need to get serious about cloud security. By most measures, they've responded — cloud security spending is up, CSPM adoption is widespread, and the market for cloud-native security tooling has consolidated around real products. And yet: 3,000 organizations analyzed, and the misconfiguration problem is sufficiently widespread and provider-specific to produce meaningfully different risk profiles across all three major platforms.
This is the gap between security investment and security outcomes that keeps showing up in breach post-mortems. Organizations buy the tools, build the teams, run the checklists — and still get compromised through misconfigurations that the tools flagged and no one fixed, or through gaps the checklist didn't cover because it was written for a different provider.
The pattern here isn't negligence. It's the structural difficulty of maintaining genuine expertise across platforms that each require years of operational experience to understand well. The organizations that will outperform on cloud security over the next three years aren't the ones with the biggest security budgets — they're the ones that are honest about where their expertise actually ends and build their programs around that honesty.
One thing the industry doesn't talk about enough: the multi-cloud sprawl problem gets worse every year because nobody builds *down* cloud complexity. Acquisitions add providers. Developers pick the platform that runs their preferred service. Shadow cloud usage is endemic. The complexity compounds while the security team headcount stays flat.
The 2026 Cloud Security Index is a useful annual artifact. The more useful question it raises is whether the organizations reading it will update their mental models or just add "review provider-specific misconfigurations" to the bottom of the checklist that already isn't working.
— HackWire Editorial
---
## Related Coverage