If you’re the administrator or owner of an AWS environment and are still relying on IAM users for your human users to access AWS IAM, then you should be considering migrating to AWS IAM Identity Center. As a security engineer, IAM users should be one of your first targets for review and remediation, because of the risks associated with long-term credentials. If you’re a development team scaling up to using multiple AWS accounts, then getting IDC configured will save you expensive effort and re-work later on.
**AWS IAM Identity Center (IDC, formerly known as “AWS Single Sign-On”) is the AWS service to connect your existing workforce identity source and centrally manage access to AWS.** A centralized approach to identity management is part of a modern access management strategy, because it increases visibility and control for access to your AWS resources, which are critical business digital assets.
Moving away from IAM users to Identity Center is no trivial task, but fortunately it’s one that can be done gradually and safely. This article will give you a step-by-step plan for performing the migration, so you can confidently modernize your AWS access management.
Why Migrate
IAM users suffer from a number of critical security-related drawbacks:
- Credential Risk: Long-lived access keys never expire and are easily exposed through code commits or compromised machines
- No Central Control: Per-account user management creates security blind spots and makes enforcing consistent controls impossible
- Manual Security: Individual MFA and password policy configuration leads to inconsistent standards
- Identity Gaps: No enterprise identity provider (IdP) integration means manual user lifecycle management and the risk of orphaned or lingering accounts
Although IAM users were previously a recommended approach, this is no longer the case. IDC offers a number of improvements over an IAM user-based environment:
In Datadog’s 2024 State of Cloud Security report they found that 46% of the thousands of surveyed organizations still have AWS IAM Users actively in use.
At a high level, the migration consists of four stages that need to be followed:
- Planning the Move
- Set-up Identity Center
- Safe, Staged Migration
- Clean-up for Security
Planning the Move
Planning is critical to a smooth migration. Even if the plan isn’t perfect, the act of planning reduces the risk and improves the likelihood of success.
Timeline
Start by defining the timeline that you’re aiming for, from start of migration to its completion. In this migration, because many critical steps can be performed in parallel, or with a “soft” cut-over, the specific dates are less important than the act of planning itself.
One key part of your plan that is often overlooked is the clean-up process. This phase comes at the end of the project, but is critical for overall success. It should be long enough that you’re comfortable that your changes have been tested completely, without dragging on for too long. Having multiple methods of access increases the complexity of your environment and should be avoided, since complexity has a cognitive and security cost associated with it.
External Dependencies
This stage is the ideal time to prepare your external dependencies. The biggest dependency this migration has is your external identity provider, which you will connect to to provide identity to IDC. IDC supports the main providers, such as Google Workspace, Ping Identity, Microsoft Entra ID, etc. using SAML 2.0 (Security Assertion Markup Language 2.0) (with or without System for Cross-domain Identity Management - SCIM).
Your choice of IdP will usually be determined by what you already have in your organization. If you don’t yet have an IdP, take the time to review the options and pick the right one for your business, as changing IdPs is a much harder and more involved process.
💡IDC has built-in IdP that can be used to store your identities, but this is usually only suitable for smaller-to-medium environments, or as a temporary option.
Communication
Often overlooked, communication of your plan and the important stages in your timeline to the people that it is going to impact is just as important as any technical consideration.
Set-up Identity Center
In almost all cases, you will want to set up an organization instance of IDC. You can have multiple account-level instances of IDC across different AWS accounts, but only one organization instance of IDC. You can never have more than one IDC (organization or account) instance in an account. Account instances of IDC are limited to the account they are provisioned in, so don’t address the single-account limitations of IAM users. An organization instance of IDC can be provisioned in your organization’s management account, or delegated to a dedicated or security-focused account.
Separate from your migration to IDC, Organizations enables security features like service control policies (SCPs), which are a valuable addition to your security posture.
Configure Your IdP
With IDC in place, you can now connect it with your IdP. The exact steps vary depending on your provider, but all the most common vendors are covered in the official documentation.
Define Your Policies
Writing and maintaining your policies is a topic worthy of its own blog post. During the migration, your goal at a minimum should be to replicate existing permissions, so that nothing breaks when you change over.
Audit existing IAM users in all your AWS accounts by generating a credential report. This CSV includes all the important information about your users, such as when their access keys were last accessed, and if they have MFA enabled.
You can also take this time to use services like AWS IAM Access Analyzer to generate policies based on user activity. While this process has limitations (for example, no data plane actions will be included in the resulting policy), it’s a great starting point for your new, role-based policies.
Create Permissions Sets
Once you have policies that replicate the existing permissions your users have, you use them to create a permissions set. These templates allow you to assign policies to users or groups in IDC. The exact groups you have will depend on the different roles in your organization, and how users are organized in your IdP.
You can assign permissions sets to specific users, but just as was the case with IAM users, you should be assigning permissions to groups of users as much as possible, since it reduces complexity and helps implement role-based access control (RBAC). Use group-based access as much as possible, so that you don’t introduce any single points of failure or key person risk in your environment.
Assign Permissions
With the levels of access configured, you can then map your existing IAM users to their new groups, and ensure that the user’s identity is configured accordingly in your IdP. Remember that all human users should be managed through IDC.
Even though it’s slightly confusing, machine users such as CI/CD pipelines or legacy systems are still a valid use case for IAM users. You should ensure that their access is locked-down to the absolute minimum required, as their requirements should not change often. More modern systems should support ODIC federation, for example GitHub Actions.
Safe, Staged Migration
With the configuration in place, you should now be able to start using IDC-based access for day to day tasks. As part of your timeline you should have identified the ideal users and groups to start using the new access. If the users don’t yet exist in your IdP, start by creating them there, and ensuring they receive the expected levels of permissions via permission sets. Your first target should be low-risk access and activities that you can easily monitor for any issues.
A common question online is: Can I use IAM users with AWS IAM Identity Center? The answer is most definitely “yes!” You can use IAM users and Identity Center in parallel, and you should when transitioning from users to IDC. While it’s good to be concerned about breaking your access, you don’t need to worry about this. Users in the context of Identity Center are completely separate from IAM users.
Check for Permissions Errors
It’s almost guaranteed that you’ve missed some permissions with the new configuration. This stage of the migration will likely uncover undocumented requirements or access when things break - this is a good thing! At this stage your users should still have the option to fallback to the old IAM user access methods, so they can quickly unblock themselves. Take the learnings from this and feed them into the new system to make them meet requirements, or change the requirements.
Migrate all Users
Like most migrations, there is huge value in the simplification you get from moving to a new, modern system. The danger is if you don’t complete the migration, and instead increase complexity in your environment by having two similar, competing systems.
💡As part of this, you’ll likely have to change how users access AWS. If you haven’t already, check out the open-source granted CLI to help manage access to multiple AWS accounts, fully integrated with IDC.
Disable old Access
Once your users are actively using the new access methods, you progress the migration by disabling, but not deleting, the old access. For IAM users, you can effectively deactivate them by applying this policy. AWS IAM policy evaluation means that any explicit “Deny” overrides any permissions currently allowed. The nice thing about this approach is that it can be reverted quickly by removing the policy from the user, and doesn’t invalidate the credentials associated with the user. IAM user access keys can also be individually deactivated.
Clean-up for Security
By this stage of the migration, all the hard work is done. You should be confident that the new approach meets your business requirements, and that you have improved and modernized your security posture by moving off long-term credentials. Now you have time to take care of the non-functional aspects of migration.
At this stage you should ensure all documentation is updated in line with the new access patterns and processes, especially for things like on-boarding and off-boarding of users. Emergency access procedures should be understood, documented, and tested.
Delete old Access
Don’t forget to delete the unused IAM users and groups in your AWS accounts. There’s no exact timeframe for this, but make sure you don’t forget to do it, so that you don’t risk old or unauthorized access being retained.
Review Access
Now that the migration is complete, it’s a good time to plan and schedule the on-going maintenance activities, such as user access reviews (UARs). Regular reviews will be easier now that you have a centralized point of access to your AWS accounts, giving increased confidence and reducing the amount of work it takes to stay secure.
💡Want to minimize standing access to your AWS environment? Common Fate provides just-in-time (JIT) access to your AWS and GCP environments, built on top of AWS IAM Identity Center, and self-hosted for security. Start your free trial today, or book a demo to see it in action.
Conclusion
Migrating from IAM users to AWS IAM Identity Center is a strategic move that modernizes your AWS access management while enhancing security. Though the migration requires careful planning and execution, the benefits of centralized identity management, automated user lifecycle management, and reduced credential risk make it well worth the effort. With a staged approach, you can confidently transition your organization to a more secure and manageable access model without disrupting your operations.
