When an AWS environment gets breached, investigators almost never find a clever zero-day exploit or a sophisticated attack on infrastructure. What they find is a set of overly permissive IAM policies — roles and credentials that gave an attacker exactly what they needed to move laterally, escalate privileges, and exfiltrate data. The code wasn’t the problem. The permissions were.
This is the pattern that repeats across incident reports, post-mortems, and breach disclosures. AWS IAM security is the critical control plane for every resource in your account, and it is routinely under-managed, under-audited, and poorly understood — even at organizations that consider themselves security-conscious.
The Numbers Don’t Lie
The research is unambiguous on where cloud security failures originate.
In the cloud, credentials are IAM. When Verizon says 80% of breaches involve credential abuse, for AWS customers that means IAM roles, access keys, and trust policies. This is not abstract risk. It’s the most likely path an attacker will take through your environment.
Why AWS IAM Is So Hard to Get Right
AWS IAM is one of the most powerful access management systems ever built. That power is also what makes it genuinely difficult to manage at scale.
A non-trivial AWS environment has IAM everywhere:
- Lambda execution roles — each function has a role that determines what it can do. Functions often get overly broad roles because it’s the path of least resistance.
- EC2 instance profiles — attaching a role with
AdministratorAccessto an EC2 instance is a common shortcut that turns every compromised instance into a full account takeover. - S3 resource policies — bucket policies operate independently of IAM identity policies and can expose data to the public or to unintended AWS accounts.
- Cross-account trust relationships — as organizations grow, they create trust relationships between accounts that can persist long after the original use case is gone.
- Service-to-service permissions — modern architectures wire together dozens of services, each needing scoped permissions that are easy to get wrong.
The AWS documentation is comprehensive. The tooling is capable. But the surface area is enormous. IAM misconfiguration doesn’t require incompetence — it emerges naturally from the speed and complexity of building on AWS.
How It Gets Away From You
IAM debt rarely accumulates through a single bad decision. It accumulates the same way technical debt does: organically, incrementally, under pressure.
The startup phase. Speed matters more than perfection. A developer needs a Lambda to write to an S3 bucket and DynamoDB table, so they attach a managed policy with broad permissions to get it working. A staging environment gets an IAM user with admin rights “temporarily.” A third-party integration gets more access than it needs because the documentation says to use a certain policy and nobody has time to scope it down.
The growth phase. The team grows. Infra is replicated across environments. Roles get copied and modified. The original intent behind permissions gets lost. The developer who set up that admin IAM user is on a different team now. Nobody remembers why the Lambda role has s3:* on *.
Team expansion and vendor onboarding. New engineers inherit what exists and extend it. A SaaS security tool needs cross-account access to scan your environment — and gets broader permissions than required because the vendor’s onboarding docs are generic. A CI/CD pipeline gets programmatic credentials. Those credentials rotate infrequently, if ever.
At no point did anyone make a reckless decision. Each choice was reasonable in context. The result is an AWS access management posture that looks fine from the outside but carries real, exploitable risk.
What “Bad” Actually Looks Like
Here are three IAM states that appear in real AWS accounts at organizations of all sizes. None of them trigger a CloudTrail alarm. None of them are visibly broken. All of them represent material cloud identity risk.
Example 1: The Wildcard Action Role
A Lambda function created during a hackathon has an execution role with the following policy:
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}This role allows the function — and any attacker who compromises it — to read, write, delete, or modify every S3 object in the account, including backups, logs, and anything in buckets belonging to other workloads. The function itself only needs to write to one bucket prefix.
Example 2: The Zombie Role
An IAM role was created 18 months ago to support a vendor integration. The vendor relationship ended. The role was never deleted. It still has an active trust policy allowing the vendor's AWS account to assume it, and the attached permissions include read access to several RDS databases and S3 buckets. No one on the current team knows it exists.
Example 3: The Overpermissive Trust Policy
A deployment role used by a CI/CD pipeline has the following trust policy principal:
{
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
}
}This trusts the entire AWS account, not a specific role or user. Any principal in that account — including compromised developer credentials — can assume this deployment role. The intent was to allow a specific deployment user. The result is an open door.
These are not obscure edge cases. They’re representative of the IAM misconfiguration patterns that appear in nearly every environment we’ve assessed.
The Cost of Getting It Wrong
The consequences of IAM misconfiguration don’t announce themselves until it’s too late.
A breach. Compromised credentials or an overly permissive role is the most common path to unauthorized access in AWS. Lateral movement, data exfiltration, ransomware — all of it flows through IAM.
A compliance failure. SOC 2, PCI DSS, HIPAA, ISO 27001 — every major compliance framework requires demonstrable access controls and least privilege. An IAM review is a standard part of any serious audit. Wildcard policies and unused roles are findings.
An audit finding. Even without a breach, a third-party security assessment or customer security questionnaire that surfaces poor IAM hygiene creates business friction. Enterprise customers increasingly require evidence of access controls before signing.
Erosion of customer trust. If your customers are enterprises handing you their data, IAM risk is their risk too. A breach that traces back to an over-permissive role is not a story you want to tell.
The cost of preventive IAM hygiene is a fraction of the cost of any of these outcomes.
Start with Visibility
You can’t fix what you can’t see. The first step toward managing AWS IAM security isn’t a policy rewrite — it’s understanding your current state. What roles exist? Which ones are unused? Which policies grant wildcard actions? Which trust relationships are still valid?
That’s precisely what Horizon IAM Risk Analyzer is built to answer. It scans your AWS environment, maps your IAM posture against least privilege principles, and surfaces the specific findings that carry the most risk — without requiring you to manually trace every policy attachment.
Horizon IAM Risk Analyzer is available on the AWS Marketplace with a free 14-day trial.
See What's Actually in Your AWS IAM
Horizon IAM Risk Analyzer maps your current IAM posture, identifies misconfigurations, and prioritizes the findings that matter most — in minutes, not weeks.
AWS Marketplace listing →The next post in this series goes deeper: the five IAM misconfigurations we find in almost every AWS account, why they’re so common, and exactly how to fix them. If you’re running workloads in AWS today, at least one of them is in your environment.