AWS IAM best practices: a practitioner’s guide for 2026

Identity is the perimeter. If you are still treating network controls as your primary security boundary in AWS, you are designing for the wrong threat model. IAM best practices have never been more consequential than they are right now, in August 2026, when AWS is shipping significant identity changes at pace, agentic AI workloads are being handed cloud credentials at scale, and regulators from the FCA to the ICO are scrutinising access governance with renewed seriousness. This guide covers the controls, the tooling, and the trade-offs you actually need in production.

Why IAM hygiene is a continuous discipline, not a setup task

Most cloud security incidents I review are self-inflicted, and the root cause is nearly always identity. The AWS shared responsibility model places identity, configuration, and workload protection squarely on customers, which means permission creep is your problem to manage.

Permission drift happens silently. A developer gets temporary elevated access and it never gets revoked. A contractor’s key is never rotated. A CI pipeline accumulates more privileges than a senior engineer. Individually, none of these look dangerous. Together, they are the most common reason IAM spirals out of control.

Identity controls are also required by standards including NIST, the CIS AWS Foundations Benchmark, PCI DSS, and ISO 27001. If you operate under FCA supervision or handle UK personal data under UK GDPR, access control is not a recommendation; it is a demonstrable obligation.

The foundational principles: roles over users, temporary over permanent

Always use roles and eliminate long-lived credentials

Long-lived access keys are an audit failure waiting to happen. The attack surface from a leaked static key is enormous compared to a short-lived STS token that expires automatically. IAM roles do not carry standard long-term credentials. When a role is assumed, AWS issues temporary security credentials scoped to that session.

For workloads outside AWS, such as on-premises servers, GitHub Actions runners, or third-party SaaS integrations, use IAM Roles Anywhere. It issues temporary credentials via X.509 certificates rather than requiring you to distribute static keys. The CreateSession API enables workloads running outside AWS to obtain temporary credentials using those certificates.

For human workforce access, the answer in 2026 is straightforward: federate through IAM Identity Center.

Enforce MFA, and use hardware keys for privileged access

Require multi-factor authentication for privileged users and sensitive actions so that compromised credentials alone cannot grant account access. For administrative roles and break-glass accounts, hardware FIDO2 keys are the right call. Virtual authenticators are acceptable for standard users but should not be the ceiling for anyone holding iam:* or AdministratorAccess.

Lock down the root user completely. As of June 2025, AWS enforces root MFA on all member accounts in an Organisation, and centralised root access management lets you remove long-lived root credentials from member accounts entirely. If you are using AWS Organisations, this should already be in place; verify it anyway.

Least privilege: the goal is a pruning loop, not perfect day-one policies

Start broad, then narrow using observed access

Least privilege is not achieved by writing perfect policies on day one. You grant roughly right, then prune what usage data proves unnecessary. IAM Access Analyzer is your primary instrument here. It provides external-access findings, unused-access findings, last-accessed data, and CloudTrail-based policy generation to rewrite grants down to observed reality.

Understand what Access Analyzer will and will not do for you

This is where teams get caught out. Access Analyzer surfaces unused permissions, unused roles, unused access keys, and unused passwords across your AWS environment. What it does not do is remove anything. Every finding is informational. The remediation decision and the remediation work stay with you.

That is a deliberate design choice by AWS, not a flaw. AWS does not want to be in the position of stripping permissions from a customer’s role and taking down a workload nobody flagged. The tool surfaces the data; the customer makes the call.

The practical implication: build a workflow around Access Analyzer findings. Route them to Security Hub, trigger EventBridge rules, and assign ownership to engineering teams. A finding sitting unacknowledged on a dashboard is not a control.

CloudTrail-based policy generation

For active roles, use IAM Access Analyzer’s policy generation feature. It analyses CloudTrail events over a trailing period and produces a least-privilege policy scoped to observed API calls. This is particularly useful when inheriting a legacy account where nobody is sure what a role actually does.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GeneratedLeastPrivilege",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ]
    }
  ]
}

Start with the generated policy, review it against expected behaviour, then attach it. Do not auto-apply generated policies without human review. Access Analyzer can only see what happened during the observation window, not what might happen during an edge case flow.

Organisation-wide guardrails: SCPs and RCPs

Service Control Policies are the mechanism by which you enforce minimum security standards that individual account teams cannot override. They are your organisation’s security floor: no matter what IAM policies exist in member accounts, certain actions are always blocked.

In November 2024, AWS introduced Resource Control Policies as a new policy type in AWS Organisations. SCPs restrict what principals can do; RCPs restrict what can be done to resources. In 2026, you should be designing your guardrails using both: SCPs to control what your identities can do, RCPs to control how your resources can be accessed.

A foundational SCP to restrict actions to approved AWS regions, a common FCA and data residency requirement, looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "sts:*",
        "support:*",
        "organizations:*",
        "cloudfront:*",
        "route53:*",
        "waf:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-west-2",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

Note the NotAction carve-outs for global services. IAM, STS, and Route 53 are region-agnostic and will break in unexpected ways if you omit them. Do not attach region-denial SCPs at the root OU without staging them through a sandbox account first.

What is new in IAM: August 2026

IAM role manager

Configuring roles and policies for common patterns is repeatable work that does not need to be manual. Announced this month, IAM role manager handles the scaffolding that previously required engineers to context-switch into the IAM console mid-deployment.

What role manager adds is a single account-level control, including coverage for a case that built-in flows cannot handle: tasks whose permissions AWS cannot determine in advance, such as running your own code. For those tasks, role manager provisions a role that you can narrow later.

The role comes from an AWS managed role template: a definition AWS builds and maintains for a specific task, with the trust policy and permissions already worked out. The console calls a new IAM API, AcquireRole, which finds the matching template, provisions the role from it, and returns it to EventBridge. Depending on the service, AcquireRole either creates a new role or reuses one that already fits, so an account does not accumulate duplicate roles for the same task.

The roles created are ordinary IAM roles that you can view, edit, or delete like any role you author yourself. In an organisation, administrators can use an SCP to control whether member accounts can enable or use role manager. That SCP-level gate is the right approach for regulated environments: enable role manager selectively, not by default across all OUs.

Account access manager

AWS IAM launched account access manager to streamline assignment of IAM roles to workforce users. Administrators use it to assign IAM roles in their AWS accounts to workforce users and groups in IAM Identity Center. This closes a long-standing gap between the two dominant access management approaches, giving you the single federation point and user awareness of IAM Identity Center alongside the flexibility of IAM roles.

Account access manager is available at no additional cost in all AWS commercial regions enabled by default.

IAM principal cost allocation for Bedrock

This sits at the intersection of IAM and FinOps, but it matters architecturally. Amazon Bedrock now supports cost allocation by IAM principal, including IAM users and roles, for model inference requests made through the bedrock-mantle endpoint. This extends capability previously available only for the bedrock-runtime endpoint, and helps customers attribute inference costs across users, teams, projects, and applications.

You can tag IAM users and roles with attributes such as team, project, or cost centre, activate them as cost allocation tags, and analyse bedrock-mantle inference costs by those tags in AWS Cost Explorer or at line-item level in CUR 2.0. The implication: your IAM tagging strategy is no longer just a security and governance concern. It is a direct input into your AI spend attribution model. Get your tagging taxonomy right early.

Common IAM pitfalls to avoid

These are the patterns I see repeatedly in architecture reviews and post-incident work.

Wildcard actions on scoped resources. "Action": "s3:*" on a specific bucket is not least privilege. It includes s3:DeleteBucket, s3:PutBucketPolicy, and other destructive operations. Be explicit about the action list.

Trust policies that are too broad. A trust policy with "Principal": {"Service": "lambda.amazonaws.com"} and no Condition block will allow any Lambda function in any account (if cross-account trust is granted) to assume the role. Add aws:SourceAccount or aws:SourceArn conditions to scope trust relationships tightly.

Archiving Access Analyzer findings without remediating. Archiving a finding makes it disappear from the dashboard. It does not remove the underlying permission. If you are using archive rules to suppress known-good findings, establish a process to validate those suppressions are still accurate on a quarterly basis.

SCPs on the management account. SCPs do not protect the management account. For protecting your management account from security risks, use AWS delegated administrators for service management instead. Anything security-sensitive should live in a dedicated security account.

Treating IAM configuration as immutable infrastructure. Permissions drift. Roles accumulate actions. Access Analyzer surfaces unused roles, keys, passwords, and permissions, but it does not remove them. Automate the detection; do not leave remediation entirely manual.

Over-permissive CI/CD roles. GitHub Actions, GitLab runners, and CodeBuild projects routinely hold more permissions than they need because it is quicker to grant broadly and ship. Use OIDC federation for CI/CD identity rather than static keys, and scope the assumed role to the minimum needed for the specific pipeline stage.

Key takeaways

  • Roles and temporary credentials are non-negotiable. Eliminate static access keys for human users and machine identities alike. Use IAM Roles Anywhere for workloads outside AWS rather than distributing long-lived keys.
  • Least privilege is a pruning loop, not a day-one achievement. Use IAM Access Analyzer’s unused-access findings and CloudTrail-based policy generation on a quarterly cycle. Findings are informational; you must build workflows to act on them.
  • SCPs and RCPs are your organisation’s guardrails. Deploy region-restriction and root-user-denial SCPs at the OU level. Complement them with RCPs to control resource-side access. Test all SCPs against a sandbox account before broad rollout.
  • Adopt IAM role manager and account access manager. Both launched in August 2026, are available at no additional cost, and reduce the manual scaffolding that leads to over-permissive one-off roles. Gate role manager access with an SCP in regulated OUs.
  • Tag IAM principals deliberately. With Bedrock IAM principal cost allocation now extended to the bedrock-mantle endpoint, your tagging taxonomy feeds directly into AI spend attribution. Team, cost-centre, and project tags on roles are infrastructure, not metadata.
  • MFA on every human identity, hardware keys for privileged access. Root MFA is now AWS-enforced in Organisations. Go further: enforce MFA as a condition in permission boundaries for any role with administrative capability.