Skip to content

The Edge of the Cyber World See the latest

Apps

How to Set Up AWS IAM Identity Center: 12 Steps [2026]

Every AWS account you spin up starts with a root user and, eventually, a pile of IAM users with long-lived access keys that someone forgets to rotate. AWS IAM Identity Center — the service formerly known as AWS SSO — replaces that pattern entirely: one login, backed by an external identity provider or a built-in directory, that grants time-limited, auditable access across every account in your organization. As of August 2026, AWS added a one-click multi-Region option for new Identity Center instances, making this a good moment to set it up correctly if you haven’t already, or to review an existing setup that may still be running on the legacy AWS SSO naming and defaults.

This tutorial builds a complete multi-account access setup from scratch: enabling IAM Identity Center, connecting it to AWS Organizations, creating permission sets that map to least-privilege IAM roles, federating with an external identity provider over SAML and SCIM, and configuring the AWS CLI so your terminal uses temporary, auto-expiring credentials instead of a static access key sitting in ~/.aws/credentials indefinitely. The service itself is free — AWS charges nothing for IAM Identity Center — so the only costs you’ll incur are the normal charges for whatever AWS resources your users actually touch, plus a small KMS charge if you opt into the new multi-Region instance.

What IAM Identity Center Replaces and Why It Matters

AWS IAM Identity Center is the direct successor to AWS Single Sign-On (AWS SSO); AWS renamed the service, and current documentation and console features use the new name while preserving backward compatibility for anyone still referencing the old one. The rename wasn’t cosmetic — it reflects the service’s expanded scope beyond simple SSO into a full identity and permissions layer for AWS Organizations.

Before Identity Center, the standard pattern for multi-account access was creating an IAM user in each account, or a single IAM user with cross-account role assumption configured by hand in every account’s trust policy. Both approaches scale badly: a company with 40 AWS accounts and 60 engineers ends up managing thousands of individual trust relationships, and revoking one person’s access on their last day means touching every account they had a role in. IAM Identity Center centralizes that entirely — you manage users, groups, and permission sets in one place, and assignments propagate to every account in your organization automatically.

The core mechanic worth understanding before you start clicking through the console: a permission set is a template made up of AWS managed policies, customer managed policies, or inline policies, plus a session duration setting. When you assign that permission set to a user or group on a specific AWS account, IAM Identity Center automatically provisions an IAM role in that target account named AWSReservedSSO_<PermissionSetName>_<random-suffix> and keeps it synchronized with the permission set going forward. You never touch that generated role directly — you manage the permission set, and Identity Center handles the plumbing across every account it’s assigned to.

This also changes what a “credential” looks like for your team day to day. Instead of a static access key ID and secret access key sitting in a config file indefinitely, every sign-in through Identity Center produces temporary AWS Security Token Service (STS) credentials scoped to a single session, with an expiration baked in by the permission set’s session duration setting. When that session expires, the credentials simply stop working — there’s no key to rotate, revoke, or accidentally leak in a committed .env file, because the credential never lived anywhere persistent in the first place. This is the same underlying STS mechanism used when a Lambda function assumes an execution role or an EC2 instance uses an instance profile; Identity Center just extends that temporary-credential model to human sign-in.

Prerequisites and Versions

Requirement Minimum Version / Detail Why It Matters
AWS Organizations Enabled with all features (not just consolidated billing) IAM Identity Center’s multi-account assignment view requires the “all features” mode, not the legacy billing-only mode
Management account access Root or admin IAM access to the Organizations management account IAM Identity Center is enabled from the management account, though delegated administration is supported
AWS CLI v2.22.0 or later This version defaults to OAuth 2.0 Authorization Code flow with PKCE for aws sso login, the current security baseline
External identity provider (optional) Any SAML 2.0 + SCIM 2.0 compliant IdP — Okta, Microsoft Entra ID, Google Workspace, OneLogin, or JumpCloud Needed only if you’re federating from an existing corporate directory rather than using the built-in Identity Center directory
Browser access Any modern browser Initial setup and the AWS access portal are console/browser-driven
Region for the Identity Center instance Any supported AWS Region (a home Region choice) You pick a home Region during setup; the new multi-Region option extends this after initial setup

Step 1: Confirm AWS Organizations Is Fully Enabled

IAM Identity Center’s multi-account permissions view depends on AWS Organizations running in “all features” mode. Check your current status from the management account:

aws organizations describe-organization

# Look for: "FeatureSet": "ALL"
# If it returns "CONSOLIDATED_BILLING" instead, you need to enable all features first:
aws organizations enable-all-features

If you haven’t set up Organizations at all yet, do that first — this tutorial assumes at least a root organizational unit (OU) with two or more member accounts already exists. If you’re also planning your account structure from scratch, our AWS Control Tower vs Azure Landing Zone comparison covers the tradeoffs between building Organizations by hand versus using Control Tower’s guardrails on top of it.

Step 2: Enable IAM Identity Center

From the AWS Management Console, signed in to the Organizations management account, navigate to IAM Identity Center and choose Enable. AWS prompts you to pick a home Region — this is where your Identity Center configuration, permission sets, and identity data are stored. Choose a Region you already operate in for lower latency on sign-in, since this cannot be changed later without recreating the instance (though the new multi-Region option, covered in Step 10, extends availability without requiring a full migration).

Once enabled, IAM Identity Center automatically creates a unique AWS access portal URL in the form https://your-subdomain.awsapps.com/start. This is the single URL every user in your organization will bookmark to sign in and see the list of AWS accounts and roles available to them.

Step 3: Choose Your Identity Source

IAM Identity Center supports three identity source options, and you pick one under Settings → Identity source:

  • Identity Center directory — the built-in default. Good for small teams or proof-of-concept setups where standing up a full IdP integration isn’t worth it yet.
  • AWS Managed Microsoft AD — via AWS Directory Service, useful if you already run Active Directory on AWS.
  • External identity provider — federating via SAML 2.0, with optional SCIM for automatic user/group provisioning. This is the standard choice for any organization with an existing corporate directory in Okta, Microsoft Entra ID, Google Workspace, OneLogin, or JumpCloud.

For this tutorial, we’ll walk through the external IdP path since it’s what most production setups use, with Microsoft Entra ID as the example — the same SAML-for-authentication, SCIM-for-provisioning pattern applies to Okta, Google Workspace, and the others with only the admin console screens differing.

Step 4: Configure SAML Federation With Your External IdP

In the IAM Identity Center console, choose External identity provider and download the Identity Center SAML metadata file. In your IdP’s admin console (Entra ID’s Enterprise Applications, for example), create a new SAML application and upload that metadata, or manually configure:

  • Identifier (Entity ID): provided by Identity Center, typically https://us-east-1.signin.aws.amazon.com/platform/saml/...
  • Reply URL (ACS URL): also provided by Identity Center in the same setup screen
  • NameID format: set to emailaddress in most configurations, and keep it consistent with what SCIM will use for the userName attribute — a mismatch here is one of the most common causes of provisioning failures, covered in the troubleshooting section below

Back in the IAM Identity Center console, upload your IdP’s SAML metadata (or manually enter the sign-in URL, issuer URL, and certificate) under Actions → Change identity source. Test the connection by attempting to sign in through the AWS access portal URL from Step 2 — if SAML is configured correctly, you’ll be redirected to your IdP’s login page before landing back on the AWS access portal.

Step 5: Enable SCIM Provisioning

SAML handles authentication, but it doesn’t automatically create users and groups inside Identity Center — that’s what SCIM (System for Cross-domain Identity Management) does. In the IAM Identity Center console, under Settings → Automatic provisioning, choose Enable. This generates a SCIM endpoint URL and an access token:

# Example values generated by IAM Identity Center — copy these into your IdP's SCIM config
SCIM endpoint: https://scim.us-east-1.amazonaws.com/xxxxxxxxxxxx/scim/v2/
Access token: (shown once — store it in your IdP's secret configuration immediately)

In your IdP’s admin console, paste the SCIM endpoint and bearer token into its provisioning settings (in Entra ID, this is under the same Enterprise Application’s Provisioning tab). Assign the users and groups you want synced, and trigger an initial provisioning cycle. Within a few minutes, those users and groups should appear under IAM Identity Center’s Users and Groups pages — if they don’t, jump to the SCIM troubleshooting entries later in this guide before continuing.

Scope what you sync deliberately rather than pushing your entire company directory into Identity Center. Most organizations only need a handful of groups synced — one per team or function that actually needs AWS access — rather than every employee and every distribution list the IdP happens to track. Syncing everything creates noise in the Identity Center Users and Groups pages that makes it harder to spot the accounts that actually matter during an access review, and it can bump you into API rate limits on larger SCIM syncs for no operational benefit.

Step 6: Create Your First Permission Set

Under Multi-account permissions → Permission sets, choose Create permission set. You have two starting options: a predefined permission set based on an AWS managed policy (like ReadOnlyAccess or PowerUserAccess), or a custom permission set built from scratch. Start with something narrow rather than defaulting to AdministratorAccess for everyone — that’s the single most common misstep teams make when adopting Identity Center, since it recreates the exact over-privileged access problem the service is meant to solve.

aws sso-admin create-permission-set 
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx 
  --name DevelopersReadOnly 
  --description "Read-only access for the engineering team in non-prod accounts" 
  --session-duration PT4H

The --session-duration flag accepts ISO 8601 duration format; PT4H means four hours, a reasonable default for a working session. Attach a managed policy to the permission set:

aws sso-admin attach-managed-policy-to-permission-set 
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx 
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx 
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

Step 7: Assign the Permission Set to Accounts

A permission set does nothing until it’s assigned to at least one account and one principal (a user or, preferably, a group). In the console, go to Multi-account permissions → AWS accounts, where you’ll see your Organizations account hierarchy — root and every child OU and account. Select the target account, choose Assign users or groups, pick the group synced from your IdP in Step 5, and select the permission set from Step 6.

The equivalent CLI call, useful once you’re managing dozens of assignments and want it scripted:

aws sso-admin create-account-assignment 
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx 
  --target-id 123456789012 
  --target-type AWS_ACCOUNT 
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx 
  --principal-id 11111111-2222-3333-4444-555555555555 
  --principal-type GROUP

This call kicks off a provisioning operation that creates the backing AWSReservedSSO_DevelopersReadOnly_* IAM role in account 123456789012. Provisioning typically completes within a minute; check status with aws sso-admin list-account-assignment-creation-status if you don’t see the assignment reflected immediately.

Step 8: Configure the AWS CLI to Use SSO

With assignments in place, each engineer configures their local CLI once. Run:

aws configure sso

# SSO session name: my-company
# SSO start URL: https://your-subdomain.awsapps.com/start
# SSO region: us-east-1
# SSO registration scopes [sso:account:access]: (press enter to accept default)

The CLI opens a browser to complete authentication against your IdP, then lists every account and permission set combination the signed-in user has been assigned. Pick one, and the CLI creates a named profile in ~/.aws/config. As of AWS CLI v2.22.0, this flow defaults to OAuth 2.0 Authorization Code with PKCE rather than the older device-code flow, which is the current security baseline AWS recommends — if your CLI still opens a device-code screen instead of a browser redirect, it’s worth upgrading.

Once configured, sign in for a working session and verify:

aws sso login --profile my-company
aws sts get-caller-identity --profile my-company

# {
#     "UserId": "AROAEXAMPLEID:jane.doe@company.com",
#     "Account": "123456789012",
#     "Arn": "arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_DevelopersReadOnly_a1b2c3d4e5f6/jane.doe@company.com"
# }

Notice the ARN: it’s an assumed role under the auto-generated AWSReservedSSO_* name, with temporary credentials tied to the session duration set on the permission set. When that session expires, the CLI throws an authentication error until you run aws sso login again — this is expected behavior, not a bug, and it’s the entire point of the system.

Step 9: Delegate Administration to a Non-Management Account

Running all IAM Identity Center administration from your Organizations management account is a security risk in itself — that account should be touched as rarely as possible. AWS supports delegating Identity Center administration to a member account (commonly a dedicated “security” or “identity” account in your Organizations structure):

aws organizations register-delegated-administrator 
  --account-id 222233334444 
  --service-principal sso.amazonaws.com

Once delegated, most day-to-day administration — creating permission sets, managing assignments, reviewing access — happens from the delegated account, leaving the management account reserved for the rare Organizations-level operations that genuinely require it, like closing an account or changing the org’s root email.

Migrating From Legacy IAM Users to Identity Center

Most teams adopting Identity Center aren’t starting from a blank account — they’re migrating away from years of accumulated IAM users, each with their own access keys and hand-rolled cross-account role assumptions. Doing this migration all at once is risky; do it account by account and role by role instead, following a sequence that never leaves anyone locked out mid-transition.

  • Inventory existing IAM users and their effective permissions. Run aws iam generate-credential-report across every account and export the attached policies for each user — this becomes your source of truth for which permission sets you need to build.
  • Group users by function, not by individual. If five engineers all have the same read-only policy attached to their IAM users, that’s one permission set and one IdP group, not five individual assignments.
  • Run both systems in parallel during the transition. Leave existing IAM users active while you onboard the same people to Identity Center, and confirm each person can perform their normal workflow through the new access path before deactivating their old access key.
  • Deactivate, don’t delete, IAM user access keys first. aws iam update-access-key --status Inactive lets you reverse the change instantly if something was missed, whereas deletion is not reversible.
  • Set a hard cutover date per account and stick to it. Open-ended “we’ll clean up the old IAM users eventually” migrations rarely finish; a dated deadline with a calendar reminder to actually delete the deactivated keys closes the loop.

Expect this migration to take longer for accounts with service accounts or CI/CD pipelines still using long-lived IAM user credentials — those need a different fix entirely (OIDC federation for CI/CD runners, for example) since Identity Center is designed for human sign-in, not machine-to-machine authentication.

Step 10: Enable Multi-Region Support (2026 Feature)

AWS added a one-click multi-Region option for IAM Identity Center instances in 2026, aimed at organizations that need resilience if their home Region has an availability event. Enabling it creates a customer-managed KMS key to protect Identity Center data across the additional Region — this is the one part of an otherwise free service that does carry a cost, since standard AWS KMS pricing applies to that key (typically around $1/month plus per-request charges). Find this option under Settings → Regions in the console, and treat it as an optional resilience upgrade rather than a required step for most setups — a single-Region instance is entirely sufficient for organizations without a specific multi-Region continuity requirement.

IAM Identity Center vs. Okta and Entra ID: Where Each One Fits

A question that comes up constantly once teams start this setup: if we already pay for Okta or Entra ID, why do we need IAM Identity Center too? The answer is that they solve different layers of the same problem, and in a well-designed setup they work together rather than competing.

Factor AWS IAM Identity Center Okta / Microsoft Entra ID
Primary role AWS-specific access control plane — issues temporary, scoped AWS credentials Company-wide identity provider — single sign-on across all SaaS apps, not just AWS
Cost Free (KMS charges only if multi-Region is enabled) Per-user licensing (see our Entra ID vs Okta vs Auth0 pricing comparison)
Scope AWS accounts and IAM permission sets only Hundreds of pre-built app integrations beyond AWS
Typical role in the stack Downstream consumer of identity via SAML/SCIM Upstream system of record for users and groups
Credential type issued Temporary STS credentials, auto-expiring Session cookies / OIDC tokens for SaaS apps; delegates to Identity Center for AWS

In practice, most organizations use Okta or Entra ID as the system of record for employees — onboarding, offboarding, and group membership all happen there — then feed that data into IAM Identity Center via SCIM so AWS-specific permission sets and multi-account assignments stay in sync automatically. Removing someone from the Okta or Entra ID group that maps to AWS access revokes their AWS access within one SCIM sync cycle, without an administrator ever touching an individual AWS account.

This division of labor also shows up in how each tool bills. Okta and Entra ID charge per user per month because they’re managing identity across your entire SaaS footprint — email, ticketing, chat, HR systems, and dozens of other apps beyond AWS. IAM Identity Center has no per-user fee because its scope is deliberately narrow: it only governs access to AWS accounts and only issues AWS-scoped credentials. A company already paying for enterprise Okta or Entra ID licensing isn’t paying anything extra to also use Identity Center as the AWS-facing layer, which is one reason nearly every AWS-heavy organization ends up running both rather than picking one.

Five Common Pitfalls When Setting Up IAM Identity Center

  • Defaulting every permission set to AdministratorAccess. It’s the fastest way to get a demo working and the worst starting point for production — build narrow permission sets per team function instead.
  • Mismatched NameID and SCIM userName attributes. If your IdP’s SAML NameID uses one format (e.g., employee ID) while SCIM provisions users keyed on email, Identity Center can end up with duplicate or unmatched user records.
  • Forgetting that permission set changes require re-provisioning. Editing an existing permission set’s policies doesn’t automatically push to every account it’s assigned to — you may need to trigger a manual “Reprovision” if changes don’t appear promptly.
  • Running all administration from the management account. Skipping delegated administration (Step 9) means every Identity Center change requires touching your most sensitive AWS account unnecessarily.
  • Setting overly long session durations for high-privilege permission sets. A 12-hour session on an AdministratorAccess permission set means a stolen laptop or leaked token stays dangerous for half a day; scope session duration to how privileged the access actually is.

These mistakes share a common thread: they’re all easier to make when IAM Identity Center is treated as a one-time setup task rather than an ongoing operational system. The console makes it deceptively simple to grant broad access in a few clicks, and there’s no built-in friction reminding you to revisit that decision later. Building the review habit described in the auditing section below, right from initial rollout, is cheaper than retrofitting it after a security review flags a dozen stale over-privileged permission sets.

Complete Working Example: Terraform for a Standard Permission Set Rollout

Once the initial console setup is done, managing permission sets as code keeps them consistent and reviewable. Here’s a complete Terraform configuration for a read-only developer permission set assigned to a group across two accounts:

data "aws_ssoadmin_instances" "this" {}

resource "aws_ssoadmin_permission_set" "developers_readonly" {
  name             = "DevelopersReadOnly"
  description      = "Read-only access for engineering in non-prod accounts"
  instance_arn     = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  session_duration = "PT4H"
}

resource "aws_ssoadmin_managed_policy_attachment" "readonly" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
  permission_set_arn = aws_ssoadmin_permission_set.developers_readonly.arn
}

resource "aws_ssoadmin_account_assignment" "dev_staging" {
  for_each           = toset(["111111111111", "222222222222"])
  instance_arn       = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  permission_set_arn = aws_ssoadmin_permission_set.developers_readonly.arn

  principal_id   = "11111111-2222-3333-4444-555555555555"
  principal_type = "GROUP"

  target_id   = each.value
  target_type = "AWS_ACCOUNT"
}

This pattern scales cleanly: adding a third account is a one-line change to the toset() list rather than another manual console click-through. Teams already managing infrastructure this way should check our Terraform on AWS setup guide for state management conventions that apply equally well here.

Advanced Tips for Production Use

Once the basics are running, a few refinements make Identity Center more resilient and auditable at scale. Enable AWS CloudTrail logging for sso-admin and sso event sources specifically, since account assignment changes and permission set edits are exactly the kind of privileged actions a security audit will ask about later. Use permission set tags to track which team or cost center owns each one — this becomes invaluable once you have 30+ permission sets and need to figure out which ones are safe to deprecate. Where possible, avoid attaching inline policies directly to permission sets in favor of customer-managed IAM policies referenced by ARN; inline policies are harder to review in a pull request and don’t get picked up by policy-linting tools like IAM Access Analyzer as consistently.

Finally, if your organization is also running workloads on EKS, remember that IAM Identity Center governs human access to the AWS console and CLI — it does not replace IAM Roles for Service Accounts (IRSA) for workload identity inside a cluster. Those are complementary systems solving different problems, and conflating them is a common source of confused permission audits; see our Kubernetes on AWS EKS setup guide for the workload-identity side of that equation.

It’s also worth building a small number of “break-glass” emergency access permission sets, separate from your normal team-based ones, with tightly restricted assignment (typically just two or three senior engineers) and shorter session durations despite the broader policy scope. These exist specifically for incident response scenarios where the normal SCIM-fed access chain — IdP to SCIM to Identity Center to permission set — might itself be part of what’s broken, and you need a path to AWS that doesn’t depend on every other system in that chain being healthy. Test this break-glass path during a scheduled game day rather than discovering it doesn’t work during an actual incident.

Auditing and Reviewing Access on a Schedule

Centralizing access control in one place makes regular access reviews far easier than they were with scattered IAM users, but the review still has to actually happen on a schedule — Identity Center doesn’t do it for you automatically. Set a recurring quarterly review where someone with security responsibility runs through every permission set and every account assignment and asks a simple question: does this group of people still need this level of access to this account? The most useful report for this is a full account assignment export:

aws sso-admin list-permission-sets 
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx 
  --query 'PermissionSets' --output text | 
while read ps_arn; do
  echo "=== $ps_arn ==="
  aws sso-admin list-accounts-for-provisioned-permission-set 
    --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx 
    --permission-set-arn "$ps_arn"
done

Cross-reference the output against your organization chart. Permission sets that map to teams that no longer exist, or accounts that were decommissioned, are the most common finding in a first review — and they’re exactly the kind of stale access that an attacker or an auditor will find first if you don’t.

Troubleshooting: Eight Errors You Will Likely Hit

Error / Symptom Likely Cause Fix
“Your session has expired” in AWS access portal Session duration on the permission set was reached Sign in again; if this happens too often, review whether the session duration is set too short for the workflow
aws sso login hangs on browser redirect Corporate firewall or proxy blocking the callback, or an outdated CLI still using the legacy device-code flow Upgrade to AWS CLI v2.22.0+; confirm the callback port isn’t blocked
Permission set assigned but role not appearing in account Assignment created but provisioning didn’t complete Run aws sso-admin list-account-assignment-creation-status and check for a FAILED status with an error reason
SCIM users not appearing in Identity Center Incorrect or expired SCIM bearer token in the IdP configuration Regenerate the token in Identity Center and re-enter it in the IdP’s provisioning settings
Duplicate user records after SCIM sync NameID (SAML) and userName (SCIM) attribute mismatch Align both to the same attribute, typically email address, across SAML and SCIM configs
“Access denied” despite correct permission set Permission set was edited but never reprovisioned to the target account Manually reprovision the permission set from the console or via aws sso-admin provision-permission-set
CLI profile shows wrong account after re-running aws configure sso Stale cached SSO token from a previous session Clear the cache at ~/.aws/sso/cache/ and re-authenticate
Multi-Region KMS charges appear unexpectedly Multi-Region instance option was enabled without realizing it carries a KMS cost Review Settings → Regions; disable if the resilience benefit isn’t needed

Sample Output You Should Expect

After completing Steps 1 through 7, listing account assignments for a given permission set should return output confirming the group-to-account mapping:

aws sso-admin list-account-assignments 
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx 
  --account-id 123456789012 
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx

{
    "AccountAssignments": [
        {
            "AccountId": "123456789012",
            "PermissionSetArn": "arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxx",
            "PrincipalId": "11111111-2222-3333-4444-555555555555",
            "PrincipalType": "GROUP"
        }
    ]
}

Testing Your Complete Setup End to End

  • Sign in as a test user through the AWS access portal URL and confirm only the expected accounts and permission sets appear — not more, not fewer.
  • Attempt an action outside the permission set’s scope (e.g., a write action on a read-only permission set) and confirm it’s denied, not silently allowed.
  • Remove the test user from the mapped IdP group and confirm, after one SCIM sync cycle, that their access portal no longer shows the account.
  • Let a session expire naturally and confirm the CLI throws a clear re-authentication prompt rather than a confusing generic error.
  • Verify CloudTrail is capturing sso-admin:CreateAccountAssignment and similar events, so access changes are auditable after the fact.

Frequently Asked Questions

Is AWS IAM Identity Center really free?

Yes, AWS does not charge for the IAM Identity Center service itself. The only related cost is standard AWS KMS pricing if you enable the optional multi-Region instance feature, which creates a customer-managed KMS key.

What’s the difference between AWS SSO and AWS IAM Identity Center?

They’re the same service — AWS SSO was renamed to AWS IAM Identity Center. Documentation and the console now use the new name, though some legacy references to AWS SSO remain for backward compatibility.

Do I still need IAM users if I set up Identity Center?

For human access, no — Identity Center is meant to replace individual IAM users entirely. IAM users and roles still matter for service-to-service access and specific edge cases like break-glass emergency access, but day-to-day human sign-in should route through Identity Center.

Can I use IAM Identity Center without AWS Organizations?

You can enable it for a single account, but its multi-account permission management — the main reason to adopt it — requires AWS Organizations with all features enabled.

How long does SCIM provisioning take after I add a user to a group in my IdP?

This depends on your IdP’s sync interval, which is typically configurable and often runs every few minutes to an hour. If a user reports missing access immediately after being added to a group, check whether the SCIM sync cycle has run yet before assuming a configuration problem.

What happens to active sessions if I delete a permission set?

Deleting a permission set removes the backing IAM role from every account it was provisioned to, which invalidates any active sessions using that role going forward, though already-issued temporary credentials may remain valid until their original expiration if AWS hasn’t yet processed the deletion.

Can I assign permission sets to individual users instead of groups?

Yes, but AWS and most practitioners recommend assigning to groups instead — managing access at the group level in your IdP scales far better than tracking individual user assignments across dozens of accounts.

Does IAM Identity Center support multi-factor authentication?

Yes, either through the built-in Identity Center directory’s native MFA support or, more commonly in production, by relying on the external IdP’s MFA enforcement, since authentication is delegated to that IdP via SAML.

Related Coverage

For more cloud infrastructure tutorials, see the Cloud Computing 2026 hub.