AWS IAM best practices are still not enough for cloud identities

At a glance

What this is: This is a 12-point AWS IAM best-practices guide that argues cloud identity security depends on tighter control of permissions, access keys, secrets, and auditing.

Why it matters: It matters because AWS programmes increasingly govern non-human access alongside human access, and the same policy drift, secret exposure, and review fatigue can undermine both.

By the numbers:

• With over 90% of organizations using cloud services, identity security is paramount.

👉 Read StrongDM's 12 AWS IAM best practices guide for 2026

Context

AWS IAM best practices are only useful if teams understand the boundary between provider security and customer responsibility. In AWS, the shared responsibility model leaves access control, permission scope, secret handling, and auditing with the customer, which means identity decisions remain the main line of defence for cloud workloads and the humans who manage them.

For IAM teams, the practical issue is not whether the controls exist, but whether they are applied consistently across roles, keys, federation, conditions, and review processes. That becomes harder as environments expand across accounts, regions, and tools, which is why NHI lifecycle control and access governance need to be treated as part of the same programme, not separate workstreams.

Key questions

Q: How should security teams implement least privilege in AWS IAM?

A: Start by mapping each role and policy to a single business function, then remove permissions that are not required for that function. In AWS, least privilege fails when roles become convenient containers for unrelated access. Use role segmentation, policy review, and exception tracking so broad access does not survive beyond the task it was created for.

Q: Why do access keys create persistent identity risk in AWS environments?

A: Access keys are reusable static credentials, so once they exist they can be copied, stored, or forgotten outside the original control path. That makes them harder to govern than federated sessions or role-based access. The risk grows when keys are embedded in scripts, shared across teams, or left active after the need for them has passed.

Q: How do you know if AWS IAM controls are actually working?

A: Look for shrinking standing privilege, shorter access lifetimes, fewer direct credentials, and cleaner audit trails for privileged actions. If reviews keep finding the same stale roles or old keys, the controls are producing paperwork rather than control. Effective IAM shows up in lower entitlement drift and faster revocation when access is no longer justified.

Q: Who is accountable when AWS access is misconfigured or overexposed?

A: Accountability sits with the organisation that owns the identities, policies, and workloads, not with AWS infrastructure security. Under the shared responsibility model, the provider secures the underlying platform while the customer governs access, permissions, and secret handling. That means IAM ownership, policy review, and incident response must be clearly assigned inside the enterprise.

Technical breakdown

Least privilege and IAM roles in AWS

Least privilege means granting only the permissions required for the current task, not the broad access that is convenient at provisioning time. In AWS, roles are the preferred way to package those permissions because they separate identity from static entitlement and make access easier to scope, revoke, and audit. The catch is that role design still depends on good policy boundaries, and those boundaries are often blurred by convenience, inherited permissions, or account sprawl. When roles become catch-all access containers, least privilege degrades into role-based overreach instead of real constraint.

Practical implication: review role scope against actual task needs and remove inherited permissions that are not operationally justified.

MFA, federation, and access keys

MFA strengthens human authentication, but it does not solve all AWS identity problems because it only addresses one hop in the access chain. Federation reduces password and key sprawl by letting users authenticate through trusted external identity providers, while access keys remain a separate risk because they can be copied, reused, and forgotten. The article’s emphasis on secure key handling reflects a deeper identity problem: static credentials are hard to govern once they are distributed to people, apps, and scripts. Centralised access pathways reduce that exposure, but only if keys are not left as a parallel access mechanism.

Practical implication: minimise direct access keys, prefer federated authentication, and enforce MFA on the human entry point.

JIT access, secrets, and audit visibility

Just-in-time access works by making privilege time-bound rather than persistent, which shrinks the window in which credentials can be misused. Secrets management addresses a different problem: how sensitive values such as API keys, passwords, and tokens are stored, rotated, and retrieved without exposing them in code or configuration. Audit logs then provide the evidence layer, showing who accessed what and when. Together, these controls only work when they are connected. JIT without secret discipline leaves standing exposure elsewhere, and logging without access scoping produces records without meaningful containment.

Practical implication: tie ephemeral access, secret storage, and audit review into one operational workflow rather than treating them as separate controls.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AWS IAM best practices are necessary, but they do not close the governance gap created by cloud sprawl. The article correctly points to least privilege, MFA, federation, JIT, auditing, and secrets management, but those controls only work when entitlement data stays current across accounts and workloads. In practice, many AWS programmes still inherit policy drift faster than they can review it, which turns a best-practice list into an incomplete operating model. Practitioners should treat IAM hygiene as a continuous governance process, not a one-time configuration exercise.

Standing access remains the hidden failure mode behind many AWS identity issues. The article’s focus on access keys and JIT access points to a core problem: persistent credentials are easier to misuse than to govern, especially when they live in scripts, shared repositories, or unmanaged tooling. That is the same control gap reflected across NHI governance programmes, where access outlives the task and review happens after exposure. The practitioner conclusion is simple: the longer access persists, the wider the blast radius becomes.

Identity federation reduces sprawl, but only if the lifecycle behind the federated identity is under control. Federation centralises authentication, yet it does not automatically solve entitlement cleanup, role review, or credential retirement. That matters because the governance problem is often not initial access but stale access that remains valid after the original need has passed. Teams should therefore align federation with lifecycle review, offboarding discipline, and policy recertification across both human and non-human actors.

Zero Trust in AWS is not a slogan, it is a control assumption about continuous verification. The article frames Zero Trust as verifying or rejecting every request, which is correct, but the operational test is whether teams can actually enforce context-aware decisions across identities, sessions, and secrets. When AWS estates grow, the hard part is not defining policy language. The hard part is sustaining enforcement across real workloads, so practitioners should measure whether verification remains continuous at scale.

Cloud identity governance increasingly spans human users, service access, and automation, so AWS IAM cannot be managed in isolation. The article reads like an AWS IAM guide, but the controls it names are the same ones that govern service accounts, tokens, certificates, and agent-like workloads. That cross-domain overlap is where modern programmes either mature or stall. Practitioners should build one governance model for all identity types, then tailor enforcement by actor rather than by platform.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge.
• The NHI Lifecycle Management Guide is the right next step for teams that need to connect provisioning, rotation, and offboarding into one governance model.

What this signals

Identity governance in AWS is becoming a lifecycle problem, not just an access-control problem. As cloud estates scale, the control question shifts from who can log in to which identities still deserve to exist, which roles still reflect current tasks, and which secrets still have a valid owner. Teams that pair IAM review with lifecycle governance will have a clearer path to reducing drift across both human and non-human access.

Persistent credentials are the most important design smell in AWS identity programmes. Static keys, old role mappings, and dormant exceptions create hidden access paths that survive long after the original business need has changed. The operational signal to watch is not just volume of access, but how much of that access is still standing when no task is active.

With 88.5% of organisations saying their non-human IAM practices lag human IAM, per The 2024 Non-Human Identity Security Report, the boundary between AWS IAM and NHI governance is already gone. The same controls that manage cloud users now govern service accounts, API keys, and automation secrets. That means the next maturity step is not more policy pages, but one identity model across every actor that touches AWS.

For practitioners

• Map every AWS role to a business task Require each role to answer a simple question: what job does this access enable, and what access is unnecessary for that job. Remove broad inherited permissions that exist only because the account has grown over time.
• Reduce direct access key dependence Use federation and role assumption wherever possible so keys are not the default access path for users, scripts, or shared administrative workflows. Where keys still exist, treat them as monitored exceptions with explicit ownership.
• Make JIT access the default for high-risk AWS actions Time-box elevated access for console, infrastructure, and production changes, then revoke it automatically when the task ends. Pair JIT with logging so the approval, use, and expiry events are all visible in one review cycle.
• Centralise secret storage and rotation Move passwords, tokens, and API keys out of code and into a managed secrets repository, then enforce rotation as part of the deployment and offboarding process. Hardcoded credentials should be treated as a policy breach, not a convenience.
• Review IAM policies on a fixed recertification cadence Compare current permissions against current service ownership, application scope, and account purpose. If a policy cannot be tied to a live operational need, remove it or reassign it before it becomes stale access.

Key takeaways

• AWS IAM best practices only work when identity governance keeps pace with cloud sprawl and role drift.
• Static access keys and stale permissions remain the easiest way for AWS identity control to fail in practice.
• The strongest AWS programmes connect federation, JIT access, secret management, and lifecycle review into one operating model.

Key terms

• Least Privilege: Least privilege is the practice of giving an identity only the permissions required to complete a specific task. In AWS, that means narrowing roles and policies so access is tied to current operational need, not historical convenience or broad administrative habits.
• Federated Access: Federated access lets a user authenticate through a trusted identity provider and then assume access in AWS without relying on long-lived local credentials. It reduces password and key sprawl, but it still requires careful role, session, and lifecycle governance to remain secure.
• Access Key: An access key is a static credential used to authenticate programmatic access to AWS resources. It is useful for automation, but it is also easy to copy, store, and forget, which makes rotation, ownership, and retirement essential to control.
• Just-in-Time Access: Just-in-time access grants privilege only for the period needed to complete a task, then removes it. In cloud environments, it reduces the time an attacker can misuse elevated access, but only if approval, expiry, and audit events are enforced together.

Deepen your knowledge

AWS IAM governance, least privilege, and secret handling are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your AWS programme is trying to manage both human and non-human access at scale, it is worth exploring.

This post draws on content published by StrongDM: 12 AWS IAM Security Best Practices to Know in 2026. Read the original.