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.

How to Switch to AWS IAM Identity Center: 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 migrate users while keeping your existing access intact until fully transitioned.

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).
Choose Instance Type:
- For multi-account setups with AWS Organizations, select "Enable with AWS Organizations" (organization instance) from the management account.
- For a single account, choose "Enable" (account instance).
Select Region: Pick the AWS Region where IAM Identity Center will operate (e.g., us-east-1). Note: This is a one-time choice per instance; changing it later requires disabling and re-enabling.
Confirm: Click "Enable" to activate IAM Identity Center. This creates a default identity store and an SSO portal URL.

Step 2: Configure Your Identity Source

Access Settings: In the IAM Identity Center console, go to "Settings" > "Identity source" tab.
Choose Identity Source:
- Default Directory: Use the built-in IAM Identity Center directory (easiest for small setups or testing).
- External IdP: Select "External identity provider" 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.
- Active Directory: Choose an existing AWS Managed Microsoft AD or AD Connector instance if using AD.
Set Up:
- For the default directory, no extra setup is needed—it’s ready to use.
- 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: Define Permission Sets

Go to Permission Sets: In the IAM Identity Center console, select "Permission sets" from the left menu.
Create Permission Sets:
- Click "Create permission set."
- Choose "AWS managed policy" (e.g., AdministratorAccess) or "Custom policy" to match your existing IAM user permissions.
- Name it (e.g., "AdminAccess," "ReadOnly") and set a session duration (default is 1 hour, max 12 hours).
Repeat: Create additional permission sets for different roles (e.g., developers, auditors) based on your current IAM policies.
Review: Ensure these match or improve upon your existing IAM user permissions.

Step 4: Assign Access to AWS Accounts

Navigate: Go to "AWS accounts" in the IAM Identity Center console.
Select Accounts:
- For an organization instance, choose the AWS accounts from your organization.
- For an account instance, it’s just the current account.
Assign Users/Groups:
- Click "Assign users or groups."
- Add users or groups from your identity source (e.g., manually add users to the default directory or sync them from your IdP/AD).
- Select a permission set (e.g., "AdminAccess") to assign to each user/group for the chosen accounts.
Submit: Review and confirm the assignments. This provisions IAM roles in the target accounts linked to IAM Identity Center.

Step 5: Test the SSO Experience

Get the Portal URL: From the IAM Identity Center console, copy the "AWS access portal URL" (e.g., https://d-xxxxxxxxxx.awsapps.com/start).
Share with Users: Provide this URL to a test user (e.g., yourself or a pilot group).
Log In:
- For the default directory, users receive an email invite to set a password, then log in with their email/password.
- For an IdP/AD, users log in with their existing credentials via SSO.
Verify Access: Ensure users can access assigned accounts and permissions via the portal (e.g., click an account role to launch the AWS Console).
Troubleshoot: If access fails, check permission sets, role trust policies, and IdP configuration.

Step 6: Migrate Users Gradually

Add More Users: Assign additional users/groups to permission sets and accounts in IAM Identity Center.
Update Workflows:
- For console users, direct them to the SSO portal instead of direct IAM logins.
- For CLI users, instruct them to use aws sso login with the portal URL (requires AWS CLI v2).
Monitor: Keep existing IAM users active during this phase to avoid disruption.
Validate: Confirm all users can perform their tasks via SSO before proceeding.

Step 7: Decommission Old IAM Users

Audit: Verify all users have migrated to IAM Identity Center and no longer need direct IAM credentials.
Disable Access Keys: In the IAM console, deactivate access keys for CLI/API users one-by-one as they switch to SSO.
Remove IAM Users:
- Go to "Users" in the IAM console.
- Delete IAM users no longer needed, starting with test cases, then scaling to all.
Clean Up: Remove unused IAM policies or roles not tied to IAM Identity Center.

Step 8: Finalize and Optimize

Review Logs: Use AWS CloudTrail to audit SSO logins and ensure compliance.
Enable MFA: In the IAM Identity Center console, under "Settings," enforce MFA if supported by your identity source.
Adjust Permissions: Refine permission sets as needed based on usage feedback.
Disable if Needed: If you decide to revert, go to "Settings" > "Disable IAM Identity Center" (but keep old IAM users until you’re sure).

Notes

Parallel Operation: Existing IAM users work alongside IAM Identity Center until you delete them, so there’s no downtime if phased correctly.
Programmatic Access: IAM Identity Center doesn’t issue long-term keys—use IAM roles with aws sso login for CLI/SDK access.

Switching to/Enabling the AWS Identity Center