01The 'Multi-Account' Identity Nightmare
A few years ago, I was helping a team that had grown into a dozen AWS accounts. Every developer had a unique IAM user in every single account. When someone joined, we spent an hour manually creating users in twelve different consoles. When someone left, we spent two hours hunting down and deleting their credentials, praying we hadn't missed one that still had an active access key. One afternoon, an SRE was locked out of the production account because they forgot which of their twelve passwords they had last updated. They reset the password, but in the hurry, they used the wrong console URL. That was the day I realized that managing local IAM users across accounts isn't just inefficient; it is a security vulnerability waiting to happen. You don't have a multi-account strategy; you have a distributed identity disaster.
02Why Local IAM Users Are a Security Liability
Local IAM users belong in an era where you had one or two AWS accounts. In a modern, multi-account environment, they are the primary source of 'credential sprawl.'
The Failure Modes of Distributed Identity:
- Credential Persistence: Because users have long-lived credentials in multiple places, rotation becomes a pipe dream. Nobody rotates twelve sets of access keys on a monthly basis.
- Inconsistent Permissions: Keeping permissions in sync across accounts requires Herculean effort. You end up with 'drift,' where a developer has 'admin' in development but is missing basic 'read' access in staging.
- The 'Offboarding' Gap: If you miss one account during offboarding, you leave behind an active entry point into your infrastructure. Attackers love finding these orphaned accounts with legacy access.
- Lack of Visibility: You cannot audit your entire infrastructure's access from one screen. You are effectively flying blind.
03The Centralized Pivot: Organizations and Identity Center
AWS Organizations allows you to group accounts into a logical hierarchy, but it does not solve the identity problem on its own. That is where AWS IAM Identity Center (formerly SSO) comes in. It acts as the single source of truth for your users. Instead of creating users in AWS, you connect Identity Center to an external identity provider (IdP)—like Okta, Azure AD, or Google Workspace. When you hire someone, you add them to your corporate directory, assign them to a group, and Identity Center handles the rest. You stop managing AWS accounts; you start managing corporate groups.
04Configuring the Centralized Path
If you want to move away from local users, you must automate the relationship between your directory and your accounts. Use Infrastructure as Code to define your permission sets. Never click through the AWS console to manage access. Centralizing access ensures that 'Read Only' means exactly the same thing in every account. If you need to upgrade the permission set, you update your configuration, and every account in your organization gets the update instantly.
05What I Actually Do / My Take
I have a hard rule in every architecture I touch: No local IAM users in any production or staging account. If I find a local user account, I treat it as a critical security finding.
My standard playbook for multi-account identity:
- Zero Trust for Console Access: I enable hardware MFA (like YubiKey) for every single user in the IdP. If the IdP doesn't support YubiKey, we find a different IdP. No SMS, no app-based TOTP if we can avoid it.
- Group-Based RBAC: I map specific groups (e.g., 'SRE', 'SecurityAdmin', 'DevReadOnly') to specific Permission Sets. Developers are never 'Admins' in production; they are 'DevOps' with just enough access to debug logs and metrics.
- Short-Lived Sessions: I set the session duration to 2 hours. If a developer needs access, they authenticate via their IdP, get a temporary session, and it expires. No persistent access keys exist on their local machine.
- Automated Cleanup: I run a weekly script using the AWS CLI to check for the existence of IAM users in member accounts. If an account is created manually, the script alerts the security team, and the console is automatically restricted.
- The 'Break-Glass' Account: I do keep one break-glass account for the root user, but the credentials are encrypted, printed, and placed in a physical safe, with the root email tied to an alias that goes to the entire security leadership team.
Stop treating your AWS accounts as islands. You aren't building a server rack; you're building a cloud foundation. Centralizing identity isn't just about 'cleaning up'—it's about removing the biggest, most predictable hole in your security posture.
06Closing / TL;DR
Managing local IAM users across multiple accounts is a security nightmare that doesn't scale. Stop creating users in every account and centralize your identity using AWS IAM Identity Center and an external IdP. Codify your permissions, enforce MFA, and stop the madness of credential sprawl.