Enforcing Least Privilege in AWS IAM: A 2026 Playbook
Over-permissive IAM roles remain the #1 cause of AWS breach blast radius. Here's a practical, tool-agnostic path to right-sizing every identity in your account.
RAZR Advisory
6 min read
Why least privilege still fails in 2026
Most teams say they follow least privilege. In audits, we consistently find:
- Wildcards (
"Action": "*") buried under 3 layers of managed policies - CI/CD roles with
AdministratorAccess"temporarily" attached 18 months ago - Cross-account trust policies scoped to entire AWS organizations
The 4-step remediation loop
- Inventory — pull every role, user, and policy via
aws iam list-*. Export to a single JSON. - Measure actual usage — Access Analyzer's
GenerateServiceLastAccessedDetailsshows what was actually called in the last 90 days. - Generate scoped policies — IAM Access Analyzer policy generation converts CloudTrail into a right-sized policy per role.
- Enforce in CI — reject any PR that reintroduces
*in Action or Resource via a simplecfn-lintor OPA rule.
Guardrails that survive turnover
- SCPs at the org level: deny
iam:CreateUseroutside a break-glass OU - Permission boundaries on every developer role
- Session policies for federated access — no long-lived keys
What to measure
Track these monthly:
| Metric | Target |
|---|---|
Roles with * in Action | 0 |
| Roles unused >90 days | 0 |
| Access keys older than 90 days | 0 |
Getting to zero on all three is a realistic 90-day project for most mid-size AWS estates.