Switching to AWS IAM Identity Center: What to Expect?

AWS IAM Identity Center (formerly AWS Single Sign-On) offers a centralized way to manage workforce identities and access to AWS accounts and applications. If you're considering moving from traditional IAM users to IAM Identity Center, here’s what will happen during the switch, what it means for your environment, and whether it’s a good idea right now.

I've included many of the questions I had when I was considering this switch which hopefully will assist you in making your decision, if you are already familiar with the feature and have decided to make the switch, just head to the next page.

What Happens When You Switch to IAM Identity Center?

Enabling IAM Identity Center

When you enable IAM Identity Center, AWS sets up a new identity management system in your chosen Region. This doesn’t touch your existing IAM users, roles, or policies—it’s a parallel setup.
You’ll get a default identity source (IAM Identity Center’s built-in directory) unless you connect an external identity provider (IdP) like Active Directory or Okta. You do not need to have an existing directory.
Nothing should break just by enabling it — your current access methods (e.g., IAM user logins, access keys) stay intact.

Transitioning to IAM Identity Center

Over time, you’ll likely shift users from IAM accounts to IAM Identity Center identities. This means:
- New Authentication: Users log in via an SSO portal (a web URL provided by AWS) instead of the AWS Management Console directly with IAM credentials.
- Permission Sets: You define reusable permission sets in IAM Identity Center, which map to IAM roles in your accounts. Users assume these roles via SSO, getting temporary credentials.
- Old IAM Users Fade Out: If you fully adopt IAM Identity Center, you might phase out standalone IAM users, deleting their credentials once SSO replaces them.
Existing programmatic access (e.g., CLI with access keys) won’t work directly through IAM Identity Center—it’s built for human workforce access. You’d need to adapt scripts or apps to use role-based temporary credentials.

Impact on Your Environment

No Immediate Disruption: Enabling it doesn’t break anything. Your IAM users and roles keep working until you decide to change them.
Gradual Shift: As you assign users to IAM Identity Center and they start using SSO, you’ll see a split: some users on the old system, some on the new. Full migration happens when you retire the old setup.
Security Boost: Moving to SSO with temporary credentials reduces risks from static access keys, assuming you enforce MFA via your identity source.
Potential Hiccups: If you misconfigure permission sets, delete IAM users too soon, or lose IdP connectivity, users might lose access temporarily—but this is avoidable with planning.

What Happens to Your Admin or Root User Accounts?

It wouldn't be too helpful if you get locked out of the account you use to enable the feature when you do enable it and that won't happen just by enabling the feature. However you do need to consider the consequences of optionally disabling/removing admin accounts from IAM later. Here’s what happens during and after the switch:

No Immediate Change: Enabling IAM Identity Center doesn’t alter the main admin account’s permissions, credentials, or access. Whether it’s the root user or an IAM admin user/role, it remains fully functional and unaffected.
Continued Access: The main admin account can still log in to the AWS Console, use the CLI, or manage resources using its existing credentials (e.g., root password/MFA or IAM access keys).
Not Automatically Migrated: Unlike other IAM users you might migrate to IAM Identity Center, the main admin account isn’t automatically added to the IAM Identity Center identity store or forced to use SSO. It stays outside the SSO system unless you explicitly include it.
Optional SSO Integration:
- If it’s an IAM user, you could create a matching user in IAM Identity Center’s identity source (e.g., same email) and assign it an "AdminAccess" permission set, then stop using the IAM user login.
- If it’s the root user, it cannot be managed by IAM Identity Center—root users are always separate and don’t use SSO. It is recommended to minimizing root user usage anyway.
Post-Switch Role: After migrating other users to IAM Identity Center, the main admin account remains a fallback or management tool:
- Use it to manage IAM Identity Center itself (e.g., adjust settings, disable it).
- Keep it active as a break-glass account in case SSO fails (e.g., IdP outage).
Decommissioning Option: If the main admin account is an IAM user and you fully transition to SSO, you could delete it after giving its equivalent SSO user admin rights—but don’t delete the root user or leave yourself without admin access.

So should you Enable the Identity Center?

Why it is Likely a Good Idea

Multi-Account Management: If you use AWS Organizations or manage multiple accounts, IAM Identity Center simplifies access across them with SSO and centralized permissions.
SSO for Apps: If you need single sign-on for AWS services (e.g., SageMaker) or third-party tools (e.g., Salesforce) this makes it much easier.
Security Modernization: Replacing IAM users with federated, temporary credentials aligns with AWS best practices.
Scaling: If your team or AWS usage is growing, IAM Identity Center sets you up for easier management down the road.
CLI/SDK Access: The Identity Center makes it easier to work with temporary credentials for CLI/SDK access, improving security and reducing the risk of accidental exposure of long-term credentials.
Future Proof: AWS is moving towards using IAM Identity Center in it's documentation and best practices.

Why It Might Not Be Right Now

Simple Setup: If you’re in a single account with a few users and no SSO needs, traditional IAM is simpler and may be sufficient.
Migration Effort: Switching requires planning—auditing users, setting up permission sets, testing SSO. If you’re not ready to invest time, it could wait.

Is It One-Way? Can You Switch Back?

Not Strictly One-Way: Enabling IAM Identity Center isn’t an irreversible commitment. You can stop using it and revert to your previous IAM setup with some caveats:
- Disabling IAM Identity Center: You can disable it entirely via the AWS Management Console (e.g., in the IAM Identity Center settings). This removes the SSO portal, permission sets, and associated configurations. However, AWS doesn’t delete the underlying IAM roles in your accounts automatically—you’d clean those up manually if desired.
- Switching Back: If you haven’t deleted your original IAM users, roles, or policies, you can simply stop using IAM Identity Center and have users revert to their old logins (e.g., IAM user credentials or existing federation). Access via the SSO portal would stop, but your prior setup remains functional as long as you kept it intact.
- Data Loss Risk: If you fully migrated (e.g., deleted IAM users and relied solely on IAM Identity Center’s directory), switching back means recreating those users or setting up a different system. The IAM Identity Center directory itself can’t be exported easily, so you’d lose any user data stored there unless backed up elsewhere.
Practical Reversibility: It’s fully reversible if you treat IAM Identity Center as an optional layer—keep your old IAM users active during the transition. If you dismantle your old setup completely, “switching back” becomes more of a rebuild than a simple rollback.
Takeaway: It’s not a one-way trap. You can enable it, experiment, and back out without losing your original access, provided you don’t prematurely delete your existing IAM configurations.

Ready to switch?

Switching to IAM Identity Center ultimately moves you toward a more modern, scalable, and secure identity model, but it’s not strictly a must-do. If you are ready to make the switch, continue to the next page.

Making the Switch - Step-by-Step Instructions

This guide provides the steps to switch from a traditional AWS IAM setup (e.g., IAM users with long-term credentials) to AWS IAM Identity Center for managing workforce access. These instructions assume you’re starting with an existing IAM configuration and want to transition to SSO-based access. You’ll enable IAM Identity Center, set it up, and test the system with a a couple of test users to prepare for migration. External directory providers (such as Active Directory) are covered, but will require additional steps not fully explained here.

Step 1: Enable IAM Identity Center

Sign In: Log in to the AWS Management Console with administrative credentials (preferably not the root user).
Navigate: Go to the IAM Identity Center console (search for "IAM Identity Center" in the AWS Console).
Enable: Click the "Enable" button.
Select Region: Your currently selected region will be used for the Identity Center. If this needs to be changed, you should do it now as this in a one-time choice. The recommendation is to select a region closest to most of your AWS users.
Confirm: Click "Enable" to activate IAM Identity Center.

Dashboard Overview

It's worth taking a quick look at a few of the dashboard sections before continuing...

Settings

Location: Left sidebar > Settings.
Identity Source Tab:
Here you can switch to an external IdP (e.g., Okta, Entra ID) or stick with the default directory.
- AWS access portal URL: This is the URL users will use to log in to the AWS Console via IAM Identity Center.
Authentication Tab:
MFA settings and timeouts.

Users & Groups

Users and groups can be fully managed here if using the default directory, or viewed if using an external IdP.

AWS Accounts

A list of all the accounts in your AWS Organization (if enabled) with the ability to assign users or groups to accounts with permission sets (e.g., ReadOnlyAccess).

Permission Sets

Here you can set up predefined permission sets like AdministratorAccess or custom ones for your users and groups.

Applications

Here you can add SAML 2.0 apps (e.g., Salesforce) or AWS-managed apps (e.g., QuickSight) for SSO access.

Step 2: Configure Your Identity Source

By default the built-in Identity Center directory is configured and ready to use. You have the option of connecting to an existing Active Directory or another external provider.

Only if you do have an external directory you wish to use:

Access Settings: In the IAM Identity Center console, go to "Settings" > "Identity source" tab.
Change Identity Source: Under the "Actions" button.
Select Identity Source:
- Identity Center directory: This is the built-in IAM Identity Center directory currently selected.
- Active Directory: Select this to connect to an existing AWS Managed Microsoft AD or AD Connector instance if using AD.
- External identity provider: Select this to connect to a SAML 2.0-compatible IdP (e.g., Okta, Entra ID). You’ll need to exchange SAML metadata between AWS and your IdP.
Set Up:
- For an external IdP, upload the IdP’s SAML metadata file and download AWS’s metadata to configure the IdP side.
- For AD, select the directory and confirm connectivity.
Save: Apply the changes. Note: Changing identity sources later deletes existing users/groups in the current source, so choose wisely now.

Step 3: Creating/Adding Permission Sets for users and groups

We'll create two test users, covering both the default internal directory and an external IdP setup. This will give us a chance to test the SSO and understand the process before using it for production users.

Users to Be Created:

test-user1: A standard user for testing basic AWS account access (e.g., read-only permissions).
test-admin1: An admin user for testing elevated access (e.g., administrative permissions).

Navigate to Users

Log in to the AWS Management Console.
Go to IAM Identity Center (under Security, Identity, & Compliance).
Click Users in the sidebar. It’s empty since it’s newly enabled.

Add Test Users

If using internal directory:
You will need an two valid email addresses you have control over to create both of these users as all users require a unique address. The accounts will get removed after testing so you'll still be able to use your email addresses for a production users later.
1. Select the Users in the left sidebar.
2. Click Add user.
3. For test-user1:
  - Username: test-user1
  - Password: Leave as "Send an email to this user with password setup instructions"
  - Email: An address for a valid email you control
  - First name: Test
  - Last name: User1
  - Display name: Test User1 - Delete after testing SSO
4. Click Next, then Next again, then Add user.
5. Repeat for test-admin1:
  - Username: test-admin1
  - Password: Leave as "Send an email to this user with password setup instructions"
  - Email: An address for a valid email you control
  - First name: Test
  - Last name: Admin1
  - Display name: Test Admin1 - Delete after testing SSO
If using external IdP:
1. Create users in the IdP:
  - In AD: Use AD Users and Computers to add test-user1 and test-admin1 with valid email addresses
  - In SAML IdP (e.g., Okta): Add users via the IdP dashboard with matching attributes (e.g., NameID as username).

Verify User Setup

If using internal directory:
- Check your email for test-user1 and test-admin1. Each gets a temporary password (e.g., X7kP9mQw2) and the AWS access portal URL (e.g., https://d-123abc456.awsapps.com/start).
- Note: Emails may go to spam if the domain isn’t verified.
If using external IdP:
- No email verification is required.

Step 4: Create Permission Sets

Go to Permission Sets in the sidebar.
Click Create permission set.
Ensure Predefined permission set is selected, and select ReadOnlyAccess.
Click Next.
Set a name, e.g., ReadOnlyAccess and click Next and Create.

Now repeat step 4 for but selecting AdministratorAccess rather than ReadOnlyAccess.

Step 5: Assign Access

Reminder: In AWS, an "account" is a top-level container for resources and billing, tied to a unique ID (e.g., 123456789012), not just a user login like in typical IT systems.

Go to AWS accounts in the sidebar.
Select one or more accounts (if you have multiple) to assign the users to.
Click Assign users or groups.

If using internal directory:
1. In Users tab, select our first user test-user1
If using external IdP:
1. In Users or Groups tab, select our first users (test-user1) or IdP groups (e.g., test-users-group). For SAML, users may need to log in first for JIT provisioning.

Click Next
From the list of permission sets, select ReadOnlyAccess
Select Next and Submit

Now repeat step 5 for test-admin1 with the AdministratorAccess permission set.

Step 6: Test the Users

Head back to the AWS access portal URL in a browser, you'll find this in the email you received earlier or under "AWS access portal URL" in the IAM Identity Center if needed.

If logging in using an external IdP, you may need to prefix or postfix your username (e.g. domain\test-user1 or [email protected]).

If using the internal directory, an MFA device will need to be set up once you password is confirmed. You may change the default MFA settings requirement within the IAM Identity Center (Settings > Authentication tab > Multi-Factor Authentication - Configure), however fully disabling MFA is not recommended.

If using an external IdP, MFA will be managed by the IdP.

Once logged on, you'll be presented with the list of accounts you have access to, along with a link to the AWS Console with appropriate access level for the account. Along with access to applications once any are configured.

Step 7: Cleanup

You may now wish to delete our test users and start planning for production users using the same steps.

Migration tips

If you have existing IAM users you can gradually migrate them to IAM Identity Center. The two system co-exist and you can manage users in both systems during the migration process.

It may be a good idea to attach a Deny policy to existing IAM users as part of the migration process to ensure users and services are fully tested with the IAM accounts blocked before fully removing them.

An example policy is given below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

CLI users should ideally move away from using any long term credentials (from standard IAM) and use temporary credentials via aws sso login with the IAM Identity Center portal URL. Further details can be found here

Switching to/Enabling the AWS Identity Center