The 7 AWS IAM Misconfigurations We Find in Almost Every Cloud Assessment

Identity and access management remains the single largest source of exploitable risk in AWS environments — more common than any specific service misconfiguration. Across our cloud security engagements, seven patterns recur with striking consistency.

The most damaging is overly permissive trust policies on IAM roles, particularly roles assumable from EC2 instance profiles or Lambda execution contexts that grant far broader permissions than the workload requires. When an application is compromised, the blast radius is defined entirely by what its role can do — and in most environments we assess, that blast radius is far larger than necessary.

Close behind: long-lived access keys instead of role-based temporary credentials, wildcard resource permissions in policies (particularly on S3 and IAM actions themselves), missing MFA enforcement on privileged users, unused but still-active IAM users and roles from departed employees or decommissioned projects, cross-account trust relationships that were never reviewed after initial setup, and service-linked roles with permissions boundaries that were never applied.

The fix for most of these isn't exotic — it's discipline. Implement permissions boundaries as a default guardrail, not an afterthought. Rotate away from long-lived keys entirely in favor of IAM roles with short-lived credentials. And schedule a quarterly access review specifically for unused principals; in our experience, at least 15% of IAM users and roles in a typical account have had no activity in over 90 days.