Misconfigured IAM is the single most common cause of cloud breaches we find in audits. The good news: almost all of it is preventable with a handful of disciplined practices. Here are the five IAM anti-patterns we see most often on AWS, and exactly how to fix each one.
AWS Identity and Access Management (IAM) controls who can do what in your cloud. When it drifts, and it always drifts, you end up with over-permissive roles, forgotten access keys and privilege paths an attacker can walk straight through. In every cloud security assessment we run, IAM findings are the largest single category. These five are the ones worth fixing first.
1. Wildcard permissions, Action: "*"
Policies granting Action: "*" or Resource: "*" are the most dangerous configuration in your cloud, a single compromised credential with a wildcard policy can do anything, anywhere in the account. Scope every policy to the exact actions and resources a role actually requires. Start from zero permissions and add only what breaks, rather than starting broad and trying to trim later. Audit continuously with AWS IAM Access Analyzer, which flags policies granting more access than the workload has ever used, and remove anything unused for more than 90 days.
2. Long-lived access keys
Static access keys are a ticking timer, the longer they live, the more places they leak into (config files, CI logs, laptops, Slack messages). Prefer short-lived credentials via IAM roles and federation wherever possible; an EC2 instance or Lambda function should assume a role, never carry a hard-coded key. Where keys are genuinely unavoidable, enforce rotation on a fixed schedule, alert on any key inactive for 90+ days, and store them in AWS Secrets Manager rather than environment variables or code.
3. No MFA on privileged accounts
Multi-factor authentication on the root account and all administrative users blocks the overwhelming majority of credential-based attacks, even if the password leaks, the attacker cannot log in. Enforce it with a Service Control Policy at the AWS Organizations level so no individual account can opt out. The root account in particular should have hardware MFA and be used almost never. There is no valid operational reason to skip this.
4. Flat account structure
Keeping development, staging and production workloads in one AWS account means a single misconfiguration, or one compromised developer credential, can expose everything. Separate workloads across dedicated AWS accounts, group them under AWS Organizations, and apply Service Control Policies as organisation-wide guardrails (for example, denying the ability to disable CloudTrail or leave a region unmonitored). Blast-radius containment is one of the highest-leverage things you can do in cloud security.
5. No continuous IAM review
IAM drifts constantly as people join, leave and change roles. One-off annual audits catch problems months after they appear, long after an attacker would have. Automate least-privilege analysis with IAM Access Analyzer, run CIS benchmark scans with AWS Inspector v2 on a schedule, and alert in real time on any new high-risk policy attachment or newly created admin user. The goal is to know about a dangerous change within minutes, not at next year's audit.
How to prioritise which IAM fix comes first
If you can only fix one thing this quarter, start with wildcard permissions on any role that can be assumed from outside the account or by a broad set of users, that is the highest blast-radius risk. After that, kill long-lived keys belonging to former employees or dormant service accounts, because those are the credentials most likely to be sitting in a leaked repository or an old laptop. MFA enforcement is the cheapest high-impact control and can usually be rolled out in a day. Account separation and continuous review are larger programmes but pay off permanently.
What a real IAM audit looks like
When we run an IAM audit for a client, we pull the IAM credential report and Access Analyzer findings, map every principal to the permissions it actually uses versus what it is granted, flag every policy with a wildcard or a resource of *, list all access keys older than 90 days, and check MFA status on every human and privileged account. We then rank findings by exploitability and blast radius, not by raw count, ten low-risk findings matter less than one internet-assumable admin role. The output is a prioritised remediation plan your team can execute, not a 400-page tool dump nobody reads.
The bottom line
Least privilege is a practice, not a one-time configuration. Fix the wildcards, kill the long-lived keys, enforce MFA, separate your accounts, and make review continuous, and you close the majority of the attack surface we find in real audits. If you would like an independent review of your AWS IAM setup, book a free cloud security assessment, we will identify your highest-risk misconfigurations in under 20 minutes.
Last updated: 1 July 2026 · Written by Momina Farooq, AWS Certified Solutions Architect, Azure AZ-500, Licensed Ethical Hacker.