5 IAM Misconfigurations We Find in Almost Every AWS Security Review

Identity is the first thing we look at in every AWS Security & Architecture Review, and it's rarely clean. Not because teams are careless — because IAM is the part of AWS that accumulates the most cruft over time, quietly, with no error message telling you it's happened. Here are the five findings that show up often enough that we'd bet on them before we've even started.

1. Root account has active access keys

The root user should never have long-lived access keys — not for a script, not for “just this once.” It's the single most privileged identity in the account, and a leaked root key is close to game over. We still find active root keys in a meaningful share of first-time reviews, usually created years ago for something nobody remembers and never rotated out.

2. Root account without MFA

The companion finding to the one above. If root access is ever compromised — through a leaked password, a phishing attempt, or a support-desk social-engineering attempt — MFA is the one control standing between an attacker and full account takeover. It takes five minutes to enable and should be non-negotiable.

3. Overly permissive IAM policies

Wildcard actions (“*”) or wildcard resources granted “to get something working” during an early sprint, then never revisited once it worked. IAM Access Analyzer's policy generation makes tightening these down to what's actually used a lot less painful than it used to be — the barrier is usually just that nobody's assigned to go back and do it.

4. Unused IAM users, roles, and access keys

A contractor's user from a project that wrapped up eighteen months ago. A role created to test something once. Long-lived keys nobody's rotated because nobody's sure what would break if they did. None of this is doing anything useful, and all of it is attack surface. IAM Access Analyzer's unused-access findings will tell you exactly what hasn't been touched in 90+ days — worth a quarterly pass on their own, review or not.

5. Cross-account roles without an external ID

If a third party — a vendor, a tool, a consultancy like us — has a role trusting their AWS account, that trust policy needs an external ID condition. Without one, the setup is vulnerable to the “confused deputy” problem: if that third party's account ID is ever reused or becomes known, anyone could potentially assume the role. It's one line in a trust policy and it's the AWS-recommended default for exactly this reason.

None of these are exotic. They're the boring, high-value fixes that a Well-Architected Security Pillar review is built to surface — and they're usually the first section of the report, because they're also usually the fastest to fix.