83% of AWS Accounts Have an IAM Policy That Allows Privilege Escalation

Quick Answer: Intruder's 2026 Cloud Security Index, based on 3,000 organisations, found IAM policies that allow privilege escalation in 83% of AWS accounts and weak IAM controls in 97%. Companies with 1,000 to 5,000 employees took the longest to fix cloud issues, 35 days on average. An independent cloud security assessment finds these paths, validates them by hand and gives your auditor signed evidence of what was tested.

A cloud breach does not always need a clever exploit. Sometimes it needs one identity that can do more than it should, and a way to reach it. In Intruder's 2026 data, the first half of that combination is not an edge case. It is present in most of the AWS accounts analysed.

The 2026 Cloud Security Index measured how often common misconfigurations appear in real AWS, Azure and Google Cloud accounts. Intruder published it in August 2026, based on anonymised data from 3,000 of its own customers, from small businesses to large enterprises, collected over 12 months ending in July 2026. Findings are grouped into six categories: weak IAM controls, missing logging and alerting, misconfigured services, permissive firewalls, exposed services and weak encryption.

One caveat before the numbers. Intruder sells cloud scanning, and the sample is its own customer base. That is a real limitation, and it also means these are organisations that already scan. Companies that never look are unlikely to be in better shape.

On AWS, the four most common issues were:

Further down the AWS top ten, 71% of accounts had IAM policies attached directly to users and 71% had IAM access keys that were not rotated.

Azure looked different. Its top three issues were all storage account settings (61% to 67% of accounts), followed by Entra users without MFA (55%). Google Cloud had the lowest misconfiguration rates overall, with exposed services in 8% of accounts against 76% on AWS, but IAM issues dominated its top four, with more than three-quarters of accounts missing OS Login controls.

AWS IAM privilege escalation means an identity in your account holds a permission that lets it give itself, or something it controls, more permissions than it was meant to have.

The classic examples are not exotic. A deployment role that can create a new version of an IAM policy can rewrite its own policy to allow every action on every resource. A user who can pass a role to a compute service and launch that service can run code as the more powerful role. A CI token that can attach policies can attach AdministratorAccess to itself. Each of these looks reasonable in the ticket where it was granted, usually during setup, usually to make something work quickly.

The risk is in what happens next. If that identity's credentials leak, through a repository, a laptop, a CI log or a compromised dependency, the attacker does not start with limited access. They start one API call away from owning the account.

This is also why privilege escalation is hard to spot by reading policies one at a time. The dangerous combination is often two permissions that are each harmless alone, held by the same identity.

Midmarket companies take longest because they run enterprise-scale cloud estates without enterprise-scale security teams. Intruder's figures by company size show the gap clearly.

Weak IAM controls affected 87% of SMEs (1 to 250 employees), 95% of midmarket organisations (250 to 10,000) and 98% of large enterprises. Remediation is where the difference opens. The smallest organisations fixed cloud issues within 7 to 16 days. Remediation times rose through the 1,000 to 5,000 employee range, peaking at 35 days, and organisations with more than 10,000 employees brought them back down to about 10 days.

Intruder's own explanation is that midmarket teams manage enterprise-level cloud complexity without the dedicated resources to match. In practice that often looks like a company that has grown into several AWS accounts, a second cloud for one product, and a handful of people who own "infrastructure" alongside everything else. Nobody's job description includes reviewing every IAM policy against every other one.

A 35-day average also hides the long tail. The finding that matters is usually not the one fixed in a week. It is the one that sits in the backlog because nobody is sure who owns the role.

No. According to the index, the top misconfigurations on AWS, Azure and Google Cloud have almost no overlap, which is the finding that should change how multi-cloud teams plan.

Intruder notes that more than two-thirds of organisations now run multi-cloud environments. Each provider brings its own terminology, its own settings and its own remediation steps for what is conceptually the same risk. A team that has hardened AWS well has not, by doing so, fixed the Azure storage accounts or the Google Cloud OS Login gaps.

In practice this means cloud security is assessed provider by provider. A single "cloud policy" covers governance. It does not tell an engineer which Azure setting maps to which AWS one.

If your infrastructure code is generated or assisted by AI, the problem compounds. We looked at how AI-written Terraform and Kubernetes configs fail security checks in an earlier piece. The misconfiguration often starts in the template and gets copied into every account built from it.

A Cloud Security Posture Management tool catches configuration drift continuously, but it does not validate exploitability, test your external perimeter or produce evidence an auditor treats as independent testing.

Tools such as Wiz, Prisma Cloud or Orca monitor your cloud configuration against benchmark rules and flag drift as it happens. If you can afford one and someone acts on its alerts, it is genuinely useful. Three things sit outside what the subscription gives you:

Many teams run both: continuous monitoring for drift, and a periodic, manually validated assessment as the checkpoint an auditor recognises.

A cloud security assessment checks two layers your web application test does not: the external network perimeter and the cloud configuration your application runs on.

It starts with asset discovery, because many teams do not have a complete list of their own public IPs, subdomains and hosts. Not knowing the footprint is a common reason to run the assessment, not a barrier to starting it.

From there, the work splits in two. On the network side, testing follows NIST SP 800-115: reconnaissance, service enumeration and manual validation of exposed services, including management ports and perimeter services like mail, DNS and VPN. On the cloud side, an AWS, Azure or Google Cloud configuration review runs against the CIS Benchmark for that provider: IAM policies, storage permissions, network exposure, logging and encryption.

Two practical details tend to surprise people. Cloud providers publish their own security testing policies, and some activities need prior notification even when you are testing your own environment, so that check happens during scoping. And if your infrastructure sits behind Cloudflare or another CDN, the useful question is whether your origin IP can be found through DNS history, exposed subdomains or mail records. A WAF in front of a leaky origin is a different risk from a WAF in front of a hidden one.

The report scores every finding with CVSS v3.1 and comes with a prioritised remediation plan. The included retest then confirms the critical and high fixes actually closed. For a misconfigured IAM role, that confirmation is often the most valuable part, because "we changed the policy" and "the escalation path is gone" are not always the same thing.

One honest boundary: this is a security assessment, not a full penetration test, and it does not cover internal networks or Active Directory attack paths. Those are scoped separately.

A cloud security assessment supports ISO 27001, GDPR, NIS2 and vendor questionnaire requirements that ask for testing beyond the application layer:

The 83% figure is not a prediction about your account. It is a reason to stop assuming. One assessment tells you whether you are in the majority, and the retest tells you when you are not.