It’s 2026: Stop Using AWS IAM and Start Using IAM Identity Center

#tutorial #devops #cloud #aws

For over a decade, AWS Identity and Access Management (IAM) users were the standard for accessing AWS accounts. Developers created IAM users, generated Access Keys and Secret Keys, and stored them in ~/.aws/credentials files or, worse, hardcoded them into applications.

It is now 2026. The cloud landscape has matured, and security best practices have evolved. The era of long-lived IAM user credentials should be over. If you are still managing individual IAM users for your team members, you are incurring unnecessary security risks and operational overhead. The modern standard is AWS IAM Identity Center (formerly AWS Single Sign-On). Even though AWS recommended using Identity Center over IAM users for more than 2 years, I still see industry accounts clinging to the same old setup, fearing migration.

This article explores why traditional IAM users are obsolete for human access, the benefits of Identity Center, and how to migrate your organization today.

The Problem with Traditional IAM Users

While IAM users are still necessary for certain service accounts or specific edge cases, they are fundamentally flawed for human access in a modern, multi-account environment.

The Security Risk of Long-Lived Credentials
When you create an IAM user, you typically generate an Access Key ID and a Secret Access Key. These credentials do not expire by default.

Leakage: If a developer accidentally commits these keys to a public GitHub repository, attackers can access your account within seconds.
Rotation Fatigue: Enforcing key rotation policies is manual and often ignored, leading to “stale” keys that remain valid for years after an employee has left or changed roles.
Operational Overhead at Scale
Managing IAM users becomes a nightmare as your organization grows.

Siloed Identities: If you have three AWS accounts (Dev, Staging, Prod), you often end up creating three separate IAM users for the same developer.
Policy Drift: Ensuring that “John Doe” has the exact same permissions across all accounts requires complex synchronization of policies. Instead of fine-grained access, administrators would likely rely on granting broader access levels.
Onboarding/Offboarding: Revoking access requires an administrator to log into every single AWS account and manually delete the user or keys.
Lack of Centralized Visibility
With individual IAM users scattered across multiple accounts, auditing “who has access to what” requires aggregating data from every single account. There is no single pane of glass for workforce identity, so it is easy for mistakes to go unnoticed.

The Solution: IAM Identity Center

AWS IAM Identity Center is the recommended service for managing human access to AWS resources. It builds on the concepts of Single Sign-On (SSO) to provide a centralized, secure, and user-friendly access management system.

Advantages of Identity Center

Short-Term Credentials: Identity Center uses temporary security credentials. When a user logs in, they receive a token that expires automatically (e.g., after 8 hours). There are no permanent access keys to leak.
Centralized Multi-Account Access: You manage users and groups in one place. You can grant the “Developers” group access to 20 different AWS accounts with a single configuration change.
Integration with Identity Providers (IdP): You don’t need to create new users in AWS. Identity Center connects with Microsoft Entra ID (Azure AD), Okta, Google Workspace, or Ping Identity. Users log in with their existing organization credentials.
Improved CLI Experience: The AWS CLI integrates natively with Identity Center. Developers run aws sso login, authorize via their browser, and their terminal is automatically configured with valid credentials.

Setting Up IAM Identity Center (New Setup)

If you are starting fresh, setting up Identity Center is straightforward.

Prerequisites:

An AWS Organization (Not mandatory, but a recommended best practice).
Administrative access to the Management Account.

Step 1: Enable Identity Center

Navigate to the IAM Identity Center console in your Management Account.
Click Enable.
Choose whether to enable it in the AWS Region where your organization is based.

Step 2: Choose Your Identity Source
By default, AWS provides a built-in Identity Store. However, for most businesses, you might have to connect to an external IdP.

Go to Settings > Identity source.
Select Actions > Change identity source.
Choose External identity provider.
Download the AWS metadata file and upload it to your IdP (e.g., Okta or Google Workspace).
Upload your IdP’s SAML metadata file back to AWS.

Step 3: Create Permission Sets
A Permission Set is essentially a managed IAM Policy template.

Go to Permission sets > Create permission set.
Select a Predefined permission set (e.g., AdministratorAccess or ViewOnlyAccess) or create a Custom one.
Define the session duration (e.g., 8 hours).

Step 4: Assign Users to Accounts

Go to AWS accounts.
Select the AWS accounts you want to grant access to.
Click Assign users or groups.
Select the Users/Groups (synced from your IdP) and the Permission Sets they should have. Note: For more streamlined management, create Groups rather than adding individual users to accounts. Once configured, your users will receive a User Portal URL (e.g., https://my-org.awsapps.com/start). They can log in there and see every AWS account they have access to.

Migration Guide: Moving from IAM to Identity Center

Migrating from an existing IAM user base can be challenging, but with proper planning, it can be completed without disrupting workflows.

Phase 1: Parallel Adoption

Set up Identity Center as described above.
Map Permissions: Audit your existing IAM Groups. Create equivalent Permission Sets in Identity Center.
Onboard Teams: Ask a pilot team to start using the aws sso login workflow instead of their Access Keys.

Tip: If you use complex inline policies, when mapping permissions, convert them to Customer Managed Policies so they can be easily attached to Permission Sets (or you can add them directly as an inline policy to the permission set).

Prerequisite: AWS CLI Version 2 is required. You can follow this guide to install or update it.

Developers need to update their local ~/.aws/config files. Instead of static profiles, they will use SSO profiles.
Run the automatic configuration wizard:

aws configure sso

Or manually update the config file:

[profile my-sso-profile]
sso_session = my-session
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-east-1
output = json

[sso-session my-session]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

Phase 2: The “Scream Test” (Soft Deprecation)
Once teams are comfortable with the new login flow:

Identify IAM users that correspond to humans.
Deactivate (do not delete) their Access Keys in the IAM Console.
Wait for complaints. If a script or tool breaks, you can instantly reactivate the key while you help the user migrate that tool to an IAM Role or the SSO workflow.

Phase 3: Cleanup
After a period of stability (e.g., 30 days):

Delete the IAM Users.
Update your onboarding documentation to point strictly to the Identity Center portal.
Implement Service Control Policies (SCPs) in AWS Organizations to prevent the creation of new IAM Users (except for specific break-glass scenarios).

Conclusion

In 2026, the overhead and risk associated with long-term IAM credentials are no longer acceptable. AWS IAM Identity Center provides a robust, scalable, and secure mechanism for managing workforce identity.

By centralizing access, integrating with your corporate IdP, and enforcing short-term credentials, you significantly improve your security posture while simplifying the login experience for your engineers.

Stop managing keys. Start managing identities.