12 AWS IAM Security Best Practices

One well-scoped Amazon Web Services (AWS) identity and access management (IAM) policy can cap what a stolen key reaches across your services. Maintaining that scope requires more than configuration. Inadequate IAM ranks as the leading cloud threat, driven by excessive permissions and poorly managed credentials.

Correct IAM configuration on its own doesn’t keep permissions scoped over time, because a permission your team granted appropriately during Monday’s change window can still be abused by a stolen key or an unused role on Friday if nobody is watching how it gets used.

This guide covers 12 AWS IAM security best practices from root account lockdown, federation for human access, and least-privilege and guardrail practices that cap blast radius, to the CloudTrail-plus-security information and event management (SIEM) audit layer that makes the other practices provable.

What Is AWS IAM?

AWS IAM is the web service that controls account access by determining who can authenticate and what each identity can do against AWS resources. An IAM user is a named identity with long-term credentials for a person or workload, while a “user group” collects users that receive permissions together.

IAM doesn’t allow nested groups, and policies can’t name a group as a Principal. An IAM role holds permissions, but no password or access keys, so whoever assumes it gets temporary credentials.

What ties users, groups, and roles together is the policy attached to them. A policy defines which actions an identity or resource allows, on which resources, and under which conditions.

1. Protect the Root Account and Never Use It for Daily Tasks

IAM policies cannot restrict root user permissions, so compromised root credentials compromise the account. You should reserve root for recovery tasks such as restoring an administrator who revoked their own permissions and use another identity for daily work. Root access keys shouldn’t exist, and the aws login command supports command-line root access without minting one. These root user best practices apply across every account you manage.

Since June 2025, every account type requires multi-factor authentication (MFA) on the root user, within 35 days from first console sign-in to register a device. AWS Organizations lets you centralize root access and delete root credentials from member accounts. Root-only actions there use tightly scoped temporary credentials. A dual-control rule prevents one person from holding both the root password and its MFA device.

2. Require Multi-Factor Authentication (MFA)

Every IAM user with a console password needs MFA. Phishing-resistant passkeys and security keys offer stronger protection than authenticator codes, while root should use a hardware MFA device. Account-by-account enforcement can leave users without MFA enforcement as people join and leave, so enforce the requirement through the aws:MultiFactorAuthPresent MFA condition key:

{
  "Sid": "DenyAllExceptListedIfNoMFA", "Effect": "Deny",
  "NotAction": ["iam:CreateVirtualMFADevice", "iam:\u0045nableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken"],
  "Resource": "*",
  "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } }
}

BoolIfExists with false rejects sessions that skipped MFA and requests that use long-term credentials such as access keys. Under this MFA enrollment policy, the NotAction list lets a user enroll a device before the policy locks them out.

In AWS Organizations, a service control policy (SCP) statement applies to the root, organizational unit, or individual account you target, though SCPs never restrict the management account.

3. Apply Least-Privilege Permissions

Least privilege means each identity holds only the actions and resources its job requires. Excessive permissions that go unused expand the possible blast radius. AWS managed policies cover common use cases, so you can start there and tighten them into specific managed policies once service access data shows which services an identity never touches.

IAM Access Analyzer policy validation runs numerous policy checks and flags statements it considers overly permissive. The worst grant is "Action": "*" on "Resource": "*", which exposes every escalation path at once.

Permissions that create policy versions, attach or insert policies, or pass roles can undermine least privilege without creating an identity. You should treat privilege escalation permissions such as iam:CreatePolicyVersion, iam:Attach*Policy, iam:Put*Policy, and iam:PassRole as carefully as administrative access.

4. Use IAM Roles and Temporary Credentials Instead of Long-Term Access Keys

An access key stays valid until someone deletes it. A role session from AWS Security Token Service (STS) uses temporary security credentials that expire automatically. Hardcoded credentials still reach source repositories, where anyone who obtains them may access AWS resources. The AWS guidance for secure access keys explains safer handling. Keep access keys out of code.

AWS workloads should assume roles. Amazon Elastic Compute Cloud (EC2) instance profiles and Lambda execution roles deliver temporary credentials that the software development kit (SDK) picks up automatically. Amazon Elastic Kubernetes Service (EKS) supports IAM Roles for Service Accounts and EKS Pod Identity, while IAM Roles Anywhere extends roles to external workloads through your certificate authority.

If a third-party tool can’t use roles or IAM Identity Center, tightly scope its IAM user, automate rotation with Secrets Manager, and keep the credentials out of code.

5. Use Federation and AWS IAM Identity Center for Human Access

Use AWS IAM Identity Center rather than IAM users for human access. AWS IAM Identity Center (formerly AWS Single Sign-On), provides the preferred workforce access. It federates identities from Okta, Microsoft Entra ID, on-premises Active Directory, or a Security Assertion Markup Language (SAML) 2.0 provider. The identity provider (IdP) keeps the password, MFA policy, and offboarding switch.

Permission sets are Identity Center’s equivalent of policies. They consist of a template of up to 10 managed policies plus an inline policy. When you assign one to a group, Identity Center creates a controlled IAM role in that account and attaches those policies.

Sessions default to one hour and cap at 12 hours, so every human session uses temporary credentials.

6. Attach Permissions to Groups and Roles Instead of Individual Users

When you attach policies directly to users, they don’t scale because you must edit each user individually. For the IAM users you still need, place permissions on an IAM user group.

Follow the same pattern with Identity Center groups and permission sets. For example, attach one read-only policy to an operations group instead of copying it to every operator.

Workloads use a role as the permission unit, so one policy change updates every instance, function, or pod and simplifies later credential reviews.

7. Rotate and Remove Unused Access Keys and Credentials

Your baseline should rotate access keys on a defined schedule and remove credentials after an inactivity threshold. Long-lived and unused credentials can outlast the workload or person that needed them.

The IAM credential report inventories every user’s credentials so a scheduled job can flag old keys and disable idle credentials. Rotation replaces a key that something still uses. Revocation deletes an unused credential and reduces the identities that your later access conditions must cover.

8. Use IAM Conditions to Further Restrict Access

A condition turns a broad allow into a scoped one without rewriting the action list. Several IAM condition keys cover common restrictions. You can combine them to control request origin, principal identity, receiving Region, and organization membership:

• aws:RequestedRegion: Confines write operations to approved Regions. IAM calls always resolve to us-east-1, so a Region condition on IAM actions breaks them.
• aws:SourceIp: Limits requests to a source address range, but virtual private cloud (VPC) endpoints omit it from requests, which is why the IfExists operator variants exist.
• aws:PrincipalTag: Admits only principals carrying a matching tag such as department.
• aws:PrincipalOrgID: Admits every account in your organization without listing them.

Conditions stack together, so one policy can apply all four at once. Policy design should use only keys that match the request context your services provide. Testing the resulting policy against IAM actions and VPC endpoint traffic verifies it before you audit public and cross-account exposure.

9. Verify and Restrict Public and Cross-Account Access

Resource-based policies on Amazon Simple Storage Service (S3) buckets, AWS Key Management Service (KMS) keys, Lambda functions, Amazon Simple Queue Service (SQS) queues, and IAM role trust policies can grant access outside your account. Within an account, an identity or resource policy may grant access only if no explicit deny, SCP, permissions boundary, or session policy blocks it.

IAM Access Analyzer’s external access analyzers report each resource-based policy that grants access outside your zone of trust.  Deploy one per Region you use. These external access analyzers complement the policy validation covered in Practice 3. Validation grades a policy you wrote before you attach it, while access analysis reports who can reach deployed resources and shows where you need multi-account guardrails.

10. Establish Permissions Guardrails Across Multi-Account Environments

An SCP sets the permission ceiling for every principal in an account or organizational unit (OU), even when an administrator attaches AdministratorAccess with */* permissions. Effective permissions are the intersection of the SCP and identity and resource policies. An SCP by itself grants nothing, and it never applies to the management account. A common sandbox-OU pattern denies IAM write actions for everyone except a named administrator role.

IAM permissions boundaries provide a similar ceiling inside one account. Developers can call iam:CreateRole only when they attach a specific boundary. Every role then inherits a cap that your recurring audits can verify.

11. Regularly Audit and Remove Unused Users, Roles, Policies, and Credentials

Roles from a migration and users for former contractors can persist. Policies attached during an incident add to standing privilege faster than teams remove it. AWS Access Advisor shows last-accessed data for every user, group, role, and policy.

An unused access analyzer produces UnusedIAMRole, UnusedIAMUserAccessKey, UnusedIAMUserPassword, and UnusedPermission findings across the organization without per-Region deployment.

These unused access findings support recurring reviews. Your organization defines how often those reviews run. A workable baseline reviews all identities on a regular cadence, examines administrative and IAM-write permissions more often, and alerts on new findings as they appear.

12. Monitor and Audit IAM Activity with CloudTrail and a SIEM

Nearly every action above produces an AWS CloudTrail event. Specific event names carry high-value signal. Your monitoring baseline should include the following categories and investigate each event by identity and source address within the affected account:

• ConsoleLogin (signin.amazonaws.com): The mfaAuthenticated field and a userIdentity.type: Root value expose logins without MFA and root use.
• AssumeRole (sts.amazonaws.com): An unexpected source address or Region points to stolen credentials.
• CreateAccessKey and AttachUserPolicy naming AdministratorAccess: The persistence pair.
• StopLogging and DeleteTrail: Defense evasion, since an attacker holding valid credentials looks like a user until they try to blind you.

Those four alert categories belong in an alert and in the store that holds the rest of your CloudTrail events. CloudTrail supplies the events, though delivery can lag the underlying activity. A SIEM adds the correlation layer on top. It joins CloudTrail events with network data and application logs, which lets a credential-based intrusion surface as a sequence of related events rather than appearing at the next access review.

Coralogix Cloud SIEM ingests AWS CloudTrail events through a Lambda/S3 integration, processes the events in-stream, applies out-of-the-box detections, and retains the CloudTrail events in your own S3 bucket.

The Best IAM Security Is Configuration Plus Continuous Monitoring

Practices one through 11 in this guide set your access perimeter, while practice 12 makes them provable, because a control you can’t audit is a control you’re taking on trust.

Coralogix runs that audit layer. The Streama© engine applies in-stream processing to CloudTrail before storage. The platform stores events in your own cloud bucket in open Parquet format with unlimited retention and no rehydration cost for incident response or compliance queries, while cloud security posture management (CSPM) flags AWS misconfigurations.

Teams handling regulated data benefit from dedicated security staff and/or managed detection and response (MDR) through Coralogix’s Snowbit MDR for round-the-clock alert interpretation.

If you want to see which practices your accounts are missing today, start a free 14-day Coralogix trial and route your CloudTrail bucket into it.

Frequently Asked Questions About AWS IAM Security Best Practices

What are the five pillars of IAM?

The “five pillars of IAM” is an informal model covering authentication, authorization, identity lifecycle management, audit and compliance, and federation. AWS and the National Institute of Standards and Technology (NIST) do not formally define it. MFA and federation cover authentication, least privilege and guardrails cover authorization, rotation and access reviews cover lifecycle, and CloudTrail plus a SIEM cover audit.

What are the best practices for security in AWS more broadly?

Every other AWS control relies on correctly scoped permissions, which makes IAM the first priority. A full posture adds VPC design and security groups, encryption at rest and in transit, threat detection with Amazon GuardDuty, and configuration compliance through AWS Config and AWS Security Hub.

What are the top 10 vulnerabilities in AWS?

Security Hub and Center for Internet Security (CIS) controls map directly to recurring AWS weaknesses. Recurring weaknesses include admin-wildcard IAM policies, leaked or unrotated access keys (IAM.3), public S3 buckets, and missing root MFA (IAM.9). Others include unencrypted Amazon Elastic Block Store (EBS) and Amazon Relational Database Service (RDS) storage, security groups open to 0.0.0.0/0 (EC2.2 and related controls), publicly accessible RDS instances, CloudTrail inactive in one or more Regions (CloudTrail.1), disabled GuardDuty (GuardDuty.1), and stale credentials (IAM.22).

How do you implement least privilege in AWS IAM?

The fastest path begins with an AWS managed policy. After collecting representative workload activity, use IAM Access Analyzer policy generation to build a customer managed policy from CloudTrail activity. Policy validation returns findings before you attach the proposed policy, and custom policy checks in your pipeline stop later edits from quietly granting new access.