Centralized Access Management for Multi-Account AWS Environments
Most AWS environments start the same way. Someone creates an IAM user in the console, generates an access key, and starts building. A second account gets created for staging. Another IAM user gets created there. A third account for production. More IAM users. Before long, you have long-lived access keys scattered across multiple accounts, no centralized view of who has access to what, and no easy way to revoke access when someone leaves the organization.
This is not a theoretical risk. Long-lived IAM access keys are one of the most common causes of AWS security incidents. They get committed to Git repositories, stored in plaintext configuration files, shared over Slack, and forgotten in CI/CD pipelines. When a key is compromised, the blast radius depends entirely on what permissions were attached to it.
AWS IAM Identity Center (formerly AWS SSO) solves this by replacing long-lived IAM users and access keys with centralized single sign-on, temporary credentials, and unified access management across your entire AWS Organization.
IAM Identity Center provides three core capabilities.
First, it gives you a single place to manage user identities. You can create users directly in Identity Center's built-in directory, or you can connect an external identity provider like Microsoft Entra ID (Azure AD), Okta, Google Workspace, or any SAML 2.0 or SCIM-compatible provider. When you connect an external IdP, user provisioning and deprovisioning happen automatically. When someone is removed from your corporate directory, their AWS access is revoked immediately.
Second, it provides single sign-on to all your AWS accounts. Users log in once through the Identity Center portal and see every AWS account they have access to. They click an account, select a role, and get temporary credentials that expire automatically. No access keys. No passwords stored per account. No credential rotation to manage.
Third, it centralizes access management through permission sets. A permission set is a collection of IAM policies that you define once and assign to users or groups across any number of AWS accounts. When you update a permission set, the change propagates to every account where it is assigned. This eliminates the need to manage IAM roles individually in each account.
IAM Identity Center is enabled in the AWS Organizations management account. If you are using AWS Control Tower, Identity Center is enabled automatically as part of the landing zone setup.
The setup process has four steps. First, enable Identity Center in your management account and choose your identity source (built-in directory or external IdP). Second, create groups that map to your organizational roles (Developers, Admins, ReadOnly, SecurityAudit, etc.). Third, create permission sets that define what each group can do. Fourth, assign groups to permission sets in specific AWS accounts.
For example, you might create a "Developers" group, a "PowerUserAccess" permission set (using the AWS managed policy), and assign that combination to your development and staging accounts. The same developers might get a "ReadOnlyAccess" permission set in the production account. All of this is managed from a single console.
Permission sets are the core building block of IAM Identity Center access management. Each permission set becomes an IAM role in every account where it is assigned. When a user assumes that role through the Identity Center portal, they receive temporary credentials scoped to the policies in the permission set.
You can build permission sets from AWS managed policies (like AdministratorAccess, PowerUserAccess, or ReadOnlyAccess), custom inline policies, or a combination of both. You can also set a session duration (1 to 12 hours) and add a permissions boundary to enforce guardrails.
A common pattern is to create a small set of standardized permission sets that cover your main access patterns. For most organizations, four to six permission sets are sufficient: Administrator, PowerUser, Developer, ReadOnly, SecurityAudit, and Billing. Avoid creating per-user or per-project permission sets. That leads to the same sprawl you are trying to eliminate.
For organizations that already manage identities in Microsoft Entra ID, Okta, or Google Workspace, connecting your existing IdP to Identity Center is the recommended approach. This gives you a single source of truth for user identities. When someone joins the company, they get AWS access through their corporate account. When they leave, their access is revoked automatically.
The connection uses SAML 2.0 for authentication and SCIM for automatic user and group provisioning. SCIM is important because it keeps Identity Center's user directory in sync with your IdP without manual intervention. When you add a user to a group in Entra ID, that user automatically appears in the corresponding Identity Center group and inherits the associated permission sets.
If you do not have an external IdP, the built-in Identity Center directory works well for smaller organizations. You manage users and groups directly in the Identity Center console. MFA can be enforced for all users, and you can require specific authenticator types.
IAM Identity Center is not just for console access. The AWS CLI v2 has native support for Identity Center authentication. You configure a named profile in your AWS config file that points to your Identity Center instance, and the CLI handles the authentication flow automatically.
When you run aws sso login --profile your-profile, the CLI opens a browser window for authentication, receives temporary credentials, and caches them locally. Every subsequent CLI command uses those temporary credentials until they expire. No access keys stored anywhere. No credentials in environment variables. No .aws/credentials file to protect.
This also works with AWS SDKs. Any application that uses the default credential provider chain will automatically pick up Identity Center credentials when configured. This is the recommended approach for local development.
If you are running AWS Control Tower, IAM Identity Center is already part of your landing zone. Control Tower uses Identity Center to manage access to all accounts created through Account Factory. When a new account is provisioned, Control Tower automatically creates the necessary IAM roles and assigns them based on your Identity Center configuration.
This integration means that every new account in your organization inherits your access management policies from day one. There is no manual IAM setup required per account. Cloud Einsteins has deployed this pattern for clients managing 12+ AWS accounts, where centralized governance and consistent access controls are critical.
Based on our experience deploying IAM Identity Center across commercial and public-sector environments, here are the practices that matter most.
Use groups, not individual user assignments. Always assign permission sets to groups, never to individual users. This makes access management predictable and auditable. When someone changes roles, you move them to a different group instead of modifying individual assignments.
Enforce MFA for all users. Identity Center supports MFA natively. Require it for every user, including administrators. Use hardware security keys or authenticator apps. SMS-based MFA should be avoided.
Keep permission sets minimal. Start with the least privilege and add permissions as needed. It is easier to grant additional access than to audit and remove excessive permissions after the fact. Use AWS managed policies as a starting point and add custom inline policies only for specific requirements.
Set appropriate session durations. The default session duration is one hour. For developers who need extended access, consider extending to four or eight hours. For administrative access, keep sessions short (one to two hours) to limit the window of exposure if a session is compromised.
Audit access regularly. Identity Center integrates with AWS CloudTrail, so every authentication event and role assumption is logged. Use these logs to identify unused access, detect anomalous login patterns, and verify that access assignments match current organizational roles. AWS Access Analyzer can also identify unused permissions within your permission sets.
Plan your group structure before you start. Changing group structures after deployment is disruptive. Map out your organizational roles, the AWS accounts each role needs access to, and the permission level required in each account before creating your first group.
IAM Identity Center should be the default for human access to AWS accounts. It provides temporary credentials, centralized management, SSO, and audit trails that IAM users cannot match.
IAM users still have a role for service accounts and programmatic access that cannot use Identity Center (legacy applications, third-party integrations that require static credentials). Even in these cases, prefer IAM roles with temporary credentials wherever possible. Use IAM users with access keys only as a last resort, and rotate those keys on a defined schedule.
For CI/CD pipelines, use IAM roles with OIDC federation (GitHub Actions, GitLab CI) or IAM Roles Anywhere (for on-premises systems) instead of IAM users. These approaches provide temporary credentials without storing long-lived secrets.
If you are running a single AWS account with IAM users today, the migration path is straightforward. Enable Identity Center, create groups that match your current access patterns, create permission sets that mirror your existing IAM policies, assign groups to permission sets, and then migrate users one at a time. You can run both systems in parallel during the transition.
If you are setting up a new multi-account environment, start with Identity Center from day one. Combined with AWS Control Tower, it gives you centralized governance, consistent access controls, and a scalable foundation that grows with your organization.
Cloud Einsteins has deployed IAM Identity Center as part of Control Tower landing zones for clients across multiple industries. If you need help setting up centralized access management for your AWS environment, we can design and implement a solution that fits your organization.