The five IAM pitfalls we keep finding in AWS

After enough cloud assessments you stop being surprised. The same handful of identity and access mistakes turn up in environments of every size, from three-person startups to companies with a platform team and a cloud center of excellence. They persist because IAM is genuinely hard, the defaults are permissive, and access tends to accumulate faster than anyone reviews it.

Here are the five we find most often, why they matter, and the fix. None of the fixes are exotic. The hard part is noticing, which is exactly why they survive for years.

Wildcards in policies that nobody meant to leave there

You see it in almost every account. A policy with Action: "*" on Resource: "*", attached to a role that needed exactly two permissions when someone created it in a hurry. The intent was to unblock a deploy on a Friday. The wildcard never came back out, and now a service that should be able to read one bucket can do anything to anything.

The danger is that an attacker who compromises that workload inherits the wildcard. A minor foothold becomes full account access, not because the attacker was clever, but because the door was already wide open. We have built entire attack paths on a single forgotten wildcard.

The fix is least privilege, and the practical way to get there is to scope policies to the specific actions and resources actually used. AWS gives you the data to do this through access analyzer and the access history on each role, which shows what permissions a role has actually exercised. Grant what is used, deny the rest, and review when responsibilities change.

Long-lived access keys that should not exist

IAM users with permanent access keys are a habit left over from an older era of AWS, and they are still everywhere. The keys get created for a script, embedded in a config file, shared in a chat message, committed to a repository once by accident, and then they live forever because nobody is sure what would break if they were rotated.

Every one of those keys is a credential that does not expire, cannot be easily traced to a person, and will not trip an alarm when it is used from somewhere new. They are the single most common way we see cloud credentials leak and get abused.

The fix is to stop using them. Human access should go through federated single sign-on with temporary credentials, so people authenticate through your identity provider and get short-lived sessions. Workloads should use roles, which hand out temporary credentials automatically and rotate them for you. For the rare case where a long-lived key is genuinely unavoidable, rotate it on a schedule and monitor it closely. The goal is that a leaked credential expires before it is useful.

The blast radius of a single role nobody questions

Most environments have a role, often tied to CI/CD or to an old admin process, that has quietly become the most powerful identity in the account. It can assume other roles, modify IAM, touch production, and reach the logging it would need to cover its tracks. Everyone knows it is too powerful. Nobody wants to be the one who breaks the pipeline by trimming it.

This is the role an attacker dreams about, and the deployment pipeline is an increasingly popular way in, because it sits at the intersection of code, secrets, and production access. If the pipeline can do everything, then anything that compromises the pipeline can do everything too.

The fix is to separate duties even when it is inconvenient. The role that deploys should not also be the role that manages identity. Production access should be scoped to what deployment actually requires. And the pipeline's credentials should be short-lived and tied to specific workflows rather than a standing key with the keys to the kingdom.

IAM changes that happen in the dark

In a surprising number of accounts, someone can create a user, attach an admin policy, and grant themselves access without anyone being notified. The capability exists, the logging may even capture it, but nobody is watching the logs, so the change happens in silence.

This matters because privilege escalation through IAM is a favorite move once an attacker has any foothold. They do not need to break anything. They just need to grant themselves more access and wait. If that grant generates no alert, you have removed the one chance you had to catch it early.

The fix is detection on the actions that matter. Changes to IAM policies, new users and keys, modifications to logging configuration, and use of the root account should all generate alerts that a human actually sees. You already have the audit trail in CloudTrail. The gap is almost always that nobody is alerting on it.

Root accounts that are still in play

The root account of an AWS account is supposed to be locked in a drawer and almost never used. In practice we still find root accounts without MFA, with active access keys, and occasionally with their credentials sitting in a password manager shared across a team.

Root is absolute. It can do things no other identity can, including things designed to be irreversible, and it sidesteps most of the guardrails you have carefully built. A compromised root account is close to game over.

The fix is straightforward and worth doing today. Remove any root access keys entirely, because root should never be used programmatically. Put strong MFA on the root login. Store the credentials so that using root is a deliberate, rare, audited event rather than a convenience. Then set up an alert so that any root activity at all gets immediate attention, because legitimate root use is so rare that every instance deserves a second look.

The pattern underneath all five

Every one of these comes from the same root cause. Access is easy to grant and nobody owns taking it away. Permissions accumulate, credentials outlive their purpose, and powerful identities drift further from least privilege with each passing quarter, because removing access feels risky and granting it feels helpful.

The fix at the program level is a regular review with a clear owner. Someone whose job it is to ask, for each powerful identity and standing credential, whether it is still needed and still scoped correctly. The tools to do this well already ship with AWS. What is usually missing is the habit, and the habit is cheaper than the breach.