The Most Common Pattern I See
Across the AWS environments I've reviewed — financial services, retail, healthcare, telecom — there is one pattern that shows up almost everywhere.
It is not a sophisticated attack vector.
It is not a zero-day vulnerability.
It is IAM.
Specifically, it is IAM configured the way it was configured three years ago, by someone who no longer works there, using a tutorial that was written for a single-account startup.
The most frequent findings:
- IAM Users with long-lived access keys attached to production workloads
- Admin roles without permission boundaries or conditions
- No SCPs enforced at the organization level — because there is no organization level
- Root account used regularly, sometimes for daily operations
- Access keys that have not been rotated in over 400 days
None of this is surprising.
All of it is fixable.
But first, you need to understand why it happens.
Why This Is Not a Skill Problem
When I point out these findings to the teams responsible, the reaction is almost always the same.
They know.
They are not unaware that long-lived access keys are a risk. They have read the AWS documentation. They have seen the warnings in Security Hub. In some cases, they have even flagged it internally, written a ticket, added it to a backlog.
The problem is not knowledge. The problem is context.
AWS documentation, AWS Well-Architected Framework, AWS Security Best Practices — all of it was written assuming a certain baseline:
A dedicated security team.
A mature cloud governance process.
An organization that started with multi-account in mind.
Budget for tooling beyond what comes free with the account.
For most organizations, the reality looks different.
They entered AWS through a single team that needed to ship something fast. IAM was configured to make that happen. There was no time to design a permission model, no security architect on the team, and no organizational structure to enforce standards later.
That is not negligence. That is how cloud adoption actually happens.
Where to Start Without Rewriting Everything
The worst advice I can give someone in this situation is "start over."
Tearing down IAM and rebuilding it properly sounds good in a blog post. In reality, it means production risk, migration work, and political capital you probably do not have.
Here is what I actually recommend as a starting point — a sequence that reduces risk without requiring a full redesign:
Step 1: Stop the bleeding.
Identify every IAM User with an access key that has not been rotated in 90+ days. Rotate or deactivate them. This takes a few hours and removes a real risk immediately.
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
awk -F',' 'NR>1 && $9 != "N/A" { print $1, $9 }'
Step 2: Tag everything you touch.
Before changing any role or policy, add tags. This is how you build the visibility you need to understand what you have before you change it.
Step 3: Enable the basics in Security Hub.
Turn on AWS Foundational Security Best Practices standard. Let it run for a week. Do not try to fix everything — use the findings to build your backlog in priority order.
Step 4: No new IAM Users.
Draw a line. From today, every new workload that needs AWS access gets a role, not a user. Not because roles are perfect, but because the habit of using roles changes how your team thinks about identity.
None of this requires a project. None of it requires approval from three stakeholders.
It requires a decision to start.
What This Problem Is Actually Telling You
IAM misconfiguration is not a technical problem with a technical solution.
It is a signal.
It tells you that cloud adoption happened faster than governance frameworks could follow. It tells you that security was positioned as a blocker rather than an enabler. It tells you that most teams building on AWS have been doing so without the baseline the documentation assumes they already have.
That is the real gap — not skill, not intention. Baseline.
The good news: you do not need a transformation program to close it.
You need a decision, a starting point, and consistency over time.
This article is part of that starting point.
What's Next
In the next article, I will go deeper into the governance layer that prevents these problems from appearing in the first place: AWS Service Control Policies, and how I use them to enforce security guardrails across environments in nine countries.
If you are managing AWS accounts across multiple clients or countries, that one is for you.
[Tags: AWS, IAM, Cloud Security, AWS Security, Cloud Governance, DevSecOps]
