AWS IAM best practices are still not enough for cloud identities

At a glance

What this is: This is a StrongDM blog post arguing that AWS IAM best practices alone still leave cloud identity blind spots because shared responsibility and operational sprawl outpace checklist-based control coverage.

Why it matters: It matters because IAM teams still need to govern cloud access as a lifecycle problem across human users, service access, and privileged workflows, not as a static AWS checklist.

Context

AWS IAM best practices are only as effective as the governance model beneath them. In cloud environments, the same access path can span human users, federated identities, roles, secrets, and time-bound permissions, which means a control checklist can look complete while the actual access surface still expands.

StrongDM's article treats AWS's Shared Responsibility Model as the real boundary condition. AWS secures the infrastructure, but the organisation remains responsible for access control, permissions, and identity governance across the assets it exposes. That is why cloud identity blind spots persist even when teams believe they have implemented the standard IAM controls.

Key questions

Q: What breaks in AWS IAM when teams rely on best-practice checklists alone?

A: Checklist-based IAM fails when the organisation assumes that policy presence equals governed access. In AWS, permissions can be technically correct while still leaving secrets, roles, and federation paths loosely owned. That disconnect creates blind spots in account lifecycle, revocation, and auditability, especially when multiple teams manage different parts of the access path.

Q: Why do long-lived AWS secrets create more risk than role-based access alone?

A: Long-lived secrets persist independently of the business decision that created them, so they can remain valid after the original need has passed. Roles can reduce standing privilege, but if secrets are embedded in automation, code, or unmanaged repositories, the identity still exists and can be abused. The risk is persistence without accountability.

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: What is the difference between federated AWS access and direct credential management?

A: Federated access delegates authentication to an external identity provider and reduces the need to manage separate AWS credentials for every user. Direct credential management ties access more tightly to AWS-issued keys or secrets. Federation can simplify governance, but only if session scope, role trust, and offboarding are tightly controlled.

Technical breakdown

Why shared responsibility leaves IAM gaps in AWS

The AWS Shared Responsibility Model separates infrastructure security from access governance, which is why identity failures often sit outside the cloud provider's direct remit. Least privilege, MFA, roles, and auditing all help, but they do not automatically close the operational gap between policy design and how access is actually used across accounts, consoles, and services. In practice, the problem is not that the controls are absent, but that they are distributed across multiple enforcement points and lifecycle states. Practical implication: treat AWS IAM as a governed operating model, not a one-time configuration exercise.

Practical implication: treat AWS IAM as a governed operating model, not a one-time configuration exercise.

How time-bound access and roles change NHI governance

Just-in-time access and IAM roles reduce standing privilege, but they also change what needs to be governed. A role that is provisioned, assumed, and withdrawn correctly can still become risky if the surrounding access policies, secrets, and federation paths are inconsistent. The identity subject may be a person, but the enforcement surface includes service credentials, session scope, and repository-managed secrets. Practical implication: align role issuance, session duration, and secret handling so that access scope is enforced at the same lifecycle stage across environments.

Practical implication: align role issuance, session duration, and secret handling so that access scope is enforced at the same lifecycle stage across environments.

Why secrets management remains the hardest AWS IAM control

Access keys, API keys, and other secrets are durable identities when they are reused, embedded, or exposed outside a managed repository. Rotation helps only if inventories are complete and revocation is tied to the actual usage pattern, because a forgotten key can still carry valid privilege long after the original need has passed. That is the core NHI problem in cloud IAM: the credential exists independently of the person or process that created it. Practical implication: govern secrets as lifecycle-managed identities, not as static configuration artifacts.

Practical implication: govern secrets as lifecycle-managed identities, not as static configuration artifacts.

Threat narrative

Attacker objective: The attacker objective is to convert legitimate AWS identity into durable access to cloud resources, data, or privileged operations.

1. Entry typically begins through exposed access keys, over-broad IAM roles, or federated identities that were provisioned more widely than intended. Once an attacker or misuse case has a valid AWS identity, the next step is to reach resources that were not meant to be directly accessible.
2. Credential access follows when long-lived secrets, reused keys, or weakly monitored role assumptions provide a durable foothold. In AWS environments, this often means the identity itself is legitimate even when the usage pattern is not.
3. Escalation occurs when that access is combined with additional permissions, poorly scoped trust relationships, or weak separation between accounts and workloads. The result is movement across services or environments that the original access request never justified.
4. Impact is unauthorized access to cloud resources, data, compute capacity, or operational control, often without tripping a single obvious perimeter control. The attacker objective is to turn valid cloud identity into broad, persistent access that outlives the original governance decision.

Breaches seen in the wild

• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud IAM is still being treated as a control checklist when it is really a lifecycle governance problem. Least privilege, MFA, roles, JIT, and secret management all matter, but none of them can compensate for weak ownership of access as identities move across accounts, services, and tools. The article's real lesson is that control presence is not control governance. Practitioners should measure whether access is actually being governed end to end, not whether a best-practice list has been ticked off.

Shared responsibility creates an accountability gap that many cloud programmes still understate. AWS secures the platform, but organisations own the identity layer that touches that platform, including federated users, temporary roles, and machine credentials. That means the hardest failures are not infrastructure failures but misaligned operational responsibilities. The implication is that IAM teams must own cloud access as an internal governance domain, even when the enforcement points sit inside AWS.

Long-lived secrets remain the structural weak point in cloud identity because they outlive the decision that created them. Once an access key, API key, or credential is embedded in automation or code, it becomes an identity artefact that can persist independently of its original business need. That persistence is the source of lateral movement and silent overreach in cloud estates. Practitioners should treat secret sprawl as a lifecycle defect, not just a hygiene issue.

Identity blast radius: the real risk in AWS IAM is not a single misconfigured policy but the cumulative reach of roles, secrets, federation, and audit gaps across environments. This article shows why cloud access should be assessed as a connected system, not as isolated controls. When access paths overlap, the smallest trust mistake can become a much larger privilege problem. Practitioners should design for contained failure rather than assume each IAM control will compensate for the others.

AWS IAM best practices are necessary, but they do not by themselves establish zero trust. Zero trust in cloud identity requires continuous verification, narrow session scope, and governance over how credentials are issued and revoked, not just who can log in. The gap is especially visible where human access, federated access, and non-human credentials intersect. Practitioners should review whether their cloud programme is enforcing trust decisions at runtime or only at provisioning time.

What this signals

Identity blast radius: cloud IAM risk is increasingly about the combined reach of roles, secrets, federation, and review gaps rather than any single misconfigured setting. That means cloud programmes should evaluate access as a connected trust graph, not as isolated line items in a checklist.

AWS-style best-practice guidance often improves the policy layer faster than the operational layer. The practical challenge for IAM teams is proving that revocation, audit, and access scope actually work when identities move between human users, temporary roles, and non-human secrets.

For practitioners

• Map cloud access to lifecycle ownership Assign explicit owners for human, federated, and non-human AWS access so that every role, key, and secret has a lifecycle path from issuance to revocation.
• Inventory long-lived credentials and role trust paths Build a complete inventory of access keys, API keys, role assumptions, and trust relationships across AWS accounts, then classify which ones still exist outside managed rotation or expiry.
• Move enforcement to time-bound access decisions Use JIT access and session limits to reduce standing privilege, but pair them with revocation and audit processes that confirm access actually disappears when the task ends.
• Review secrets as identities, not just configuration Treat any reusable AWS secret as a governed identity with ownership, scope, rotation, and offboarding requirements, especially where automation or CI/CD uses it repeatedly.
• Test cloud access reviews against real usage Compare granted permissions with actual account, role, and secret usage so that review cycles catch hidden privilege that the policy catalogue alone will miss.

Key takeaways

• AWS IAM best practices help, but they do not eliminate the governance gap created by shared responsibility and distributed cloud access.
• The hardest cloud identity failures usually involve durable secrets, broad trust relationships, or access that remains valid after the original task ends.
• IAM teams should focus on lifecycle ownership, time-bound access, and complete credential inventory if they want cloud controls to hold up in practice.

Key terms

• Shared Responsibility Model: A shared responsibility model divides security duties between the cloud provider and the customer. For NHI governance, the provider supplies the platform controls, but the organisation still owns configuration, privilege review, secret handling, monitoring, and lifecycle management of its identities.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Federated Identity: Federated identity lets one organisation trust an external identity provider so a user can access another service without creating a separate account. It simplifies access, but it also expands the trust relationship that must be monitored. Weak federation settings can turn a single compromise into cross-domain access.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.