Identity is the new perimeter.
Before cloud-native infrastructure, security teams could draw a physical boundary around their systems. Today, your perimeter is a set of credentials — and attackers know it.
AWS Identity and Access Management (IAM) is the backbone of access control in AWS. It answers two fundamental questions: who can access your cloud environment (developers, SREs, CI/CD pipelines, third-party services), and what they can do once inside (read an S3 bucket, invoke a Lambda function, spin up an EC2 instance).
Get IAM wrong, and a single compromised credential can cascade into a full account takeover. Get it right, and you've closed off the most common attack vector in cloud breaches.
This guide covers the IAM security best practices every team should have in place in 2026 — from foundational hygiene to advanced guardrails.
📘 Want hands-on practice? This article covers the why — if you want to master the how, check out Learn AWS Identity Management with AWS IAM, SSO & Federation on Udemy. It covers AWS IAM, Organizations, Directory Service, SSO, and Federation end-to-end, fully updated for 2026.
1. Use Federated Identity for Human Access
Never create long-term IAM users for human access.
Instead, require all humans — developers, SREs, data engineers, auditors — to authenticate through a federated identity provider (IdP) such as Okta, Azure AD, Google Workspace, or AWS IAM Identity Center (formerly AWS SSO).
Why federation matters:
- Centralized user management: Onboarding and offboarding happens in one place. When an employee leaves, disabling their IdP account revokes access to all connected systems instantly.
- Reduced password fatigue: Users authenticate once and access multiple systems through SSO, reducing the temptation to reuse passwords.
- Smaller attack surface: Fewer systems store credentials, meaning fewer places for attackers to target.
- Audit-ready logs: Federated sessions tie CloudTrail events back to a specific identity in your IdP, making forensic investigation and compliance reporting straightforward.
Federated users receive short-lived, automatically expiring session tokens — not permanent access keys. This dramatically reduces the blast radius of any single credential compromise.
2026 note: AWS IAM Identity Center now supports automated provisioning (SCIM) with all major IdPs. If your team hasn't migrated off IAM users for human access yet, this is the year to do it.
2. Enforce Multi-Factor Authentication (MFA)
MFA is non-negotiable.
It combines something you know (your password) with something you have (a TOTP app, hardware key, or passkey). Even if a password is phished or leaked in a breach, MFA prevents it from being used alone.
Enforce MFA on:
- The root account — always, without exception
- All IAM users with console access (if you still have any)
- Highly privileged roles and break-glass accounts
- Sensitive operations like disabling CloudTrail or modifying SCP policies
You can enforce MFA conditions in IAM policies like this:
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
For privileged accounts, use hardware security keys (FIDO2/WebAuthn, e.g., YubiKey). Unlike TOTP apps, they are fully phishing-resistant.
3. Protect and Restrict the Root User
Your AWS root user has unrestricted access to everything — billing, account settings, IAM itself — and cannot be constrained by IAM policies. That makes it uniquely dangerous.
Root user hygiene checklist:
- Enable MFA immediately, preferably with a hardware key
- Store credentials in a secrets vault or a physically secured location
- Never create access keys for the root user
- Only use it for the small set of tasks that require it, like closing the account or changing the support plan
- Set up a CloudWatch or GuardDuty alert to notify your team any time the root user is used at all
In multi-account AWS Organizations setups, use Service Control Policies (SCPs) to block sensitive actions by member account root users.
4. Apply the Principle of Least Privilege
Grant every identity — human or machine — the minimum permissions required for its specific job, and nothing more.
This limits what an attacker can do if they compromise a credential. It also limits damage from insider threats and misconfigured automation.
Practical steps:
- Start with AWS managed policies, then refine with customer-managed policies as access patterns become clearer
- Use IAM Access Analyzer's policy generation to analyze CloudTrail logs and generate a minimal policy based on what a role actually used
- Prefer resource-level permissions (specific bucket ARNs, function ARNs) over wildcard
*resources - Avoid
AdministratorAccessexcept for dedicated break-glass roles - Scope
iam:PassRoletightly — it's one of the most common privilege escalation paths
Permission boundaries are underused but powerful. They define the maximum permissions an identity can ever receive, even if a more permissive policy is attached later. Use them to safely delegate IAM management to teams without risking privilege escalation.
5. Use Temporary Credentials for Workloads
Applications, Lambda functions, EC2 instances, and containers should never use long-term access keys embedded in code, environment variables, or config files.
Hardcoded keys accidentally pushed to a public GitHub repo is still one of the most common causes of cloud breaches.
Use IAM roles instead:
- Attach a role to your EC2 instance, ECS task, Lambda function, or EKS service account
- The AWS SDK automatically retrieves short-lived credentials from the instance metadata service (IMDS)
- Credentials expire and rotate automatically — no manual rotation needed
- Nothing to distribute, store, or accidentally commit
For on-premises or hybrid workloads, use IAM Roles Anywhere. It issues short-lived AWS credentials to on-prem servers using X.509 certificates — no long-term keys required.
For CI/CD pipelines (GitHub Actions, GitLab CI, etc.), use OIDC federation to obtain short-lived credentials scoped to only what that specific pipeline run needs.
6. Eliminate and Rotate Long-Term Credentials
If you still have IAM users with access keys, audit them now.
- Use IAM Credential Reports to identify keys unused for 90+ days — deactivate and delete them
- Rotate active keys on a regular schedule; use the
access-keys-rotatedAWS Config rule to enforce a maximum key age - Never embed access keys in source code — use AWS Secrets Manager or Parameter Store (SecureString) for runtime credentials
- Set up Config or Security Hub alerts for keys older than your policy threshold
The goal is a zero-standing-credentials model: no persistent long-term keys anywhere, only short-lived credentials generated on demand.
7. Regularly Audit and Remove Unused Access
IAM drift is real. Over time, roles accumulate permissions they no longer need, users go inactive, and policies are attached "just in case." This bloat silently expands your attack surface.
Build a regular IAM hygiene process:
- Use IAM Access Advisor to see the last time each service permission was used — permissions idle for 90+ days are strong candidates for removal
- Review unused IAM roles using the
GetServiceLastAccessedDetailsAPI - Delete IAM users who've been replaced by federation
- Replace inline policies with managed policies (they're easier to audit and reuse)
- Review group memberships quarterly to reflect current team structures
Automate this with AWS Config rules, Security Hub findings, or a CSPM tool. Make it a recurring process, not a one-time cleanup.
8. Detect External and Cross-Account Access with IAM Access Analyzer
IAM Access Analyzer continuously monitors your resource-based policies — on S3 buckets, KMS keys, SQS queues, Lambda functions, IAM roles — and generates findings whenever a resource is accessible from outside your AWS account or organization.
It answers a critical question: can someone outside my account access this resource?
Enable Access Analyzer at the organization level so it catches cross-account access patterns across your entire AWS estate. A public S3 bucket or an overly permissive role trust policy can be an entry point for a supply chain compromise — and you want to know about it immediately, not in a post-incident review.
New in 2025–2026: Access Analyzer now includes unused access findings, identifying roles and policies with permissions that haven't been exercised. This combines external access detection and least-privilege auditing into a single tool.
9. Establish Permission Guardrails with SCPs and Resource Control Policies
In a multi-account AWS Organization, Service Control Policies (SCPs) define maximum permission boundaries at the account or OU level.
Think of them as a constitutional layer. Even if an admin in a member account attaches AdministratorAccess to a role, an SCP can still block them from disabling CloudTrail, creating IAM users, or operating outside approved regions.
Common SCP guardrails to implement:
- Deny creation of IAM users or access keys (enforce federation org-wide)
- Deny disabling of GuardDuty, CloudTrail, or Security Hub
- Restrict workloads to approved AWS regions
- Deny disabling S3 Block Public Access
- Block root user activity in all member accounts
Resource Control Policies (RCPs), introduced in late 2024, complement SCPs by controlling resource-based policies directly. Use RCPs to build a data perimeter — ensuring only trusted identities from within your organization can access sensitive resources, regardless of what individual account policies say.
Together, SCPs and RCPs give you defense in depth at scale and help satisfy compliance frameworks like SOC 2, ISO 27001, and PCI DSS.
10. Monitor, Alert, and Respond
A strong IAM posture isn't just about configuration — it requires continuous monitoring.
- AWS CloudTrail: Logs every IAM action. Enable it with log file validation and ship logs to a locked-down S3 bucket in a separate security account.
- Amazon GuardDuty: Detects anomalous IAM activity — credential exfiltration, unusual API calls from unexpected geos, root credential use.
- AWS Security Hub: Aggregates findings from GuardDuty, Access Analyzer, and Config into a unified dashboard with CIS AWS Foundations Benchmark scoring.
- EventBridge rules: Trigger automated remediation — revoke a session, page the on-call team, isolate a role — when high-severity findings fire.
Set up dedicated alerts for: root user login, console sign-ins from new locations, disabling of security services, and creation of new admin-level roles or policies.
Summary
| Practice | Priority |
|---|---|
| Use federated identity for all human access | Critical |
| Enforce MFA, especially on privileged accounts | Critical |
| Lock down and rarely use the root user | Critical |
| Apply least privilege and use permission boundaries | High |
| Use IAM roles and temporary credentials for workloads | High |
| Eliminate long-term access keys | High |
| Audit and remove unused access quarterly | High |
| Enable IAM Access Analyzer at org level | High |
| Implement SCPs and RCPs as guardrails | High |
| Monitor with CloudTrail, GuardDuty, and Security Hub | High |
AWS IAM is powerful — but power without discipline creates risk. These practices aren't one-time checkboxes. They're habits. The teams with the strongest cloud security postures are the ones who've made IAM hygiene a continuous, automated, team-wide process rather than an afterthought.
Start with the critical items, automate what you can, and build from there.
Want to Go Deeper?
This article covers the security side of AWS IAM, but there's a lot more to master — from hands-on identity federation setup, to AWS Organizations and Directory Service, to building SSO across complex multi-account environments.
If you want to go from understanding best practices to actually implementing them, check out Learn AWS Identity Management with AWS IAM, SSO & Federation on Udemy.
The course covers AWS IAM, AWS Organizations, Directory Service, SSO, and Federation end-to-end — and it's fully updated for 2026. Whether you're preparing for an AWS certification or hardening a production environment, it's one of the most comprehensive resources available on the topic.
Top comments (0)