AWS IAM Identity Center: Complete Guide to Centralized Identity

Managing workforce access across multiple AWS accounts using individual IAM users is a security risk that doesn't scale. You end up with long-term access keys scattered across accounts, duplicated user management, and fragmented audit trails. AWS IAM Identity Center solves this with centralized single sign-on, temporary credentials, and unified access management across your entire AWS Organization.

In this guide, you'll learn everything you need to implement IAM Identity Center: how it works, identity source options, permission set configuration, security best practices, and the troubleshooting knowledge that official documentation assumes you already have.

What is AWS IAM Identity Center?

AWS IAM Identity Center is a centralized workforce identity management service that provides single sign-on (SSO) access to multiple AWS accounts and business applications. If you've heard of AWS Single Sign-On (AWS SSO), it's the same service, just renamed in 2022.

The service integrates with AWS Organizations for multi-account management and supports multiple identity sources: its built-in directory, Microsoft Active Directory, and external identity providers like Okta, Microsoft Entra ID, Ping Identity, JumpCloud, and Google Workspace.

Here's the best part: IAM Identity Center is available at no additional cost in all AWS commercial, GovCloud, and China Regions where it's supported. You're only paying for associated services like KMS if you choose customer-managed encryption keys.

Core Capabilities

IAM Identity Center provides several capabilities that make workforce access management practical:

• Integration with AWS managed applications: Amazon Q, AWS CLI, Amazon Redshift, and other AWS services that support workforce identity federation
• Trusted identity propagation: Pass user identity context to downstream AWS services for user-aware access control and auditing
• Centralized permissions management: Define permission sets once and assign them across multiple accounts
• Single point of federation: Connect your corporate identity provider once, then manage access through IAM Identity Center
• User-friendly access portal: Users get a web portal showing all their assigned accounts and applications in one place

Organization Instances vs Account Instances

IAM Identity Center supports two deployment models, and this distinction matters:

Organization Instances (Recommended):

• Enabled in your AWS Organizations management account
• Supports all IAM Identity Center features including multi-account access
• Only one organization instance per management account
• Provides centralized control and full feature support

Account Instances:

• Bound to a single AWS account and Region
• Cannot support permission sets for AWS account access
• Cannot be converted to or merged with organization instances
• Useful only for isolated application deployments or trials

For any serious multi-account implementation, you want an organization instance. Account instances exist for edge cases where you need isolated application authentication without organization-wide identity management.

Why Use IAM Identity Center?

Before diving into implementation details, let's address why this matters for your AWS environment. If you're managing multiple AWS accounts (and you should be following a multi-account strategy), IAM Identity Center fundamentally changes how you handle workforce access.

Benefits Over Traditional IAM Users

The security improvement alone makes IAM Identity Center worth adopting. Temporary credentials that expire after a few hours are dramatically safer than long-term access keys that developers might accidentally commit to repositories or leave in environment variables.

When to Choose IAM Identity Center

IAM Identity Center makes sense when:

1. You have multiple AWS accounts: If you're operating within AWS Organizations (and you should be for anything beyond a single development account)
2. You have existing corporate identity: Active Directory, Okta, Entra ID, or any SAML 2.0 compatible identity provider
3. You need SSO to AWS managed applications: Amazon Q, Redshift, SageMaker Studio, and other services that support workforce identity
4. You want to eliminate long-term access keys: Temporary credentials reduce your security exposure
5. You need a centralized audit trail: Single location for who accessed what, when

The main scenario where IAM Identity Center doesn't fit is for service-to-service authentication, AWS service roles, or programmatic access from applications. Those use cases still require traditional IAM roles.

How IAM Identity Center Works

Understanding the architecture helps you make better implementation decisions. IAM Identity Center sits between your identity source and your AWS accounts, managing authentication and authorization.

Architecture Overview

The Authentication Flow

When a user accesses AWS through IAM Identity Center, here's what happens:

1. User navigates to the AWS access portal URL (your custom subdomain.awsapps.com)
2. Redirected to identity source for authentication (password + MFA if configured)
3. SAML assertion returned to IAM Identity Center after successful authentication
4. Portal displays assigned accounts and permission sets the user can access
5. User selects an account and role, triggering STS AssumeRoleWithSAML
6. Temporary credentials issued with duration based on permission set configuration (1-12 hours)

This flow ensures users never need long-term credentials. Every session is temporary and tied to their authenticated identity.

Identity Sources and Federation

Your identity source determines where user accounts live and how authentication works. IAM Identity Center supports only one identity source per organization instance, so choose carefully.

IAM Identity Center Directory (Built-in)

The built-in directory is the default when you first enable IAM Identity Center. You create and manage users directly in the IAM Identity Center console.

When to use it:

• Organizations without existing corporate identity providers
• Small teams that don't need IdP integration
• Testing and proof-of-concept deployments

Limitations:

• Does NOT support nested groups
• You manage MFA within IAM Identity Center (up to 8 devices per user)
• No automatic synchronization with external systems

Microsoft Active Directory Integration

Connect IAM Identity Center to AWS Managed Microsoft AD or self-managed Active Directory through AWS Directory Service.

Key requirements:

• Directory must be in the same AWS Region as IAM Identity Center
• Uses pass-through authentication (passwords never stored in AWS)
• Limited to one connected directory (cannot be increased)
• Users from 4+ domains must use DOMAIN\user syntax when signing in

What's NOT supported:

• SAMBA 4-based Simple AD
• Foreign Security Principals synchronization

This option works well when you have existing AD infrastructure and want to leverage it for AWS access without deploying a separate identity provider.

External Identity Providers (SAML 2.0)

For organizations using Okta, Microsoft Entra ID (formerly Azure AD), Ping Identity, JumpCloud, or Google Workspace, external IdP integration is typically the best choice.

How it works:

• Users authenticate through your corporate IdP via SAML 2.0
• MFA is managed by the external IdP, NOT IAM Identity Center
• Users and groups must be provisioned into IAM Identity Center before you can assign them permissions

Supported provisioning methods:

• SCIM v2.0 (automatic, recommended)
• Manual provisioning

SCIM Automatic Provisioning

SCIM (System for Cross-domain Identity Management) automates user and group synchronization from your external IdP to IAM Identity Center.

Critical details:

• SCIM access tokens are valid for ONE YEAR. You'll get reminders 90 days before expiration, but if tokens expire, synchronization stops entirely. Set a calendar reminder to rotate tokens before expiration.
• After enabling automatic provisioning, you cannot manually modify users in the IAM Identity Center console. All changes must come from your IdP.
• Unique email addresses required for all users. Duplicate emails will cause provisioning failures.
• Verify the externalId attribute mapping in your IdP configuration to ensure users are correctly matched.

SCIM keeps your IAM Identity Center users in sync with your IdP automatically. When someone joins or leaves your organization, their AWS access follows without manual intervention.

Permission Sets: Defining Access

Permission sets are how you define what users can do in AWS accounts. Think of them as templates that IAM Identity Center uses to create IAM roles in each account you assign them to.

Understanding how permission sets work is essential because they're the primary mechanism for controlling access across your organization.

Understanding Permission Sets

Permission sets are stored centrally in IAM Identity Center and contain:

• AWS Managed Policies: Pre-built policies maintained by AWS (like AdministratorAccess, PowerUserAccess)
• Customer Managed Policies: Policies you create that must exist in every target account
• Inline Policies: Custom IAM policies embedded directly in the permission set
• Permissions Boundaries: Policies that set maximum permissions

When you assign a permission set to an account, IAM Identity Center creates an IAM role with a name starting with AWSReservedSSO_. Users assume this role when they access that account through the portal or CLI.

Key quotas:

• Maximum 500 permission sets per organization
• Maximum 500 permission sets per AWS account
• Maximum 20 managed policies (AWS + customer managed combined) per permission set
• Maximum 32,768 characters for inline policy

AWS Managed vs Customer Managed Policies

AWS Managed Policies are maintained by AWS and ready to attach:

• Quick to assign, no setup required
• AWS updates them when new services launch
• Good for standard job functions (Admin, PowerUser, ViewOnly)

Customer Managed Policies require more work:

• Must exist in EVERY target account with the exact same name
• Policy names must match across all accounts
• You're responsible for keeping them updated

For most organizations, start with AWS managed policies and add inline policies for customization. Customer managed policies make sense when you have complex requirements that need to be consistent across accounts.

Permission Set Session Duration

Control how long users can work before their credentials expire:

• Default: 1 hour
• Minimum: 1 hour
• Maximum: 12 hours

IAM Identity Center creates IAM roles with a 12-hour maximum session duration, but the permission set setting controls the actual session length. Don't set sessions longer than necessary. Shorter sessions limit the window of exposure if credentials are somehow compromised.

Permission Boundaries

Permission boundaries set the maximum permissions that identity-based policies can grant. They're useful for:

• Preventing privilege escalation
• Limiting what delegated administrators can do
• Enforcing organizational security policies

When using a customer managed policy as a boundary, that policy must exist in each target account, just like customer managed policies in permission sets.

AWS Access Portal

The AWS access portal is what your users actually interact with. It's a web-based SSO portal where users see all their assigned AWS accounts and applications.

After authentication, the portal displays available accounts and permission sets. Users click to access the AWS Console or copy credentials for CLI use.

Portal Features for End Users

Users can:

• Launch AWS Console for any assigned account/role combination
• Get CLI credentials for programmatic access
• Reset passwords (for built-in directory users)
• Register MFA devices
• Create shortcuts to frequently accessed resources
• View active sessions

Session management:

• Default session duration: 8 hours
• Configurable range: 15 minutes to 90 days
• Signing out from the portal signs out from all applications
• Closing individual browser tabs keeps other sessions active

Customizing the Access Portal

Administrators can customize:

• Portal subdomain name: Choose something recognizable for your organization
• Session duration: Balance security requirements with user convenience
• Branding: Add your organization's identity

Integrating with AWS Organizations

For multi-account environments, the integration between IAM Identity Center and AWS Organizations is where the real power lies. This is how you manage access at scale.

Multi-Account Access Management

When IAM Identity Center integrates with Organizations:

• Assign users and groups to multiple accounts simultaneously
• Reuse permission sets across any number of accounts
• Changes to permission sets automatically update all assigned accounts
• View all assignments from a single console

This scales far better than creating IAM users in each account manually.

Service-Linked Roles

When you enable IAM Identity Center, AWS automatically creates a service-linked role named AWSServiceRoleForSSO in your management account. This role:

• Can only be assumed by the sso.amazonaws.com service principal
• Allows IAM Identity Center to perform operations within organization accounts
• Enables IAM Identity Center to create and manage IAM roles in member accounts

You don't need to configure this manually, but understand it exists if you're troubleshooting permission issues.

Delegated Administration

For organizations following delegated administrator best practices, you can designate a member account to manage IAM Identity Center. This reduces the need for management account access.

Key constraints:

• Only one delegated administrator at a time
• Delegated administrators CANNOT:
  • Enable or disable IAM Identity Center
  • Delete IAM Identity Center configurations
  • Manage permission sets in the management account
  • Register or deregister other delegated administrators

Delegated administration is a security best practice because it limits who needs access to your management account.

Security Best Practices

IAM Identity Center improves your security posture significantly when configured correctly. Here's how to maximize those benefits.

Multi-Factor Authentication Configuration

MFA is enabled by default for IAM Identity Center directory users. For external IdP users, MFA is managed by your IdP, not IAM Identity Center.

Supported MFA types:

• FIDO2 authenticators: Hardware security keys, biometrics (TouchID, Windows Hello), passkey providers
• Virtual authenticator apps: TOTP applications like Google Authenticator, Authy
• RADIUS MFA: Available when using Active Directory

Device limits:

• Maximum 8 MFA devices per user
• Up to 6 FIDO authenticators + 2 virtual apps

Enforcement options:

1. Require MFA registration at sign-in (default): Users without MFA are prompted to enroll
2. Email one-time password: Codes sent via email (NOT industry-standard MFA)
3. Block sign-in: Users without MFA cannot access the portal
4. Allow sign-in without MFA: Not recommended for production

For external IdP users, configure MFA in your IdP since IAM Identity Center won't manage it.

Session Management and Duration

Balance security with user experience through session configuration:

Best practice: Set the shortest session duration that doesn't disrupt legitimate work. For most organizations, 4-8 hours for interactive sessions and 1-4 hours for IAM role sessions is a reasonable balance.

Audit and Compliance with CloudTrail

All IAM Identity Center API calls are logged in CloudTrail. Recent updates (2025) provide enhanced error messages for troubleshooting provisioning issues.

Key audit capabilities:

• User identity tracked in the OnBehalfOf element of CloudTrail logs
• Integration with trusted identity propagation for user-aware auditing across services
• Automated monitoring of synchronization processes through CloudTrail

For compliance requirements, ensure CloudTrail is configured for organization-wide logging to capture all IAM Identity Center activity.

Getting Started with IAM Identity Center

Ready to implement? Here's the practical path from zero to production.

Prerequisites

Before enabling IAM Identity Center:

1. AWS Organizations with all features enabled: Not just consolidated billing, you need the full feature set
2. Management account access: You'll enable IAM Identity Center from the management account
3. Identity source decision: Know whether you'll use built-in, AD, or external IdP
4. Region selection: IAM Identity Center runs in a single Region, choose carefully

Enabling IAM Identity Center

1. Navigate to the IAM Identity Center console in your management account
2. Select your AWS Region (this cannot be easily changed later)
3. Enable the service
4. Note your AWS access portal URL (you can customize the subdomain)

Region considerations:

• All IAM Identity Center data is stored in the selected Region
• Some AWS managed applications require the same Region
• Switching Regions requires deleting and recreating your instance

Configuring Your Identity Source

Choose one of the three options:

For built-in directory:

• Start creating users and groups directly in the console
• Configure MFA settings for your organization

For external IdP:

• Configure SAML 2.0 federation
• Set up SCIM provisioning for automatic user sync
• Note your SCIM endpoint and generate an access token

For Active Directory:

• Ensure your directory is in the same Region
• Connect through AWS Directory Service

Creating Your First Permission Set

1. Choose predefined (AWS managed) or create custom
2. Attach policies (managed and/or inline)
3. Configure session duration
4. Optionally add permission boundary
5. Assign to users/groups and target accounts

Start with AWS managed policies like AdministratorAccess for your initial admins, then create more restrictive permission sets for regular users.

Developer Integration

Developers care about how IAM Identity Center integrates with their workflows. Here's what you need to know about CLI and SDK usage.

AWS CLI Configuration

AWS CLI v2 supports IAM Identity Center natively. Configure it with:

aws configure sso

This walks you through setting up a named profile with your SSO session. You'll provide:

• SSO start URL (your access portal URL)
• SSO Region
• Account and role to use

Requirements:

• AWS CLI v2 (or v1.27.10+ for limited support)
• For token refresh: AWS CLI v2.9.0 or later

To authenticate:

aws sso login --profile your-profile-name

This opens a browser for authentication, then stores session information locally. Credentials are valid for up to 12 hours based on your permission set configuration.

For detailed step-by-step instructions, see our guide on how to configure the AWS CLI for IAM Identity Center.

SDK Integration

AWS SDKs automatically resolve SSO credentials from your CLI profile. A new SDK plugin (released 2025) streamlines token exchange with external identity providers:

• Available for Java 2.0 and JavaScript v3 SDK
• Automates token exchange for trusted identity propagation
• Eliminates custom workflow code for IdP integration

API Overview

IAM Identity Center provides three API namespaces:

• sso: Single sign-on operations
• identitystore: User and group management
• sso-oauth: OIDC operations (RegisterClient, CreateToken, CreateTokenWithIAM)

For automation, you'll primarily use the identitystore APIs for user/group management and the sso-admin APIs for permission set and assignment management.

Advanced Features

For organizations with sophisticated access requirements, IAM Identity Center offers additional capabilities.

Attribute-Based Access Control (ABAC)

ABAC grants permissions based on user attributes (tags) rather than explicit assignments. This reduces the number of permission sets you need.

How it works:

1. Define attributes in IAM Identity Center (department, cost center, project)
2. Create permission policies using aws:PrincipalTag condition keys
3. Tag AWS resources with matching values
4. Users only access resources where their tags match

Benefits:

• Fewer permission sets to manage
• Access automatically follows organizational changes
• Fine-grained permissions without policy explosion

Prerequisites: If your IAM Identity Center instance was created before December 2020, you'll need to associate additional IAM permissions to enable ABAC.

Trusted Identity Propagation

Trusted identity propagation passes user identity context to downstream AWS services, enabling:

• User-aware access control across multiple services
• Audit trails that show who accessed what data (not just which role)
• Simplified compliance for regulated workloads

Supported services:

• Amazon Redshift
• Amazon EMR (6.15.0+ with Apache Spark)
• Amazon Athena
• Amazon SageMaker Studio
• AWS Glue (5.0+)
• Amazon S3 (via S3 Access Grants)
• AWS Lake Formation
• Amazon OpenSearch Service
• Amazon Q Business

The 2024 single identity context feature simplifies this by allowing applications to use a single IAM role session with the sts:identity_context parameter rather than maintaining two separate sessions.

Service Quotas and Limits

Know the boundaries before you hit them:

For large organizations approaching these limits, you can request quota increases through AWS Support for most resources. The complete IAM Identity Center quotas reference provides the full list.

Regional Considerations

IAM Identity Center runs in a single AWS Region per instance. This decision has long-term implications.

Factors for Region selection:

• User proximity: Lower latency for users closer to the Region
• AWS managed app availability: Some apps must be in the same Region
• Data residency: Compliance requirements may dictate Region choice
• Directory location: Active Directory must be in the same Region

Switching Regions: If you need to change Regions later, you must delete your current instance and recreate everything. This means recreating all users, groups, permission sets, and assignments. Use the APIs to export your configuration before making this change.

Availability design:

• Data plane (sign-in): 99.95% availability target
• Control plane (administration): 99.90% availability target
• Operates across multiple Availability Zones within the selected Region

Common Issues and Troubleshooting

When things go wrong with IAM Identity Center, here are the most common problems and how to resolve them.

SCIM Synchronization Issues

Problem: Users or groups aren't syncing from your external IdP.

Troubleshooting steps:

1. Check SCIM token expiration: Tokens expire after one year. Generate a new token and update your IdP configuration.
2. Verify unique email addresses: Duplicate emails cause provisioning failures.
3. Check required attribute mappings: Ensure externalId and other required attributes are correctly mapped.
4. Review CloudTrail logs: Enhanced error messages (2025) provide specific information about sync failures.
5. Confirm user assignment in IdP: Users must be assigned to the IAM Identity Center application in your IdP to be provisioned.

Permission Set Application Delays

Problem: Users can't access accounts after permission set assignment.

What to expect:

• Permission set changes can take up to 2 hours to propagate
• User group membership changes: Up to 2 hours
• Direct user assignment removal: Within 1 hour

Verification steps:

1. Confirm the IAM role exists in the target account (look for AWSReservedSSO_*)
2. Check if the permission set is correctly assigned to both the user/group AND the account
3. Verify the user is actually a member of the assigned group (for group-based assignments)

MFA Enrollment Problems

Problem: Users can't enroll MFA devices.

Checks:

1. Verify MFA enforcement setting allows self-enrollment ("Users can add and manage their own MFA devices")
2. Confirm the authenticator type is supported
3. For external IdPs: MFA is managed by the IdP, not IAM Identity Center. Check your IdP configuration.
4. Verify user hasn't exceeded the 8-device limit

IAM Identity Center vs Traditional IAM

Still deciding between IAM Identity Center and traditional IAM users? Here's when each makes sense:

Use IAM Identity Center when:

• Managing human access to AWS accounts
• You have multiple AWS accounts
• You have (or plan to have) corporate identity integration
• You want centralized access management and audit
• Temporary credentials are acceptable

Use Traditional IAM when:

• Service-to-service authentication (use IAM roles instead)
• Programmatic access from applications
• Single-account scenarios without SSO requirements
• You need permanent credentials (rare, but sometimes necessary)

For workforce access in any multi-account environment, IAM Identity Center is the better choice. It's more secure, more scalable, and easier to manage as your organization grows.

Wrapping Up

AWS IAM Identity Center centralizes workforce identity management across your AWS accounts at no additional cost. The key concepts to remember:

1. Choose your identity source carefully since you can only have one per organization instance. Built-in works for simple cases, external IdP for enterprise integration.
2. Permission sets define access and automatically create IAM roles in target accounts. Start with AWS managed policies and customize as needed.
3. MFA enforcement and session duration are your primary security controls. Configure them based on your risk tolerance.
4. The AWS access portal provides a unified entry point for users to access all their assigned accounts and applications.
5. SCIM token expiration is a common gotcha. Set reminders to rotate tokens before they expire.

Next steps: If you haven't already, enable IAM Identity Center in your AWS Organizations management account and start with a small pilot group before rolling out organization-wide. Once you're comfortable, integrate with your corporate identity provider for a complete SSO solution.

What's your experience with IAM Identity Center? Have you encountered migration challenges from traditional IAM users? Share your thoughts in the comments.