What Is IAM Identity Center? Your Company's AWS Login

AWS IAM Identity Center is the company login system for your AWS world: employees sign in with one workforce identity, then see the AWS accounts and applications they are allowed to use. It can use identities stored directly in IAM Identity Center or connect to an existing company directory or identity provider. The counterintuitive part is that IAM Identity Center no longer has to manage AWS account access at all: since August 5, 2026, a new organization instance can be created only for AWS applications, with AWS account management turned on later if you need it.

The name makes this service sound like something only a large security team could love. The day-to-day experience is much simpler. Your employee opens the company’s AWS access portal, signs in, and sees the resources that have been assigned to them.

The clever part is not the login screen. It is everything behind it: where the employee identity comes from, which groups the person belongs to, which AWS accounts or applications those groups can enter, and which permissions apply after entry.

What is IAM Identity Center, really?

IAM Identity Center is AWS’s service for connecting your workforce identities to AWS applications, AWS accounts, or both. A workforce identity means a human who works with your organization: an employee, administrator, developer, analyst, contractor, or another person whose access you manage as part of your company.

That distinction matters because AWS has several identity products, and they solve different problems. IAM Identity Center is not primarily a customer-login service for the users of your shopping app. It is not a place to create a permanent access key for a server. It is the central identity layer for the people in your workforce who need to use AWS.

Suppose Jake owns a small phone shop. His company has grown from one AWS account into four:

• a production account running the booking site;
• a development account where his developer can experiment;
• a security account holding logs;
• and a separate account used for backups.

If Jake creates separate employee credentials independently in each account, the simple setup becomes a maintenance problem. Somebody changes jobs. Somebody leaves. A contractor needs access for two weeks. The developer needs broad permissions in development but only read access in production.

IAM Identity Center lets Jake manage the workforce identity once and then decide where that identity can go.

Ethan puts it more plainly: “The portal is the front door, Jake. Your permissions are the keys. Do not confuse everyone entering through reception with everyone receiving a key to the server room.”

That one distinction will save you from several common IAM Identity Center mistakes. Authentication answers who are you? Authorization answers what may you do? IAM Identity Center helps centralize both parts of the workforce experience, but signing in successfully does not automatically grant permission to every AWS resource.

How the IAM Identity Center login flow works

The visible part of IAM Identity Center is the AWS access portal. That is the web page an employee uses to reach the resources assigned to them.

A custom portal URL can look like:

https://your-company.awsapps.com/start

The exact URL comes from your IAM Identity Center configuration. Administrators distribute that URL to workforce users.

The basic sign-in path is:

1. The employee opens the AWS access portal or starts access through an integrated AWS application.
2. The configured identity source authenticates the employee.
3. IAM Identity Center maps that sign-in to the workforce user known to the service.
4. The service determines which applications, AWS accounts, IAM roles, or permission-set roles the user has been assigned.
5. The portal shows only the resources available to that user.
6. When the employee enters an AWS account, AWS creates a temporary IAM role session with the permissions and duration associated with that access path.

If the company uses the built-in Identity Center directory, IAM Identity Center stores and manages those workforce users. If the company connects an external identity provider, authentication can happen there instead.

This is why an employee can authenticate correctly but still see no AWS account. Login success proves who the person is. It does not prove that somebody assigned them account access.

It is also why resetting the wrong password does nothing. If your company’s identity source is Microsoft Entra ID, for example, changing an unrelated local password in AWS is not fixing the authentication system actually being used.

The AWS access portal is also different from the AWS Management Console. The portal is the personalized launch page that shows the user’s assigned accounts and applications. The AWS Management Console is the collection of consoles used to manage AWS resources after the person enters an account.

IAM vs IAM Identity Center vs Cognito

This is the comparison beginners usually need before anything else. All three products deal with identity, but they solve different identity problems.

IAM does not disappear when you adopt IAM Identity Center. IAM remains the authorization foundation inside AWS accounts.

For permission-set based AWS account access, IAM Identity Center creates IAM roles in the target AWS accounts. Those roles normally have names beginning with AWSReservedSSO_. The employee gets a friendlier centralized login experience, but IAM policies and IAM roles still enforce what the person can actually do.

There is now another AWS account-access option too: account access manager. Introduced on August 10, 2026, it lets administrators centrally assign existing IAM roles in AWS accounts to workforce users and groups from IAM Identity Center.

That matters because the old comparison was often presented as a binary choice: either manage IAM federation separately in every account or use Identity Center permission sets. Account access manager adds a third practical pattern: keep the IAM roles you already designed in your accounts, but assign those roles centrally to Identity Center workforce identities.

Cognito belongs in a different conversation. If Jake builds a customer portal where 50,000 phone-shop customers create accounts, those customers are not suddenly Jake’s AWS workforce. IAM Identity Center is for the people operating the business and using AWS resources or workforce applications. Cognito is designed around application end users.

Which identity source should your company use?

The identity source is where your workforce users and groups are managed.

IAM Identity Center can use its own directory, Microsoft Active Directory, or an external identity provider that integrates using supported standards.

With an external identity provider, two acronyms often appear together: SAML and SCIM.

SAML 2.0 is used for federated authentication. In ordinary language, that is the part that allows the external provider to tell AWS who successfully signed in.

SCIM is used for provisioning users and groups. That is the part that keeps Identity Center aware of the people and groups you want to assign.

They are not two names for the same function. A person can authenticate through the external provider, while Identity Center still needs a corresponding workforce identity to which access assignments can be attached.

Exact console path to view or change the identity source

Open IAM Identity Center → Settings → Identity source.

To change it, choose Actions → Change identity source, select the new source, and follow the configuration flow.

There is an especially nasty timing detail here. Active sessions can survive an identity-source change until their configured session duration expires. Deleting or disabling a user also does not magically guarantee that every independent IAM role session stops that second.

So the safe offboarding question is never just “Did I remove the user?” It is also “What sessions already exist, how long can they live, and which ones can I revoke?”

Organization instance vs account instance

IAM Identity Center has two instance types, and choosing the wrong mental model here causes confusion later.

An organization instance is the full company-wide deployment. It is associated with the AWS Organizations management account and supports the complete centralized feature set, including the organization-level account-access capabilities.

An account instance is narrower. It belongs to one AWS account and Region and is designed for scenarios where an AWS application needs Identity Center functionality in that account without turning the instance into your company-wide account-access system.

AWS Organizations is recommended for IAM Identity Center, but it is not required for every possible use of the service. When you want the complete organization-wide workforce model, however, the organization instance is the normal design.

You can also register one member account as a delegated administrator for IAM Identity Center. The instance still resides in the Organizations management account, but delegated administration lets appropriately authorized administrators perform most Identity Center administration from a member account.

That is useful because the Organizations management account is unusually powerful. You do not want every person who handles normal workforce assignments signing into that account simply because Identity Center was originally enabled there.

The console path for checking the delegated administrator is IAM Identity Center → Settings. In the details or management information, look for the registered delegated administrator account.

Two ways to give employees AWS account access in 2026

This is the part many older IAM Identity Center articles now miss.

For centralized workforce access to AWS accounts, there are two important models to understand:

• permission-set based account access managed through IAM Identity Center;
• account access manager, which centrally assigns existing IAM roles to Identity Center users and groups.

Account access manager was released on August 10, 2026. It fills a real gap.

Before it, a company with an established set of hand-crafted IAM roles often faced an awkward choice. Either keep federating into those roles account by account, or move toward Identity Center permission sets and let the service provision its own managed roles.

Now you can keep the IAM roles and centralize who may assume them.

My recommendation is straightforward: if you are building a new multi-account workforce model and do not have a strong reason to preserve account-specific IAM roles, permission sets give you a clean centralized starting point. If your organization already has mature IAM roles with carefully tuned trust and permission policies, account access manager deserves serious consideration before you rebuild them as permission sets.

What is a permission set?

A permission set is a reusable definition of the permissions a workforce user receives when entering an AWS account through the permission-set model.

Think of it as a badge template.

You might create:

• ProductionReadOnly;
• Developer;
• BillingView;
• and a tightly controlled administrative permission set.

Creating one does not give anybody access by itself. You still assign users or groups to AWS accounts with that permission set.

When Identity Center provisions the assignment, it creates a corresponding IAM role in the target account. If you inspect IAM and see a role beginning with AWSReservedSSO_, that is a strong clue that the role came from an IAM Identity Center permission-set assignment.

The permission set can contain AWS managed policies, customer managed policy references, an inline policy, permissions-boundary configuration, and session settings as appropriate to the design.

The cleanest operating model is normally group based. If all six developers need the same access, assign a Developers group rather than maintaining six nearly identical personal assignments.

Ethan’s rule is: “Give broad freedom where mistakes are cheap, narrow access where mistakes are expensive.” That can mean generous development permissions in a sandbox and sharply restricted production permissions for the same developer.

What employees see after they sign in

For the ordinary employee, IAM Identity Center should feel much less complicated than this article.

They open the AWS access portal and see a personalized set of resources.

That can include AWS accounts, AWS managed applications, and supported cloud applications. For permission-set account access, an AWS account can expose one or more available roles. The displayed role name comes from the permission set.

The employee chooses the account, chooses the role, and can then open the AWS Management Console or obtain temporary credentials for programmatic access.

If account access manager is used, the portal can also expose the AWS account access application, where employees can view IAM roles that have been assigned to them through that model.

A portal therefore does not need to look identical for everyone.

Jake might see Production Read Only and Billing. His developer might see Development Admin and Production Read Only. His bookkeeper might see only the finance-related path. A contractor might see one temporary application and no AWS account at all.

That is the point of the portal: one place to start without one permission set for everyone.

Why does my AWS access portal show no accounts?

Check four things in this order.

1. Is AWS account management enabled for this organization instance? A new application-only organization instance can intentionally have no managed account access.
2. Is the user known to IAM Identity Center? For an external IdP, confirm provisioning as well as authentication.
3. Is the user or one of their groups assigned to an AWS account?
4. Is the expected permission set or IAM role actually attached to that assignment?

Do not start by changing the password if the person has already authenticated successfully. An empty portal is usually an authorization or assignment question, not a password question.

How developers use IAM Identity Center from the AWS CLI

Identity Center is not only a browser login system. It also gives developers a way to use temporary workforce credentials from the AWS CLI and supported SDK tooling.

The normal setup begins with:

aws configure sso

Use the wizard to configure the SSO session and profile information.

For AWS account access, the registration scope commonly used is:

sso:account:access

Then sign in:

aws sso login --profile development

Once the browser authorization is complete, check which AWS identity the profile is actually using:

aws sts get-caller-identity --profile development

This command is much more useful than saying “the CLI seems logged in.” It tells you the account and identity behind the credentials the command is currently using.

When the sign-in needs refreshing:

aws sso login --profile development

To clear cached IAM Identity Center sign-in sessions from the AWS CLI:

aws sso logout

The modern SSO token provider configuration can automatically refresh authentication tokens when the supported CLI or SDK version is being used.

That is a better workforce pattern than teaching every developer to create a long-lived IAM access key and leave it on a laptop indefinitely.

CLI says the session expired but the browser still works

That does not automatically mean Identity Center is broken. The browser access portal session, the cached CLI authentication session, and the IAM role session used for an AWS account have related but separate lifetimes.

Re-run aws sso login for the profile, then run aws sts get-caller-identity. If the result shows the wrong account or role, inspect the profile configuration instead of repeatedly logging in.

IAM Identity Center session duration: the two clocks

There are two different clocks that are easy to mix up.

The first is the user interactive session, which covers the employee’s sign-in to the AWS access portal and connected AWS managed applications. Its default duration is eight hours. Administrators can configure it from 15 minutes up to 90 days.

The console path is IAM Identity Center → Settings → Authentication → Session duration → Configure.

The second clock is the AWS account IAM role session.

For permission sets, the default session duration is one hour. It can be configured from one hour up to 12 hours.

This is why signing out of the portal does not mean every already-created IAM role session instantly disappears.

Once established, an IAM role session can continue independently for its configured duration. That protects long-running CLI work from unexpectedly dying merely because the original portal session changed.

It also means your offboarding procedure has to understand sessions, not only directory status.

What changed in IAM Identity Center in 2026?

The February multi-Region change is important because the old mental model was heavily tied to one primary Region.

For supported configurations, an organization instance can now be replicated to additional Regions. Identities, entitlements, and related information are replicated so workforce users can continue accessing assigned resources through enabled Regions when the feature is configured.

This is not a universal “turn on every Region” switch. Multi-Region support has prerequisites. Active Directory cannot be the identity source for a multi-Region instance, for example.

The August 5 change is conceptually even bigger for beginners.

Previously, enabling an organization instance for AWS managed applications also meant taking on the account-access management model. Now you can configure an organization instance for AWS applications without enabling AWS account management.

If you later need account access, you can enable it from the instance settings rather than recreating the identity system.

Then came account access manager on August 10. That means “we already have the IAM roles we want” is no longer a reason by itself to give up centralized workforce assignment.

How I would set up IAM Identity Center for a company

Do not begin by clicking through screens until something turns green. Decide the access model first.

1. Choose the company-wide instance model. If this is the central workforce identity layer, enable an organization instance rather than scattering account instances across teams.
2. Decide whether AWS account access belongs in this instance. A new organization instance can be application-only. Enable account management only when that is actually part of the design.
3. Confirm the identity source before building users. Open IAM Identity Center → Settings → Identity source. If the company already uses an external workforce IdP, decide whether it should remain the source of truth before creating a large local directory.
4. Configure provisioning. For external providers, make sure the users and groups needed for assignments are provisioned into IAM Identity Center.
5. Create job-based groups. Examples might be Developers, Finance, Security, Support, and Contractors.
6. Choose the AWS account-access model. Use permission sets when you want centrally defined roles, or account access manager when existing IAM roles should remain authoritative.
7. Create narrow permission tiers. Separate development privileges from production privileges instead of cloning one AdministratorAccess assignment everywhere.
8. Assign groups to accounts and applications. Group-based access usually ages better than a pile of personal exceptions.
9. Configure authentication session duration. IAM Identity Center → Settings → Authentication → Session duration.
10. Consider delegated administration. Keep day-to-day Identity Center administration away from the Organizations management account where practical.
11. Pilot with a small group. Confirm that each persona sees exactly the accounts and applications expected.
12. Document offboarding. Include identity disablement, assignment removal, active sessions, and emergency revocation.

That last step is not paperwork for the sake of paperwork. Access systems are easiest to design while everyone still works at the company. The uncomfortable test is: what happens at 4:45 p.m. when somebody’s access must end immediately?

What IAM Identity Center costs and how far it scales

IAM Identity Center is provided at no additional charge.

That sentence has an important boundary around it. The resources and services your users access are not therefore free. An EC2 instance still costs what EC2 costs. A database still bills normally. Customer managed KMS keys used for supported Identity Center features can still incur KMS charges.

Worked example: 80 employees and four AWS accounts

Imagine a company with 80 workforce users, four AWS accounts, and one Identity Center organization instance.

The arithmetic for the IAM Identity Center service itself is:

80 workforce users x $0 additional IAM Identity Center service charge = $0 additional IAM Identity Center service charge

The company still pays for whatever those employees use behind the portal. Identity Center centralizes access; it does not zero out the infrastructure bill.

Current default Identity Center quotas are large enough for ordinary organizations but relevant to automation and very large enterprises.

Large environments should also know the practical management thresholds. Once you are beyond 50,000 users, 10,000 groups, 500 permission sets, or 3,000 applications, AWS points administrators toward CLI and API based central administration rather than expecting every operation to be comfortable as a manual console workflow.

There is another quota hiding underneath permission sets: IAM roles. Permission-set assignments create IAM roles in AWS accounts, and those roles count against IAM role quotas. If an account is already crowded with roles, Identity Center provisioning can run into that account-level IAM limit.

The IAM Identity Center security model I would choose

For human workforce access, centralize identities rather than creating long-lived employee credentials independently throughout every AWS account.

If the company already has a real workforce identity provider, connect it unless you have a deliberate reason to build a separate AWS-only directory.

Use groups for stable job functions.

Use temporary role sessions for AWS account access rather than normalizing permanent IAM access keys for humans.

Separate development, production, finance, and security responsibilities instead of building one company-wide superuser group.

Use delegated administration so fewer people need administrative access to the AWS Organizations management account.

Configure multi-factor authentication in the system that actually performs authentication. When the Identity Center directory is the identity source, IAM Identity Center provides its MFA controls. When an external IdP owns authentication, make sure the corporate authentication policy there provides the MFA posture you expect.

Keep session durations long enough for people to work and short enough that a stolen session does not live forever merely because a 90-day maximum exists.

Audit both identity changes and AWS activity. The portal is only the entry point; it is not the end of the security story.

And document the emergency path. Somebody must know how to respond when the IdP is unavailable, when an administrator accidentally removes a critical assignment, or when an active session must be contained.

IAM Identity Center troubleshooting by symptom

Do not troubleshoot “SSO is broken.” That sentence is too broad to be useful. Name the symptom first.

Permission set changed but the user still sees old behavior

First determine whether you are looking at a newly created session or an existing IAM role session. An old session does not necessarily transform in place merely because an administrator changed a policy centrally.

Next confirm that the permission set has been provisioned to the target account as expected. Finally, verify which role the user actually entered. In a portal with multiple roles, a person can be perfectly authenticated and simply be using the wrong access path.

SCIM user is not appearing

Do not use a successful SAML login as proof that SCIM provisioning is healthy. They solve different parts of the system.

Check whether the user is inside the IdP’s provisioning scope, whether provisioning is succeeding, and whether the corresponding identity appears in IAM Identity Center before trying to attach an account assignment.

Portal works at home but not on the corporate network

If the company filters web traffic through a secure web gateway, proxy, or next-generation firewall, confirm that the domains and URL endpoints required by the AWS access portal are allowed. A network filter can make an identity problem look like a browser or SSO problem.

When nothing works: what to collect before support

If the obvious fix failed, stop making unrelated changes. Record the state while the failure still exists.

For a portal or account-access problem, collect:

• the IAM Identity Center instance type;
• the primary Region;
• whether additional Regions are enabled;
• the identity source;
• whether AWS account management is enabled;
• whether the user can authenticate;
• whether the user and relevant groups appear in IAM Identity Center;
• the AWS account ID involved;
• the expected permission set or IAM role;
• the assignment path, including direct or group assignment;
• the approximate time the failure occurred;
• and the exact error text rather than a paraphrase.

For CLI trouble, add:

• the AWS CLI version;
• the profile name;
• the SSO session name;
• the SSO Region;
• the configured account and role;
• the result of aws sts get-caller-identity --profile your-profile when available;
• and whether aws sso login --profile your-profile completes successfully.

For provisioning automation, add the request identifier and operation status rather than assuming that a successful API submission meant the asynchronous change had finished.

For an identity-source migration, say explicitly that the source changed and when. That one fact can explain deleted assignments, missing identities, changed portal behavior, and active sessions that outlive the migration.

A precise support case sounds like this: “The user authenticates successfully through our external IdP at 10:14 a.m., appears in the Identity Center directory, belongs to Developers, but account 123456789012 does not appear in the portal even though the group has the ProductionReadOnly assignment.”

That is a problem somebody can investigate. “AWS SSO broken” is a mood.

IAM Identity Center FAQ

1. What is AWS IAM Identity Center used for?

IAM Identity Center connects workforce identities to AWS applications, AWS accounts, or both. Employees get a centralized sign-in experience, while administrators centrally control which people and groups receive which access.

2. Is IAM Identity Center the same as AWS SSO?

IAM Identity Center is the current name of the service previously called AWS Single Sign-On. The rename happened on July 26, 2022. Older technical names such as sso, sso-admin, and aws configure sso remain for compatibility.

3. Is IAM Identity Center free?

IAM Identity Center is provided at no additional charge. AWS services, applications, KMS keys, directories, and resources used alongside it can still create their normal charges.

4. What is the IAM Identity Center login URL?

Employees use the AWS access portal URL provided by their administrator. A customized portal can use a format such as https://your-company.awsapps.com/start.

5. What is the difference between IAM and IAM Identity Center?

IAM is the core AWS authorization system for identities, roles, and policies inside AWS accounts. IAM Identity Center is the centralized workforce-access layer that connects company users to AWS applications and accounts while relying on IAM roles and permissions underneath AWS account access.

6. IAM Identity Center vs Cognito: which should I use?

Use IAM Identity Center for your workforce: employees, administrators, developers, analysts, and contractors who need AWS or business-application access. Use Amazon Cognito for application end users and customer identity scenarios.

7. Does IAM Identity Center require AWS Organizations?

No, AWS Organizations is not required for every IAM Identity Center use case. An organization instance is nevertheless the recommended model when you want the complete centralized company-wide feature set and AWS account-management capabilities.

8. Can IAM Identity Center use Microsoft Entra ID or Okta?

Yes. An external identity provider can be connected for workforce authentication. SAML handles federated authentication, while provisioning such as SCIM keeps the relevant users and groups available for Identity Center assignments.

9. What is a permission set in IAM Identity Center?

A permission set is a reusable definition of AWS account permissions. When assigned through Identity Center, it is provisioned as an IAM role in the target AWS account and appears to the assigned user as an available role.

10. What is IAM account access manager?

Account access manager is an IAM capability launched on August 10, 2026. It lets administrators centrally assign existing IAM roles in AWS accounts to workforce users and groups from IAM Identity Center instead of recreating those roles as permission sets.

11. Why does IAM Identity Center show no AWS accounts?

Check whether AWS account management is enabled for the instance and whether the user or one of their groups has an account assignment. A new organization instance configured only for applications can legitimately show no managed AWS account access.

12. How do I log in to AWS CLI with IAM Identity Center?

Configure an SSO profile with aws configure sso. Then run aws sso login --profile your-profile. Use that profile with AWS CLI commands and confirm the resulting identity with aws sts get-caller-identity.

13. Does aws sso login create permanent access keys?

No. The IAM Identity Center CLI workflow is built around temporary credentials and SSO sessions rather than creating a permanent IAM access key for normal workforce access.

14. How long does an IAM Identity Center session last?

The user interactive session defaults to eight hours and can be configured from 15 minutes to 90 days. Permission-set based AWS account role sessions default to one hour and can be configured up to 12 hours.

15. Why can a disabled IAM Identity Center user still access AWS?

An IAM role session that was already established can operate independently until its configured duration ends. Disabling the identity prevents future access paths as appropriate, but administrators must also consider active sessions when immediate revocation is required.

16. Should employees use IAM users or IAM Identity Center?

For centralized human workforce access, IAM Identity Center is the preferred starting point. It avoids treating independently managed long-lived IAM users in every AWS account as the normal employee-access model and provides centralized assignments with temporary role sessions.

The bottom line: IAM Identity Center is the workforce front door

IAM Identity Center becomes much easier once you stop treating it as “that AWS SSO page” and instead see the whole system.

The identity source answers who the person is. IAM Identity Center connects that workforce identity to AWS. Groups and assignments decide which accounts or applications the person can reach. Permission sets or account access manager decide which AWS account roles are available. IAM policies decide what those roles can actually do. Sessions decide how long already-established access remains valid.

The service has also changed enough in 2026 that an older explanation can now send you in the wrong direction. An organization instance can be application-only. Multi-Region access exists for supported configurations. Existing IAM roles can now be centrally assigned through account access manager. Those are not minor console-label changes; they change how you can design the workforce system.

For Jake’s phone shop, the goal is not to build the fanciest identity architecture in town. It is to make employee access boring: one trusted company identity, one obvious place to begin, the right accounts for each job, temporary sessions, and no mystery about what happens when somebody joins, changes teams, or leaves.

If your AWS environment has reached the stage where people keep asking “which account login am I supposed to use?”, that is a good signal to stop creating another password and design the workforce front door instead. And if you find a 2026 behavior here that AWS changes later, send the correction along; identity guidance is only useful when the access path described on the page still matches the one in front of you.

Revision note. Written October 5, 2026, after account management became optional and account access manager arrived. Getting people into AWS calmly is most of the job, and one clear front door makes that easier on everyone.