AWS IAM Security Best Practices — Why Over-Permissive Access Is Your Biggest Cloud Risk
AWS IAM Security Best Practices — Why Over-Permissive Access Is Your Biggest Cloud Risk
TLDR: I audited a Series A startup's AWS account last year. Seven developers, all with AdministratorAccess. Three inactive accounts from people who'd left the company — still enabled, still with full permissions. Root account with no MFA. No API key rotation in 18 months. This is not unusual. It's the norm. IAM misconfiguration is the number one cloud attack vector — and fixing it costs nothing but time. Here's exactly what to fix.
What IAM Is and Why It's the Foundation of Cloud Security
AWS Identity and Access Management (IAM) is the system that controls who can do what in your AWS account. Every API call, every console login, every automated process that touches your cloud infrastructure goes through IAM. If IAM is misconfigured, every other security control is undermined — an attacker with the right IAM credentials can read your data, modify your infrastructure, delete your backups, and exfiltrate everything you've built.
According to the CrowdStrike 2025 Global Threat Report, cloud-related breaches increased 75% year-over-year in 2024, with credential-based attacks and IAM misconfigurations consistently cited as the primary entry point. This isn't a sophisticated attack class — it's the exploitation of access controls that were never configured correctly in the first place.
The 6 IAM Mistakes I Find in Almost Every Startup Account
1. Everyone has AdministratorAccess. AdministratorAccess is the AWS equivalent of giving every employee a master key to every system, every database, and every configuration in the company. Developers need it to move fast in the early days — the problem is it never gets removed. By the time a company reaches Series A, the entire engineering team typically has full administrative rights they've never needed and shouldn't have.
2. Inactive accounts from former employees remain enabled. When someone leaves, their IAM user needs to be disabled and eventually deleted. This step is regularly skipped — either because offboarding checklists don't include it, or because "we'll do it next sprint." Three months later, the account is forgotten but still active. A former employee — or an attacker who compromised their email and triggered a password reset — has full access to your production environment.
3. Root account used for day-to-day operations. The AWS root account is the account you created when you first signed up. It cannot be restricted by IAM policies — it has absolute, unrestricted access to everything. It should never be used for day-to-day operations, and its access keys should never exist. Almost every startup audit I run finds the root account actively used, and often no MFA enabled on it.
4. Long-lived access keys never rotated. IAM access keys (the AKIA... key ID and secret) are credentials that grant programmatic API access. Unlike passwords, they don't expire by default. Keys created 18 or 24 months ago — possibly assigned to developers who've since left or applications that were decommissioned — are still valid and still represent exploitable credentials if they've been leaked anywhere.
5. Service accounts with admin permissions. When a developer needs a service to access AWS — a deployment pipeline, a Lambda function, a third-party integration — the quickest solution is an IAM user with broad permissions. The correct solution is an IAM role with the minimum permissions that specific service needs. Service accounts with AdministratorAccess are one compromised application away from full account takeover.
6. No IAM permission boundaries or Service Control Policies. In multi-developer accounts, there's nothing preventing a developer with IAM permissions from escalating their own privileges — creating a new admin user, attaching an admin policy to themselves, or assuming a role with broader permissions. Permission boundaries and SCPs are the guardrails that prevent this, and they're rarely configured in early-stage accounts.
The Principle of Least Privilege — Applied Practically
Least privilege means every identity — human or machine — has access to exactly what it needs to perform its function, and nothing more.
In practice for AWS IAM, this means:
A developer who deploys to a specific S3 bucket needs s3:PutObject and s3:GetObject on that specific bucket ARN. Not s3:*. Not s3:* on *. The specific action on the specific resource.
A Lambda function that reads from a DynamoDB table needs dynamodb:GetItem and dynamodb:Query on that table. Not AdministratorAccess. Not even full DynamoDB access.
This sounds tedious to implement, and for the first few roles it is. The practical approach is to start with broader permissions, enable AWS CloudTrail and IAM Access Analyzer, and use the access data those tools generate to identify what each role actually uses — then scope permissions down to match reality. AWS's IAM Access Advisor shows the last time each permission was used, making it straightforward to identify and remove unused permissions.
How to Audit Your IAM Setup Right Now
Step 1: Generate the IAM credential report. In the AWS Console, navigate to IAM → Credential Report → Download Report. This CSV lists every IAM user, whether their password and access keys are active, when each was last used, and whether MFA is enabled. Any user with password_last_used showing never or over 90 days ago warrants immediate review.
Step 2: Identify AdministratorAccess assignments. In IAM → Users, filter by the AdministratorAccess policy. Every user or role with this policy should be reviewed. If the reason isn't clear and current, remove it.
Step 3: Check the root account. Sign into the AWS console and verify MFA is enabled on the root account (visible in the IAM Security Recommendations panel on the IAM dashboard). If root access keys exist (shown in the credential report), delete them immediately.
Step 4: Review access key ages. In the credential report, identify any access key older than 90 days that is still active. Rotate these keys and update any systems using them.
Step 5: Audit inactive users. Any IAM user with no activity in 90+ days should be disabled. Any user from a former employee should be disabled immediately regardless of last activity.
IAM Best Practices: Roles vs Users, MFA, Permission Boundaries
Use IAM roles instead of users for applications and services. IAM roles are assumed temporarily and issue short-lived credentials automatically. They don't have static access keys that can be leaked or forgotten. Any service running in AWS — EC2 instances, Lambda functions, ECS containers — should authenticate via an IAM role, not a long-lived access key.
Enforce MFA on all human IAM users. An IAM policy that denies all actions unless MFA has been used in the current session is a two-minute implementation that eliminates credential-only compromise for human accounts. AWS provides example MFA enforcement policies in their documentation.
Never use the root account operationally. Create a dedicated admin IAM user for administrative tasks, enable MFA on it, lock the root account credentials away, and never use them again except for account-level operations that strictly require root.
How Attackers Exploit IAM Misconfigurations
The attack chain is straightforward and well-documented. Step one: obtain a valid credential — through a leaked access key in a GitHub repository, an SSRF vulnerability that hits the EC2 metadata endpoint and returns instance role credentials, or a phishing attack against a developer.
Step two: enumerate permissions. Tools like Pacu — an open-source AWS exploitation framework — automate this: "what can this credential actually do?"
Step three: privilege escalation. If the compromised credential has iam:CreateUser, iam:AttachUserPolicy, or iam:PassRole permissions, the attacker can create a new admin user or escalate to a higher-privilege role. From there, the entire account is compromised — every service, every data store, every secret.
This is not a theoretical attack chain. It is documented in real breaches and in AWS's own security guidance.
Tools That Help
IAM Access Analyzer — built into AWS, free, identifies resources and roles that are accessible from outside your account or that grant broader access than intended.
AWS Trusted Advisor — the Security checks include IAM-specific recommendations: MFA on root account, IAM access key rotation, and permissions reviews. Available on Business and Enterprise support plans.
Prowler — open-source cloud security tool that runs hundreds of checks against your AWS account against CIS Benchmarks and AWS security best practices, including comprehensive IAM coverage. Free to run, produces a detailed findings report.
# Run Prowler against your AWS account
pip install prowler
prowler aws --services iam
Get Your IAM Configuration Reviewed
IAM misconfiguration is the highest-leverage security problem in most startup AWS accounts — high likelihood of exploitation, high potential impact, and entirely preventable with the right configuration.
A cloud security review covers IAM in depth: every user and role's permissions, key ages, inactive accounts, privilege escalation paths, and the configuration of monitoring and guardrails. The findings are specific and actionable, not generic recommendations.
Get in touch to discuss what a review covers for your environment, explore our services, or read more about how we work. More cloud security guides are on the Kuboid blog.
Kuboid Secure Layer provides cloud security assessments and web application penetration testing for startups and growing businesses. Learn more at www.kuboid.in.
