Cloud incidents don’t start with breaches.
They start with archaeology.
You open the IAM console.
You scroll.
And there it is:
legacy-service-migration
Access keys: active
Console access: Enabled
Last rotation: never
Owner: unknown
No one remembers why it exists.
No one knows what breaks if you delete it.
So it stays.
This isn’t negligence.
It’s a trophic cascade.
🐺 Apex Trigger: “We’ll Just Create an IAM User”
Every cascade begins with a reasonable decision:
- “We need access for a script”
- “CI needs credentials”
- “It’s temporary”
- “We’ll clean it up later”
An IAM user is created.
Access keys are generated.
The system moves on.
Nothing breaks.
Nothing alerts.
That’s how invasive species enter ecosystems.
🐗 Primary Impact: Long-Lived Identity Enters the System
IAM users don’t expire.
They outlive:
- Scripts
- CI pipelines
- Teams
- Architectural decisions
Fast-forward a few years.
The script is gone.
The migration is done.
The pipeline changed.
The team rotated.
The IAM user remains.
Now you have:
- Credentials with unclear ownership
- Permissions added “just in case”
- No confidence about blast radius
This is identity hygiene debt.
🌿 Secondary Cascade: Hygiene Decay Becomes Normalized
Eventually, 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”
At this stage, security stops being declarative and becomes historical.
“We don’t know why this exists, but it must.”
Unknown identity is worse than no identity.
🌊 Ecosystem Shock: A Real Incident (AWS IMDS)
This fragility is exactly why real-world incidents hurt.
In 2025, An active exploitation attempts tied to CVE-2025-51591 an SSRF vulnerability in the Pandoc document converter.
Attackers submitted crafted HTML designed to force servers to make internal requests — specifically targeting AWS Instance Metadata Service (IMDS) at:
Why IMDS?
Because it can return AWS credentials.
Wiz observed attackers probing metadata paths like:
/latest/meta-data/iam/info/latest/meta-data/iam/security-credentials
In many environments, the attack failed thanks to IMDSv2, which requires session tokens and blocks blind SSRF.
But here’s the uncomfortable question:
What if those workloads relied on static IAM user keys instead of roles?
That’s where the cascade completes.
🧨 When IAM User Hygiene Is Bad, Incidents Become Permanent
There’s a critical difference:
If a role is compromised
- Credentials expire
- Sessions die
- Access collapses naturally
If an IAM user key is compromised
- 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.
🧹 What I Actually Found During an Audit
During a routine IAM review, I found:
- IAM users created in 2016–2018
- Active access keys
- Broad permissions (S3, EC2, IAM)
- No recent CloudTrail activity
- No documentation
- No owner
Deleting them felt risky.
That’s the real failure state:
Inaction feels safer than action.
And that’s how ecosystems rot.
🛡️ The Missing Species: Ephemeral Identity
Modern AWS identity assumes:
- Short-lived credentials
- Clear ownership
- Contextual access
- Automatic expiration
That means:
- IAM roles
- OIDC
- SSO
- IMDSv2 only
- Explicit controls limiting IAM user creation
IAM users should be:
- Rare
- Documented
- Owned
- Audited
- Treated like radioactive material
Not defaults.
🌱 Rewilding the System
Fixing the cascade looks like this:
- List all IAM users
- Identify owners
- Review last usage
- Remove unused keys
- Replace users with roles
- Block new IAM users where possible
- Treat unknown identity as a defect
Yes, something might break.
But something breaking is better than something silently owning your cloud.
🧠 Final Lesson: This Is a Life Choice
Using IAM users in 2026 isn’t about ignorance.
It’s a choice to accept:
- Permanent credentials
- Unbounded blast radius
- Identity archaeology
- Fragile security posture
Cloud failures aren’t sudden.
They’re ecological.
And finding IAM users from 2017 that no one understands anymore
isn’t just technical debt. It’s a warning sign that the ecosystem is already collapsing.
Top comments (1)
Suggestion: give your iam user only the permission to assume a certain role. This way if the credentials leak the attacker can't use it since they need to know what the role name is.
It's some sort of weak two factor