AWS IAM Security Checklist for Beginners

A practical, prioritized checklist for AWS IAM hardening. Group items by area, score each, and tackle highest-impact first.

---

1. Account Foundation

• All AWS accounts inventoried with owners.
• AWS Organizations in use.
• Control Tower (or equivalent) used for new accounts.
• Standard account baseline applied to every account.

2. Root Account

• Hardware MFA on root.
• Strong unique password in password manager.
• No active root access keys.
• Recovery email is monitored shared mailbox.
• Recovery phone is controlled corporate number.
• Root sign-in alerted.
• Root not used for daily operations.
• Annual review of root credentials.

3. Human Access

• AWS IAM Identity Center used for human access.
• External IdP (Entra ID / Okta / Google) federated where possible.
• MFA enforced (hardware preferred).
• Permission Sets follow least privilege.
• Admin Permission Sets minimized.
• Standalone IAM Users minimized.

4. Workload Access

• EC2 uses instance profiles (no embedded keys).
• IMDSv2 enforced on EC2.
• Lambda uses execution roles.
• ECS / EKS uses task roles / IRSA.
• CI/CD uses OIDC federation (no stored access keys).
• Service trust uses aws:SourceArn / aws:SourceAccount.

5. Long-Lived Credentials

• IAM user access keys minimized.
• Remaining keys rotated ≤ 90 days.
• Leaked-key monitoring (GitHub secret scanning, GitGuardian).
• Inactive keys disabled / deleted.
• No keys for root.

6. Authorization

• No *:* policies in production.
• AWS managed AdministratorAccess use minimized.
• iam:PassRole scoped to specific roles.
• IAM Access Analyzer enabled.
• Unused-access findings actioned.
• Custom policies in version control.
• Inline policies minimized.

7. Permission Boundaries

• Boundaries used for delegated IAM administration.
• iam:PermissionsBoundary condition required on principal creation.
• Boundaries deny their own removal.
• Boundaries documented per team.

8. Service Control Policies

• Baseline SCPs at OU level.
• Deny disabling CloudTrail / GuardDuty / Security Hub.
• Deny public S3 (where possible).
• Region restriction.
• Deny IMDSv1 launches.
• Deny root usage in member accounts.

9. Cross-Account

• Cross-account access via roles.
• External IDs for third-party trust.
• aws:PrincipalOrgID for internal cross-account.
• Tight trust policies (no Principal: "*").
• Stale vendor trust removed promptly.

10. Resource-Based Policies

• S3 Block Public Access at account level.
• Bucket policies reviewed; no broad principals.
• KMS key policies reviewed.
• SNS / SQS / Lambda resource policies reviewed.
• IAM Access Analyzer external-access findings actioned.

11. Logging

• Multi-region CloudTrail in every account.
• Management + data events for sensitive resources.
• CloudTrail centralized to logging account.
• Logging bucket immutable; long retention.
• Config aggregator across accounts.
• VPC Flow Logs where applicable.

12. Detection

• GuardDuty enabled across accounts.
• Security Hub aggregator enabled.
• Macie for sensitive data discovery.
• SIEM ingests CloudTrail and security findings.
• Identity-specific detections live (IAM user creation, AdministratorAccess assign, trust changes, access key leak, root sign-in, anomalous AssumeRole).

13. Response

• Incident playbooks for: compromised key, compromised role, public S3, root compromise, rogue admin.
• Tabletop exercises annually.
• Break-glass procedure documented and tested.

14. Governance

• All principals tagged with owner / purpose.
• Quarterly access reviews on privileged Permission Sets and roles.
• Annual broader review.
• Joiner / mover / leaver workflows update access promptly.
• Inactive identities and keys cleaned up quarterly.

15. Continuous Improvement

• Posture score (e.g., Forestall, Security Hub) tracked over time.
• Top risks reported to leadership quarterly.
• Attack-path analysis continuous.
• Best-practice metrics tracked (MFA adoption, key age, public buckets, etc.).

---

How to Use This Checklist

1. Score each item as Implemented / Partial / Not Started.
2. Identify the worst 5–10 in high-impact sections (Root, Human Access, Long-Lived Credentials, Authorization, Logging).
3. Make those this quarter's goals.
4. Re-score quarterly.
5. Use trend (items implemented over time) as your KPI.

---

How Forestall Helps

Forestall checks every account against these and many more items, ranks findings by attack-path impact, and tracks remediation — turning this checklist into measurable AWS IAM risk reduction over time.

---

Conclusion

AWS IAM has many surfaces, but a small set of high-impact controls (Identity Center + federation, hardware MFA, root lockdown, eliminate long-lived keys, least privilege via Access Analyzer, baseline SCPs, centralized CloudTrail, identity-focused detections) closes most risk for most organizations. Use this checklist as your map; fix the highest-impact items first; and watch your AWS identity attack surface shrink quarter over quarter.