AWS, Azure, and GCP Fail Differently: Inside a 3,000-Organization Cloud Misconfiguration Study

76% of AWS accounts had at least one exposed service in the last twelve months. Azure: 64%. Google Cloud: 8%. Permissive firewalls hit 83% of AWS accounts and only 34% of Google Cloud accounts. If you're running workloads across all three — and most mid-to-large infrastructure teams I know are, whether by design or by acquisition — you are not managing one risk profile. You're managing three, and they do not average out.

That data comes from Intruder's 2026 Cloud Security Index, published via the Cloud Security Alliance, which pulled misconfiguration findings from 3,000 organizations across AWS, Azure, and Google Cloud over the twelve months to July 2026. I've lost count of the nights I've had to reconcile findings like this across a multi-cloud estate — usually well past midnight, usually after an auditor or a pen tester found something first — so a dataset this size, broken down by provider and by category, is worth sitting with properly instead of skimming the press release.

Where the Numbers Come From

Misconfiguration isn't a theoretical risk category. CSA ranks it among the top threats to cloud computing, and CISA's Binding Operational Directive 25-01 now mandates baseline secure-configuration practices for US federal agencies specifically because it's the most common way cloud environments get breached — not zero-days, not exotic exploits, just a setting nobody got around to fixing.

Intruder's dataset is large enough to be interesting: 3,000 organizations, all three hyperscalers, a full year of scan data. What makes it more useful than the usual vendor-neutral "secure your cloud" advisory is that it doesn't pretend the three platforms fail the same way. They don't. Each one has a distinct fingerprint, and that fingerprint tells you a lot about how each vendor designed its defaults.

AWS: The Burden Is on You

These are the misconfigurations that hit the highest percentage of AWS accounts in the dataset:

Misconfiguration	% of AWS accounts affected
S3 does not enforce HTTPS	87%
Permissive ingress to sensitive ports (via ACL)	84%
Overly permissive network ACL	83%
IAM policy allows privilege escalation	83%
VPC endpoint not enabled for EC2	82%
Block Public Access not enabled (S3, account level)	81%
VPC subnet auto-assigns public IP	72%
Root access not centrally managed	72%
IAM policy attached directly to user	71%
IAM access key not rotated	71%

Four of AWS's top ten are IAM issues, and that's the pattern that should worry you more than any single line item. IAM Policy Allows Privilege Escalation sits at 83% — a policy that looks scoped and reasonable in the console but, combined with one or two other permissions, lets a principal grant itself more access than it started with. AWS's IAM permission model is genuinely one of the most powerful and most misunderstood systems in cloud infrastructure, and "looks safe in isolation" is exactly the failure mode it's prone to.

This isn't hypothetical. In a recent incident covered by Dark Reading, an attacker went from a single set of exposed credentials to administrative privileges in under ten minutes, ultimately compromising 19 AWS principals. Ten minutes is faster than most SOC alert triage, let alone a manual investigation. That's the practical cost of a permissive IAM policy sitting quietly in an account nobody's audited since it was provisioned.

The rest of AWS's list is firewall and network ACL sprawl — the kind of thing that doesn't hurt you today but quietly widens the blast radius the next time someone spins up a dev environment without thinking about it. AWS's shared-responsibility model puts more of the secure-configuration burden on the customer than the other two providers, and this list is what that burden looks like in aggregate, across 3,000 real environments.

Azure: Storage and Identity, Over and Over

Misconfiguration	% of Azure accounts affected
Storage Account key rotation not enabled	67%
Storage Account access keys enabled	66%
Storage Account public network access enabled	61%
Entra user without MFA	55%
Trusted Launch not enabled	45%
Key Vault secret never expires	41%
Disable public access not enabled (Key Vault)	41%
Key Vault not recoverable	38%
Storage Blob public access enabled	36%
Key Vault using legacy access control model	34%

Azure's top three all land on Storage Accounts, within six points of each other (61–67%). That tight clustering tells its own story: where a team hasn't hardened storage, they usually haven't hardened any of it — key rotation, access keys, and public network access tend to be missing together, not independently. Storage Accounts routinely hold customer PII, and a public, key-based, unrotated storage endpoint is about as close to "please breach me" as cloud misconfiguration gets.

The other number that stands out is Entra User Without MFA at 55%. More than half. That one matters beyond the Azure tenant itself, because Entra ID (formerly Azure AD) is very often the identity backbone for Microsoft 365, a pile of third-party SaaS via federation, and on-prem systems through hybrid join. The 2024 Midnight Blizzard breach of Microsoft's own corporate network started with a password spray against a legacy, non-production test account that didn't have MFA enabled. Nation-state actor, and the entry point was the kind of dusty test account that exists in nearly every Entra tenant I've ever audited.

Google Cloud: Better Defaults, Same Old IAM Debt

Misconfiguration	% of GCP accounts affected
OS Login MFA not enabled	77%
OS Login not enabled	76%
Unused service account	75%
Overly permissive service account	53%
Permissive ingress to sensitive ports	34%
Service account key not rotated	31%
Default network in use	29%
Service account unused key	29%
Block project-wide SSH keys not enabled	26%
Shielded VM not enabled	21%

Don't read Google Cloud's much lower headline exposure numbers as "GCP shops are just better at security." Some of that is true, but a lot of it is architecture: Google ships a "Shared Fate" model with meaningfully more secure defaults out of the box — private-by-default networking, stricter default service account scoping in newer projects — versus independent comparisons that consistently find AWS leaves more configuration decisions, and therefore more room for error, to the customer.

But GCP's own top four are still IAM problems wearing a different hat: OS Login without MFA, OS Login not enabled at all (meaning teams are still using static SSH keys embedded in metadata instead of IAM-governed, auditable, revocable logins), and unused or over-scoped service accounts sitting in three out of every four accounts. Service accounts are non-human identities with no MFA prompt to fail and no employee to offboard — they just accumulate, unrotated and over-permissioned, until someone finds one during an incident.

The Category Breakdown

Intruder grouped the individual checks into six categories and compared prevalence across all three providers directly. This table is the single most useful thing in the whole study, because it's the one place you can actually compare apples to apples:

Category	AWS	Azure	Google Cloud
Weak IAM controls	97%	90%	87%
Missing logging and alerting	98%	80%	82%
Misconfigured services	68%	80%	37%
Permissive firewalls	83%	45%	34%
Exposed services	76%	64%	8%
Weak encryption	49%	35%	8%

Two things jump out. First, weak IAM and missing logging are near-universal — 80% to 98% of accounts, regardless of provider. Nobody gets a pass here. Second, everything else diverges hard: AWS leads five of six categories, Google Cloud has the lowest prevalence in four, and Azure is the outlier leader on exactly one category — misconfigured services, at 80% versus 68% on AWS and GCP. There is no single "most secure cloud." There's a most-exposed-by-default cloud (AWS) and a best-defaults cloud (GCP), and Azure sitting in between with its own specific failure mode around service configuration.

How This Actually Plays Out in an Incident

It's worth walking through why a single IAM misconfiguration turns into a full account compromise so fast, because the AWS privilege-escalation incident above isn't unusual — it's the standard chain:

Initial exposure — credentials leak via a committed .env file, a misconfigured CI pipeline, or a phished developer laptop. This step rarely involves the cloud provider at all.
Enumeration — the attacker runs standard IAM enumeration (iam:ListPolicies, iam:GetPolicyVersion, sts:GetCallerIdentity) to map what the compromised principal can already do.
Privilege escalation — a policy that looked reasonable — say, iam:PassRole combined with the ability to launch a Lambda or EC2 instance — lets the attacker assume a role with far more access than the original credential had.
Lateral movement across principals — with elevated IAM access, the attacker pivots through cross-account trust relationships and assumed roles, which is how a single compromised credential turned into 19 compromised principals in the Dark Reading case.
Persistence and exfiltration — new access keys, new IAM users, or a backdoored trust policy get planted so the attacker survives credential rotation, and data movement begins.

Every one of those steps after the first is enabled by exactly the kind of finding sitting in AWS's 83% IAM-privilege-escalation number. It's not an exotic attack. It's the default outcome of not auditing IAM policies for combinable permissions.

Size Doesn't Save You — It Changes the Shape of the Problem

For most misconfiguration types, prevalence drops as organizations get bigger: fewer permissive firewalls, fewer exposed services, less weak encryption, as you'd expect from more mature, better-resourced teams. IAM is the exception, and it's a significant one. Weak IAM controls affected 87% of SMEs (1–250 employees), climbing to 95% of midmarket organizations (250–10K), and 98% of large enterprises (10K–100K+ employees).

That's not a maturity failure — it's a complexity failure. More people means more roles, more one-off permission grants, more service accounts nobody remembers creating, more cross-team trust relationships. A single overprivileged identity is often all it takes to bypass every other control an enterprise security team has spent years hardening. I've seen this firsthand: organizations with genuinely strong network segmentation and mature patch cycles still get flagged hard on IAM sprawl, because nobody owns the unglamorous job of periodically re-reviewing who can do what.

Remediation speed follows an equally counterintuitive curve. Smaller organizations fix issues fastest — 7 to 16 days. Remediation slows dramatically in the 1,000–5,000 employee range, peaking at 35 days, before improving again at 10,000+ employees, back down to around 10 days. The midmarket is stuck managing enterprise-scale cloud complexity without enterprise-scale security headcount or process — Intruder notes this mirrors what they found in their own 2026 Attack Surface Management Index. If your organization is in that 1,000–5,000 band, this study is describing you specifically, and it's worth taking personally.

My Take

What I find most useful about this data isn't any single percentage — it's that it finally gives infrastructure teams permission to stop treating "cloud security" as one undifferentiated discipline. I've sat in too many planning meetings where a single checklist gets applied uniformly across AWS, Azure, and GCP estates because it's easier to standardize than to specialize. That checklist ends up either too loose for AWS or wasting effort re-verifying things GCP already defaults correctly.

The AWS numbers don't surprise me at all. I've onboarded more AWS accounts than I can count, and the platform's flexibility is exactly what makes it dangerous in inexperienced hands — there's no single "correct" way to configure a VPC, an S3 bucket policy, or an IAM role, which means teams under deadline pressure reach for whatever works rather than what's scoped correctly. AWS gives you every rope you need, including the ones to hang yourself with.

Azure's storage-account clustering is the one I've personally chased down more than once — usually during an M&A integration, where a subsidiary's storage account was provisioned years earlier by someone who's long since left, keys never rotated, public network access left on because "it was easier for the vendor integration." Entra MFA gaps are almost always legacy or service accounts too, exactly like the Midnight Blizzard entry point. Those accounts are invisible until an audit or an incident forces someone to look.

And Google Cloud's lower numbers genuinely reflect better architectural decisions — Shared Fate is a real design philosophy, not just marketing — but I'd push back on reading it as "GCP is the safe choice." Three out of four GCP accounts still have unused service accounts sitting around, and OS Login without MFA at 77% means most GCP shops are one leaked service-account key away from the same outcome as everyone else. Better defaults buy you a smaller initial attack surface. They don't buy you ongoing hygiene.

The category table is the real finding here: weak IAM and missing logging sit at 80–98% on every provider. That's the actual headline, and it's the one number in this whole report that should worry every reader equally, regardless of which cloud they're standing on.

What You Should Do Right Now

Generic "audit your cloud" advice is useless. Here's what's actually worth doing this week, broken out by what the data says matters most on each platform:

If you run AWS

Run aws iam get-account-authorization-details (or use IAM Access Analyzer) and specifically hunt for policies granting iam:PassRole, iam:CreatePolicyVersion, or sts:AssumeRole combined with compute-launch permissions — that combination is the privilege-escalation path in the Dark Reading incident.
Enforce s3:x-amz-server-side-encryption and a bucket policy denying non-TLS requests (aws:SecureTransport false) at the Organization level via SCP, not per-bucket.
Turn on S3 Block Public Access at the account level, not just per-bucket, and centralize root account access through IAM Identity Center.

If you run Azure

Inventory every Storage Account and check three things together: key rotation policy, public network access, and whether Azure AD (Entra) authorization is enforced instead of shared access keys. Fix all three at once — the data shows they travel together.
Run an Entra sign-in log query filtered for accounts without MFA, sorted by last sign-in. The legacy test accounts nobody remembers are the ones that matter most, per Midnight Blizzard.
Move Key Vaults off the legacy access-control model to Azure RBAC, and set expiration dates on every secret going forward.

If you run Google Cloud

Enforce OS Login with 2FA org-wide via an Organization Policy constraint, and disable project-wide SSH keys in metadata.
Run gcloud iam service-accounts list across every project and cross-reference against actual usage in Cloud Logging — kill anything unused, and rotate or eliminate long-lived keys on the rest.
Don't assume secure defaults mean secure state — audit as if you were on AWS, because the gap closes fast once service-account sprawl sets in.

If you run more than one

Stop applying one checklist across all three. Build provider-specific baselines, but track them against a single common risk taxonomy — the six-category breakdown in this study (IAM, logging, service config, firewalls, exposure, encryption) is a reasonable starting structure.
Prioritize IAM review and logging coverage first, everywhere, since those are the two categories where no provider's defaults save you.
If your org is in the 1,000–5,000 employee range, budget specifically for cloud security headcount or tooling now — the data says you're statistically the slowest to remediate what you find, and that gap doesn't close on its own.

This article was researched and drafted with AI assistance as part of an experiment in building a faster tech-writing workflow, then reviewed and edited before publishing.

Primary source: 2026 Cloud Security Index: How Risk Differs Across AWS, Azure, and Google Cloud — Cloud Security Alliance, September 4, 2026 (originally published by Intruder)

Secondary sources: 8 Minutes to Full Access: How an AWS Environment Was Breached — Dark Reading; Midnight Blizzard: Guidance for Responders on Nation-State Attack — Microsoft Security Blog; BOD 25-01: Implementing Secure Practices for Cloud Services — CISA