Replacing IAM Admin Users with AWS IAM Identity Center (SSO) *

Replacing IAM Admin Users with AWS IAM Identity Center (SSO)

In the early days of an AWS setup, most teams create a single IAM admin user to avoid using the root account.It works, but as your environment grows, static credentials and scattered permissions quickly become unmanageable.The modern, recommended path is to move to AWS Organizations with IAM Identity Center (formerly AWS SSO).

Here's how to retire your legacy admin user safely while keeping full control of your AWS environment.

Why Replace IAM Admin Users?

Old Pattern (IAM User)Modern Pattern (IAM Identity Center)

One admin user per account

Centralized access across all accounts

Long-term credentials (keys/passwords)

Temporary, automatically rotated credentials

Separate MFA per user

Central MFA enforcement

Hard to audit

Centralized access logs

Manual user creation

One directory for everyone

In short, IAM Identity Center turns AWS access into an enterprise-grade single sign-on experience.

1. Secure the Root Account

Keep the root user as an emergency backup only.

• Enable MFA.
• Remove any access keys.
• Add alternate billing and security contacts.
• Store the credentials in a secure password manager.

The root account should be used only for payment methods or account-closure actions.

2. Enable AWS Organizations and IAM Identity Center

1. From the management account, enable AWS Organizations.
2. Turn on IAM Identity Center and link it to the organization.
3. Record your new access portal URL:

   https://yourcompany.awsapps.com/start
   

This portal becomes your single login point for every AWS account.

3. Create SSO Users and Permission Sets

1. In IAM Identity Center → Users, add yourself and any teammates.
2. • Use work email addresses.
   • Send invitation emails for password setup.
3. In Permission sets, create a predefined set using AdministratorAccess.
4. • You can later add limited roles such as ReadOnlyAccess or DeveloperAccess.
5. Assign users to accounts and permission sets:
6. • Select your users.
   • Select target accounts (management, dev, staging, prod).
   • Attach the desired permission set.

After this, each user can choose which account and role to open directly from the SSO portal.

4. Test the New Workflow

1. Visit the portal URL and sign in with your email and MFA.
2. You'll see tiles for each AWS account with roles like AdministratorAccess.
3. Clicking a tile opens that account's console instantly—no static passwords, no key management.

5. Use SSO for the CLI

Developers can deploy through the CLI using temporary credentials:

aws configure sso
# Enter portal URL, region, account ID, and role name
aws sso login --profile dev

All credentials are short-lived and automatically refreshed—no more long-term keys in .aws/credentials.

6. Handle Automation with Roles, Not Users

For CI/CD pipelines, create dedicated IAM roles inside each account.Grant only the permissions required for deployments or builds.Pipelines assume those roles programmatically (via OIDC or AWS CodePipeline) instead of using human credentials.

7. Retire the Legacy IAM Admin User

Once you verify that:

• You can log in via SSO.
• You have full access to every needed account.
• No scripts depend on the old admin's keys.

Then:

1. Delete the admin user's access keys.
2. Disable its console sign-in.
3. Optionally delete the user entirely.
4. (Optional) Create a Break-Glass Admin Role that only the root user can assume for emergencies.

8. The End State

When you're done, your AWS access model should look like this:

• Root user — Used only for critical account operations such as billing updates, payment method changes, or emergency recovery. Keep it protected with MFA and never use it for daily administration.
• IAM Identity Center (SSO) — Used for all day-to-day administrative work. This is where you and your engineers log in through the SSO portal, pick an account, and assume the AdministratorAccess or other assigned roles.
• Automation roles — Used for your CI/CD pipelines and application deployments. Each environment (for example, dev, staging, or production) has its own IAM role with just the permissions needed to deploy and run workloads.
• Break-glass role — A special IAM role that can only be assumed by the root account in case of emergencies when SSO is unavailable.

Together, these roles create a clear and secure separation between human access, automation, and emergency recovery.

Final Thoughts

Deleting your old IAM admin isn't a loss of control—it's a promotion to a cleaner, safer architecture.By adopting IAM Identity Center, you gain:

• Centralized, auditable sign-on for all AWS accounts.
• Automatic MFA enforcement.
• No static credentials to rotate or leak.
• Consistent CLI and console experience across environments.

This shift brings your AWS environment in line with the Well-Architected Framework's security pillar—least privilege, centralized identity, and short-lived credentials by design.

How to Configure AWS CLI with IAM Identity Center

Once IAM Identity Center (SSO) is in place, you can connect the AWS CLI directly to your SSO login.This replaces the old aws configure flow that relied on static credentials.

1. Run the setup command:

   aws configure sso
   

2. When prompted, enter the following values:

   SSO start URL [None]: https://yourcompany.awsapps.com/start
   SSO region [None]: us-east-2
   SSO account ID [None]: 111122223333
   SSO role name [None]: AdministratorAccess
   CLI default client Region [None]: us-east-2
   CLI default output format [None]: json
   CLI profile name [None]: dev
   

3. Authenticate your session:

   aws sso login --profile dev
   

4. Verify that your CLI session is using temporary SSO credentials:

   aws sts get-caller-identity --profile dev
   

   You should see your AWS account ID and a federated identity—no access keys needed.
5. Deploy your app or run any AWS command:

   aws s3 ls --profile dev
   aws cloudformation deploy --template-file template.yml --stack-name myapp --profile dev
   

All credentials are short-lived and automatically refreshed when you run aws sso login again.This eliminates the need for static credentials, improves security, and keeps your workflow simple.