Skip to content

AWS Updated 2026-07-04

IAM Identity Center (SSO): moving humans off IAM users

How to set up IAM Identity Center (AWS SSO) and migrate human access off IAM users: permission sets, external identity providers, aws configure sso, and the migration runbook that does not break anyone.

IAM Identity Center (the service formerly named AWS SSO) is how humans should reach AWS today: one sign-in portal, short-lived role sessions in every account, MFA enforced at the directory, and no access keys anywhere. It requires AWS Organizations, runs at no additional charge, and replaces the per-account IAM users and the password spreadsheet that grew around them. The migration is unglamorous but mechanical: stand up Identity Center, mirror existing access as permission sets, run both paths briefly, then retire the IAM users.

What’s happening

Identity Center sits at the organization level and does three jobs. It holds or connects the identity source — its built-in directory, or better, the directory you already run (Microsoft Entra ID, Google Workspace, Okta) via SAML for authentication and SCIM for automatic user and group provisioning. It defines permission sets — reusable permission templates like ReadOnly, PowerUser, BillingOnly. And it handles assignment: user or group X gets permission set Y in account Z. Behind the scenes each assignment materializes as an IAM role named AWSReservedSSO_<permission-set>_<random> in the target account; sign-ins mint short-lived sessions of those roles, so every action in CloudTrail carries the person’s identity instead of a shared user.

Operationally that changes three things at once. Credential theft loses its payoff — sessions expire in hours (1 to 12, configurable per permission set) instead of keys living for years. Offboarding becomes one action at the identity source instead of a hunt across accounts. And CLI use gets cleaner: AWS CLI v2 supports aws configure sso, which opens a browser sign-in and caches refreshable credentials — no secret lands in ~/.aws/credentials. Two constraints to plan around: Identity Center requires an organization (the organization-level instance is the one you want; account instances exist for narrow application cases but do not do multi-account access), and it is deployed in one home region you should choose deliberately. Setup details are in the Identity Center documentation.

What to check first

  • Organizations status. No organization means that gets created first; if you are already using Control Tower, Identity Center is present — our Control Tower article covers that path.
  • Where identities should live. If Entra ID, Google Workspace, or Okta already exists, connect it; a second identity island in the built-in directory is a last resort.
  • The current human population. Credential report per account: who has console passwords, who has keys, which keys are humans-doing-CLI versus actual automation.
  • Tooling that assumes static keys. Old CLI v1 installs and scripts reading ~/.aws/credentials directly need updating to SSO profiles.

How to verify

# Is an Identity Center instance in place?
aws sso-admin list-instances

# Configure a CLI profile against the portal (interactive, CLI v2)
aws configure sso

# After sign-in: prove you hold an SSO-minted role session
aws sts get-caller-identity
# expect: arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_PowerUser_ab12cd34/jsmith

Console path: IAM Identity Center > Settings shows the identity source and MFA configuration; IAM Identity Center > Permission sets lists the templates; per-account roles appear under IAM > Roles with the AWSReservedSSO_ prefix. A sign-in test through the access portal URL plus a get-caller-identity in the CLI proves the whole chain.

The runbook

  1. Enable Identity Center in the management account, in a deliberately chosen home region. Enable it from the console; the organization instance covers all accounts.
  2. Connect the real identity source. Configure SAML with Entra ID / Google Workspace / Okta and turn on SCIM provisioning so joiners and leavers sync automatically. Using the built-in directory? Set MFA to required at first sign-in and prompt always-on.
  3. Create permission sets that mirror today’s access — no better, no worse. Migration day is the wrong day to redesign permissions; start from AWS managed policies like ReadOnlyAccess and PowerUserAccess, set session duration (4 hours is a sane interactive default), and refine later.
  4. Assign groups, not individuals, to accounts. Group-based assignment is what keeps 30 people times 12 accounts manageable.
  5. Run the parallel period. Announce the portal, help everyone set up aws configure sso, and watch IAM user activity fall in the credential report. Two to four weeks is typical.
  6. Retire the IAM users in stages. Disable console passwords first, deactivate human access keys next, delete users after a quiet month. Keep one documented break-glass IAM user or rely on root-with-MFA per your policy — never zero emergency paths, since an identity-source outage would otherwise lock out everyone.

When this is the wrong move

A single standalone account with two people in it can defensibly stay on IAM users with MFA and no keys — the ceremony of Organizations plus Identity Center buys little there until growth arrives. And workloads never migrate to Identity Center: services keep using roles (instance profiles, task roles, OIDC federation); Identity Center is for humans only.

Common mistakes

  • Creating users by hand in the built-in directory when a company IdP exists — offboarding then requires remembering two systems.
  • Assigning permission sets to individuals instead of groups, recreating per-person sprawl one layer up.
  • Deleting all IAM users with no break-glass path, making an IdP outage an AWS lockout.
  • Leaving old access keys active “temporarily” after the portal goes live — the migration is not done until the credential report says so.

Keeping it under control

  • Review assignments quarterly: groups against accounts against permission sets, with the same rigour as firewall rules.
  • Keep permission sets in infrastructure-as-code so access changes are pull requests, not console clicks.
  • Alert on any new IAM user creation post-migration; the correct steady-state rate is zero.
  • Watch session duration creep — 12-hour sessions everywhere quietly rebuild the long-credential problem you left.

Moving humans to Identity Center is the single highest-return IAM project most organizations have available: one migration, and entire classes of findings — stale users, shared passwords, unrotated human keys — stop existing. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.