IAM User

An IAM User is an AWS identity with long-term credentials - a username/password for console access and/or access keys for programmatic access.

When to Use (and Not Use)

• Human Access: use IAM Identity Center instead of IAM users; it provides SSO, MFA, temporary credentials, and centralized management
• Application Access: use IAM Roles instead; EC2 instance profiles, Lambda execution roles, ECS task roles all provide temporary credentials
• Cross-Account: use role assumption instead of sharing IAM user credentials
• Third-party SaaS: use IAM roles with external ID instead of sharing access keys

If You Must Use IAM Users

• Enforce MFA on all users (hardware or virtual)
• Set a password policy (length, complexity, rotation)
• Rotate access keys regularly, every 90 days per the CIS benchmark (use the Credential Report to audit)
• Never share credentials between people
• Use IAM Access Analyzer to identify unused users and permissions

Why Long-Term Credentials Are the Problem

The security issue with IAM users is not the identity, it is the credential lifetime. An access key created in 2021 and never rotated is still valid today, and it works from anywhere on the internet unless a policy condition says otherwise. Compare that with a role session that dies on its own within hours. Every static key is a small standing liability: it can be copied out of a laptop, a CI configuration, a Docker image layer, or a git commit, and nothing about the key itself tells AWS it was stolen. This is why every AWS security maturity model starts with the same two moves: migrate humans to Identity Center, migrate workloads to roles, and shrink the IAM user population toward zero. The stragglers are usually legacy third-party tools that only speak static keys; isolate those in a dedicated account with minimal permissions rather than letting them justify keys everywhere.

How It Goes Wrong in Practice

The most repeated AWS incident pattern in existence: a developer commits code with an IAM user's access key pair embedded in a config file and pushes it to a public GitHub repository. Automated scanners, both attacker-run and defender-run, watch the public commit firehose continuously, and stolen keys are typically tried within minutes. The attacker's first calls are reconnaissance (GetCallerIdentity, listing permissions), followed by whatever the key permits: spinning up large EC2 fleets for cryptomining, reading S3 data, or creating new users and keys for persistence. Because the key belongs to an IAM user, it keeps working until a human deactivates it. GuardDuty can flag the anomalous usage, and AWS may quarantine leaked keys it detects with a restrictive policy, but neither substitutes for not having long-lived keys in the first place. The durable fixes: no keys in code (use roles), secret scanning in CI, and alerting on key usage from unexpected networks.

Practical Check: Audit Every User's Credentials

The IAM Credential Report lists every user and the age and status of each password and access key. Generate it, then download it:

aws iam generate-credential-report

aws iam get-credential-report --output text > credential-report.csv

The first command starts generation (its State field moves from STARTED to COMPLETE); the second retrieves the CSV. Look for users with password_enabled true but no MFA, and access keys with a last-used date months in the past. To kill a compromised or stale key immediately:

aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name bob

The --status parameter accepts Active or Inactive; deactivation is reversible, which makes it the safe first move during an incident before you delete anything.

Frequently Asked Questions

Are IAM users deprecated?

No, they remain fully supported, but AWS guidance is explicit: use Identity Center for human access and roles for workloads, and reserve IAM users for the narrow cases that genuinely require long-term credentials, such as legacy tooling that cannot assume roles.

Can an IAM user have two access keys?

Yes, up to two per user, and that is deliberate: it enables rotation without downtime. Create the second key, deploy it, verify traffic on the new key, deactivate the old one, watch for breakage, then delete it.

What should I do first if a user's key leaks?

Deactivate the key with update-access-key, then review CloudTrail for what the key did (filter by AccessKeyId), check for persistence such as newly created users, keys, or roles, and only then clean up. Deactivation before investigation, deletion after.