An AWS IAM least privilege checklist has five parts: no long-lived keys for people or workloads, policies scoped to named actions and resources, evidence from Access Analyzer instead of guesses, a routine to delete unused access, and organization level guardrails. Work through them in that order, because each step makes the next one cheaper.
Why start with credentials and not policies?
A perfectly scoped policy attached to a leaked access key is still a leak. AWS's own IAM guidance lists temporary credentials first. Human users should federate through an identity provider, and AWS recommends IAM Identity Center for central access management. Workloads on EC2 or Lambda receive role credentials automatically.
Workloads outside AWS can still avoid static keys. The documentation names IAM Roles Anywhere with an X.509 certificate, and the AssumeRoleWithWebIdentity and AssumeRoleWithSAML calls for tokens from an identity provider. CI systems are the usual case for the web identity route.
How do you scope a policy without breaking production?
AWS says you may start broad while you learn what a workload needs, then narrow as the use case matures. That is honest, and it means narrowing must be scheduled work, not a hope.
AWS managed policies are a starting point only. They serve every customer, so they rarely fit one workload. IAM Access Analyzer can read CloudTrail activity for a role and generate a fine-grained policy from the services and actions actually used. Test the generated policy before it reaches production.
Constructed example: a nightly report job has an AdministratorAccess role because it was built in a hurry. Run policy generation over thirty days of CloudTrail, find it only calls S3 GetObject on one bucket and Athena queries, and replace the role with that policy.
What about conditions?
Conditions turn a broad grant into a narrow one. The AWS guide gives two examples: require requests to use TLS, and allow an action only when it is made through a specific service such as CloudFormation. Use conditions on resource tags, source VPC endpoints or organization membership where your design supports them.
How do you find access nobody uses?
IAM reports last accessed information for users, roles, permissions, policies and credentials. Use it on a calendar. Quarterly is common, though the right interval depends on your change rate. Remove what is unused and refine what is partly used.
What stops one account from undoing the rest?
Separate workloads by account in AWS Organizations and use service control policies as guardrails over every principal in the member accounts. AWS also lists resource control policies for resources and permissions boundaries to delegate permission management safely inside one account. Guardrails cap what any single mistake can grant.
The checklist
- Humans sign in through federation with temporary credentials, not IAM users.
- Workloads use roles; any remaining access keys are listed with an owner and a rotation date.
- MFA is required where people still hold credentials, and the root user is locked down.
- No policy contains a wildcard on both action and resource without a written reason.
- Policies are generated or checked with Access Analyzer, including its policy validation checks.
- Public and cross-account access findings are reviewed and closed.
- Last accessed data is reviewed on a schedule and unused access is removed.
- SCPs, and resource control policies where fitting, cap each account.
- Permissions boundaries are set for any team allowed to create roles.
- Policy changes go through code review, with CI checks on the policy files.
Safeguard's policies and gates can check infrastructure code in the pipeline, so an over-broad policy fails review before it deploys.
How do you keep it from decaying?
Least privilege is a state you drift away from. New features need new permissions, someone adds a wildcard to unblock a release, and the exception never gets removed. Put policy changes through the same review as code, record the reason for any broad grant with an expiry date, and rerun last accessed reviews on a schedule. Treat the first cleanup as a baseline, not a finish line.
Quick check
Are AWS managed policies least privilege?
Not usually. AWS notes they are built for all customers, so define customer managed policies that match your use case.
How do you generate a policy from real usage?
Use IAM Access Analyzer policy generation, which builds a policy from CloudTrail activity. Test it, then deploy it.
Sources
Last reviewed: 18 October 2026.
