AWS IAM Misconfigurations We Keep Finding

AWS's own IAM best practices guide has existed, in some form, for over a decade, and the misconfigurations it warns against are still the ones that show up in almost every cloud assessment we run. IAM is rarely the newest part of an AWS environment; it's usually the part that's accumulated the most historical cruft, one "just give it AdministratorAccess for now, we'll fix it later" decision at a time.

Overly permissive policies, granted out of convenience

The single most common finding is an IAM policy attached to a role or user that grants far more than the workload needs, not a misconfigured S3 bucket or an exposed security group. s3:* on all resources when the application only ever needs to read from one specific bucket. AdministratorAccess attached to a CI/CD service role because scoping it down took longer than the sprint allowed. Each one of these is a rational shortcut in isolation and a real risk in aggregate, because IAM permissions define the actual blast radius of any single compromised credential, key, or vulnerable workload. A properly scoped role limits what an attacker can do with a stolen credential; an over-permissioned one hands them the whole account.

Long-lived, unused access keys

Root account access keys still existing at all is the most severe version of this, AWS's own guidance is that the root user shouldn't have active access keys under normal operation, full stop, since root can bypass every IAM boundary in the account. Below that severity level, individual IAM users with access keys that were created for a one-time migration or a departed contractor and never rotated or deactivated are a routine finding, every live key is a standing credential that, once leaked (committed to a public repo, embedded in a client-side bundle, cached in a CI log), works indefinitely until someone notices and revokes it.

Missing MFA on privileged users

Console access without MFA enforced on any account with meaningful IAM permissions, not just root, remains common, particularly on service accounts or "break glass" admin users that were set up quickly and never revisited. A compromised password with no MFA behind it is a full account takeover; the same compromised password with hardware or app-based MFA enforced usually isn't, which is exactly why this is one of the highest-leverage, lowest-effort fixes available in any AWS environment.

Trust policies that are wider than intended

Cross-account roles and identity federation are where a subtler version of this shows up: a role's trust policy meant to allow access from one specific partner account, written broadly enough that it actually allows any AWS account, or a condition key that was intended to restrict access but doesn't actually enforce what the author assumed it did. These don't show up in a simple permissions review, they require actually reading and testing the trust policy's logic, not just the attached permission policy.

Closing the gaps

• Least-privilege policies scoped to specific resources and actions, not wildcard grants, reviewed against what the workload genuinely calls
• AWS IAM Access Analyzer run continuously, not as a one-time audit, since permissions drift as fast as the environment changes
• MFA enforced on every human user with console access, with hardware keys or an authenticator app on anything privileged
• Scheduled access key rotation and removal of any key with no recent usage in CloudTrail, an unused key is pure risk with zero operational benefit

This is exactly the surface our AWS Security engagements are scoped around, IAM policy review, Access Analyzer findings, and trust-policy testing, not just a checklist of enabled services. For the broader class of cloud misconfiguration this sits inside, see our piece on common cloud security misconfigurations, and for the identity model this all supports, see Zero Trust Architecture, explained.