Using IAM Users in 2026 Is a Life Choice

Source: Dev.to

The Hidden Cost of Legacy IAM Users

Cloud incidents don’t start with breaches—they start with archaeology.

You open the IAM console, scroll, and see something like:

legacy-service-migration
Access keys: active
never
unknown

No one remembers why it exists, and no one knows what would break if it’s deleted, so it stays. This isn’t negligence; it’s a trophic cascade.

How the Cascade Begins

1. “We need access for a script.”
2. “CI needs credentials.”
3. “It’s temporary; we’ll clean it up later.”

An IAM user is created, access keys are generated, and the system moves on. Nothing breaks, nothing alerts.

Why IAM Users Outlive Their Purpose

IAM users don’t expire. They outlive:

• Scripts
• CI pipelines
• Teams
• Architectural decisions

Fast‑forward a few years: the script is gone, the pipeline changed, the team rotated, but the IAM user remains. You end up with:

• Credentials of unclear ownership
• Permissions added “just in case”
• No confidence about blast radius

This is identity hygiene debt.

When Temporary Becomes Permanent

Over time, IAM users stop feeling temporary. You start hearing:

• “Don’t touch that one.”
• “It’s probably used somewhere.”
• “We’ll audit later.”
• “It’s been there forever.”

Security shifts from declarative to historical: “We don’t know why this exists, but it must.”

Unknown identity is worse than no identity, and this fragility explains why real‑world incidents hurt.

Real‑World Example: SSRF Exploitation in 2025

In 2025, an active exploitation attempt tied to CVE‑2025‑51591, an SSRF vulnerability in the Pandoc document converter, targeted the AWS Instance Metadata Service (IMDS). Attackers submitted crafted HTML designed to force servers to make internal requests, specifically targeting IMDS at:

• http://169.254.169.254/latest/meta-data/iam/info
• http://169.254.169.254/latest/meta-data/iam/security-credentials

Why IMDS? Because it can return AWS credentials.

Wiz observed attackers probing metadata paths. In many environments the attack failed thanks to IMDSv2, which requires session tokens and blocks blind SSRF.

The Uncomfortable Question

What if those workloads relied on static IAM user keys instead of roles?

That’s where the cascade completes.

• Credentials expire → Sessions die → Access collapses naturally
• Credentials persist → Attackers can return later → Rotation is manual (and often forgotten)

An SSRF is just an entry point; IAM user hygiene determines the blast radius and lifespan.

Findings from a Routine IAM Review

• IAM users created in 2016–2018
• Active access keys with broad permissions (S3, EC2, IAM)
• No recent CloudTrail activity
• No documentation, no owner

Deleting them felt risky. This is the real failure state: inaction feels safer than action, and ecosystems rot.

Modern AWS Identity Assumptions

• Short‑lived credentials
• Clear ownership
• Contextual access
• Automatic expiration

Recommended Controls

• IAM roles instead of users
• OIDC and SSO for federated access
• IMDSv2 only
• Explicit controls limiting IAM user creation

IAM users should be:

• Rare
• Documented
• Owned
• Audited
• Treated like radioactive material (i.e., not defaults)

Fixing the Cascade: A Step‑by‑Step Plan

1. List all IAM users
2. Identify owners
3. Review last usage (CloudTrail, last sign‑in)
4. Remove unused keys
5. Replace users with roles where possible
6. Block new IAM users where feasible (policy guardrails)
7. Treat unknown identity as a defect

Yes, something might break. But a breakage is better than silently owning your cloud.

Conclusion

Using IAM users in 2026 isn’t about ignorance; it’s a conscious choice to accept:

• Permanent credentials
• Unbounded blast radius
• Identity archaeology
• Fragile security posture

Cloud failures aren’t sudden—they’re ecological. Finding IAM users from 2017 that no one understands isn’t just technical debt; it’s a warning sign that the ecosystem is already collapsing.