Why Your AWS IAM Setup Is Probably Broken and How to Fix It
- May 4
- 3 min read
IAM - Identity and Access Management - is the single most important security control in any AWS environment. It determines who can access what, under what conditions, and from where. It also happens to be one of the most commonly misconfigured components across Australian AWS environments, from early-stage startups through to established digital businesses.
The pattern is almost always the same. A team gets started on AWS, moving fast, and grants broad permissions to get things done. A developer needs S3 access - they get Administrator Access. An application needs to write to a database - it gets a user with full IAM permissions. Nobody goes back to tighten these up, because the system is working and there are features to ship. Until there's an incident.
The Most Common IAM Mistakes
Over-permissioned users and roles: Using Administrator Access or wildcard (*) actions when scoped permissions would suffice
Shared credentials: Multiple team members using the same IAM user, making it impossible to attribute actions or revoke access for a single individual
No MFA on privileged accounts: Root accounts and administrator users left without multi-factor authentication enforced
Long-lived access keys: Programmatic access keys created, never rotated, and often embedded in code repositories or shared via Slack
IAM users instead of roles: Using IAM users for applications and services rather than IAM roles with instance profiles or service-linked roles
How to Fix It: A Practical Remediation Approach
Fixing a broken IAM setup doesn't need to be disruptive if you approach it systematically. Start with an audit. Use AWS IAM Access Analyser and the Credential Report to understand what exists, what's being used, and what isn't. You'll often find unused users, stale access keys, and roles with far broader permissions than the workload requires.
From there, work through the following steps:
Remove unused IAM users and deactivate credentials that haven't been used in 90 days or more
Enforce MFA on all human users, especially those with administrative access
Replace shared IAM users with individual accounts and use AWS SSO (IAM Identity Centre) for centralised access management
Migrate applications from IAM users with long-lived keys to IAM roles with appropriate trust policies
Define and codify least privilege policies using Infrastructure as Code, so new roles are created consistently and reviewed before deployment
Why This Matters for Australian Teams
For Australian teams handling customer data, IAM misconfigurations carry real regulatory risk. A compromised credential or over-permissioned role can result in a data breach that triggers Privacy Act notification obligations - and the reputational damage that comes with them. More practically, a well-configured IAM environment makes it far easier to pass the security reviews that enterprise customers and partners increasingly require as part of vendor onboarding.
Automating IAM through Infrastructure as Code also prevents the most common source of future drift: ad hoc changes made directly in the AWS Console that are never documented, never reviewed, and gradually accumulate into a security liability. When your IAM configuration is managed in version-controlled Terraform, every change is visible, reviewable, and reversible.
Getting IAM right is not glamorous work. But it's one of the highest-return security improvements you can make - reducing risk, improving auditability, and laying the foundation for every other security control to function as intended.
Habitat3 conducts AWS IAM audits and implements least privilege access frameworks for Australian digital businesses - as part of a broader Landing Zone or security uplift engagement. Talk to a solutions architect at Habitat3!
