Most startups don't have an IAM problem. They have ten IAM problems, and they don't know about any of them. A developer needed S3 access six months ago, got AdministratorAccess because it was faster, and that credential is still active. A Lambda function has a role that can write to every DynamoDB table in the account. An intern who left in March still has a login. This is the normal state of AWS IAM at a Series A company, and it is a serious liability.
This guide walks you through an AWS IAM audit for your startup using the AWS CLI and the IAM console. No paid tools required to start. You will know exactly what to look for, what to fix first, and what mistakes to avoid.
Why IAM Audits Matter More at Startups
Larger companies have dedicated security teams running automated compliance checks. Startups move fast, give developers broad access to unblock them, and rarely clean up afterward. That combination means your AWS blast radius, the scope of damage an attacker can do with one compromised credential, is usually much larger than it should be.
IAM misconfigurations are consistently in the top causes of AWS-related breaches. Stolen credentials with overly broad permissions turn a phishing email or a leaked .env file into a full account compromise. An audit does not take days. A focused review takes two to four hours and can significantly reduce your exposure.
Step 1: Generate the IAM Credential Report
Start here. Run this command to generate a CSV of every IAM user, their last activity, and whether MFA is enabled:
aws iam generate-credential-report
Then download it:
aws iam get-credential-report --query Content --output text | base64 -d > iam_report.csv
Open the CSV and look for three things immediately. First, any user where password_last_used is more than 90 days ago or is empty. Those accounts are dormant and should be disabled or deleted. Second, any user where mfa_active is false and password_enabled is true. That is a human login without MFA, which is unacceptable. Third, any access key where access_key_1_last_used_date is older than 90 days. Rotate or delete it.
Step 2: Find Overprivileged Users and Roles
Run this to list all users with attached managed policies:
aws iam list-users --query 'Users[*].UserName' --output text | tr '\t' '\n' | xargs -I{} aws iam list-attached-user-policies --user-name {}
You are specifically looking for AdministratorAccess or PowerUserAccess attached to any user who is not a break-glass emergency account. If a developer has AdministratorAccess for day-to-day work, that is the first thing to fix.
For roles, do the same check:
aws iam list-roles --query 'Roles[*].RoleName' --output text | tr '\t' '\n' | xargs -I{} aws iam list-attached-role-policies --role-name {}
Pay close attention to roles used by Lambda functions, ECS tasks, and EC2 instances. These are frequently over-permissioned because they were set up quickly and never revisited.
Step 3: Use IAM Access Analyzer
Enable IAM Access Analyzer in the IAM console if you have not already. It is free and it will flag any resource policies that allow access from outside your AWS account or organization. Go to IAM, click Access Analyzer, create an analyzer for your account or organization, and review the findings. Any finding labeled as external access to an S3 bucket, KMS key, or Lambda function deserves immediate attention.
Step 4: Review Inline Policies and Old Roles
Inline policies are easy to miss because they do not show up in managed policy lists. Check them with:
aws iam list-user-policies --user-name YOURUSERNAME
Also audit roles that have not been used recently. AWS records last role activity in the console under IAM, Roles. Sort by last activity and flag anything unused for 60 days or more for deletion.
Common Mistakes Startups Make
- Using the root account for anything operational. Create an admin IAM user or use AWS SSO. Lock down root and store those credentials offline.
- Sharing access keys across team members. Every person and every service should have its own credential. Shared keys make audit logs useless.
- Attaching policies directly to users instead of groups or roles. This makes permissions impossible to manage at scale. Use groups for humans and roles for services.
- Skipping the permission boundary on developer roles. If developers can create IAM roles themselves, they can escalate their own privileges. Use permission boundaries to cap what they can grant.
- Never reviewing third-party cross-account roles. Every SaaS tool you connected to AWS may have a cross-account role sitting in your account with broad access. List them and verify they are still needed and still scoped correctly.
Run this audit quarterly at minimum. If you are preparing for SOC 2 or a security review from an enterprise customer, you will need evidence that you do this regularly. A spreadsheet log of findings and remediations is enough to start.
Need help?
If you'd rather have someone do this for you, book a free 20-minute call with MatrixGard. We'll tell you what's broken and what it costs to fix.
