{"slug": "the-iam-mistake-i-keep-finding-in-aws-environments-and-why-it-s-not-your-fault", "title": "The IAM Mistake I Keep Finding in AWS Environments — And Why It's Not Your Fault", "summary": "The article explains that the most common security issue in AWS environments is improperly configured Identity and Access Management (IAM), often set up years ago by former employees using outdated tutorials. The author argues this is not due to negligence but because cloud adoption typically outpaces the development of proper security governance and dedicated teams. The recommended solution is not a complete redesign but a practical, step-by-step approach starting with rotating old access keys and tagging resources.", "body_md": "Across the AWS environments I've reviewed — financial services, retail, healthcare, telecom — there is one pattern that shows up almost everywhere.\nIt is not a sophisticated attack vector.\nIt is not a zero-day vulnerability.\nIt is IAM.\nSpecifically, 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.\nThe most frequent findings:\nNone of this is surprising.\nAll of it is fixable.\nBut first, you need to understand why it happens.\nWhen I point out these findings to the teams responsible, the reaction is almost always the same.\nThey know.\nThey 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.\nThe problem is not knowledge. The problem is context.\nAWS documentation, AWS Well-Architected Framework, AWS Security Best Practices — all of it was written assuming a certain baseline:\nA dedicated security team.\nA mature cloud governance process.\nAn organization that started with multi-account in mind.\nBudget for tooling beyond what comes free with the account.\nFor most organizations, the reality looks different.\nThey 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.\nThat is not negligence. That is how cloud adoption actually happens.\nThe worst advice I can give someone in this situation is \"start over.\"\nTearing 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.\nHere is what I actually recommend as a starting point — a sequence that reduces risk without requiring a full redesign:\nStep 1: Stop the bleeding.\nIdentify 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.\naws iam generate-credential-report\naws iam get-credential-report --query 'Content' --output text | base64 -d | \\\nawk -F',' 'NR>1 && $9 != \"N/A\" { print $1, $9 }'\nStep 2: Tag everything you touch.\nBefore 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.\nStep 3: Enable the basics in Security Hub.\nTurn 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.\nStep 4: No new IAM Users.\nDraw 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.\nNone of this requires a project. None of it requires approval from three stakeholders.\nIt requires a decision to start.\nIAM misconfiguration is not a technical problem with a technical solution.\nIt is a signal.\nIt 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.\nThat is the real gap — not skill, not intention. Baseline.\nThe good news: you do not need a transformation program to close it.\nYou need a decision, a starting point, and consistency over time.\nThis article is part of that starting point.\nIn 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.\nIf you are managing AWS accounts across multiple clients or countries, that one is for you.\n[Tags: AWS, IAM, Cloud Security, AWS Security, Cloud Governance, DevSecOps]", "url": "https://wpnews.pro/news/the-iam-mistake-i-keep-finding-in-aws-environments-and-why-it-s-not-your-fault", "canonical_source": "https://dev.to/mariogongora/the-iam-mistake-i-keep-finding-in-aws-environments-and-why-its-not-your-fault-16oo", "published_at": "2026-05-23 22:06:56+00:00", "updated_at": "2026-05-23 22:32:53.237263+00:00", "lang": "en", "topics": ["cloud-computing", "cybersecurity"], "entities": ["AWS", "IAM", "Security Hub", "AWS Well-Architected Framework"], "alternates": {"html": "https://wpnews.pro/news/the-iam-mistake-i-keep-finding-in-aws-environments-and-why-it-s-not-your-fault", "markdown": "https://wpnews.pro/news/the-iam-mistake-i-keep-finding-in-aws-environments-and-why-it-s-not-your-fault.md", "text": "https://wpnews.pro/news/the-iam-mistake-i-keep-finding-in-aws-environments-and-why-it-s-not-your-fault.txt", "jsonld": "https://wpnews.pro/news/the-iam-mistake-i-keep-finding-in-aws-environments-and-why-it-s-not-your-fault.jsonld"}}