IAM Identity Center: How Enterprises Replace 1,000 IAM Users with One Identity

Business Challenge

A financial services firm has grown from five AWS accounts to fifty over two years. Each account was provisioned with its own set of IAM users — one per engineer, one per service team, one per contractor. Nobody planned it this way; it just happened as teams moved fast and the AWS account count grew faster than the identity strategy.

The result: over 1,000 IAM users spread across 50 accounts. When a senior engineer resigned last quarter, the security team spent three days tracking down and deactivating their access across accounts. Two accounts were missed. The auditor found them six weeks later during a quarterly review.

The pattern has four failure modes at scale:

• Offboarding latency — disabling access requires a manual action in every account. Miss one and the former employee still has console access.
• Access key sprawl — IAM users accumulate long-term credentials. Keys created "temporarily" persist for years unless someone actively rotates or deletes them.
• No central visibility — there is no single place to answer "what does this engineer have access to across all accounts?" You query each account's IAM separately.
• MFA inconsistency — MFA can be enforced per-account, but it requires a policy in every account. Accounts added later frequently miss the control.

Architecture

IAM Identity Center (renamed from AWS Single Sign-On in July 2022) is the control plane for human access across an AWS Organization. It sits in the management account, connects to your identity provider, and provisions IAM roles into every member account on demand.

Three core concepts

Permission set → account assignment model

The assignment model is a three-way relationship: principal × permission set × account. A single permission set can be assigned to many accounts; a single account can have many permission sets; a single group can have different permission sets in different accounts. This lets you express your access model precisely:

ABAC — Attribute-Based Access Control

Permission sets answer "who can access which accounts." ABAC answers a finer question: "what resources within an account can this person access?" Instead of creating a separate permission set for every team and every environment, ABAC embeds user attributes from your IdP as session tags and references them in IAM policy conditions.

A concrete example: your tagging strategy tags every S3 bucket with Environment=prod or Environment=dev. Your data engineers have env-access=dev in Okta. The S3 bucket policy checks:

{
  "Condition": {
    "StringEquals": {
      "aws:PrincipalTag/env": "${s3:ExistingObjectTag/Environment}"
    }
  }
}

A data engineer with env-access=dev can access dev buckets but not prod buckets — without any change to their permission set, without creating a separate permission set, and without touching IAM in the target account. Add a new environment: tag the resources, and the policy automatically covers it.

Why This Architecture Works

Offboarding in one place

Disable the user in Okta. SCIM sync removes them from all Identity Center groups. All active sessions expire at their natural timeout (1 hour maximum). No manual action per account, no possibility of missing an account. The audit trail — CloudTrail in every account — shows the last session timestamp and what it did.

No long-term credentials

Every console session and every CLI profile issued through Identity Center is a set of temporary STS credentials with a maximum lifetime of 12 hours (configurable per permission set, default 1 hour). There are no IAM access keys to rotate, no secrets to store, and no credential-based attack surface on the IAM user level.

MFA enforced once

MFA is enforced at the identity provider — Okta, Azure AD, or the built-in Identity Center MFA. It applies to every account, every permission set, every CLI invocation automatically. You do not need an MFA enforcement SCP per account; the IdP is the single enforcement point.

CloudTrail attribution

Every API call made through an Identity Center session carries the username and session tags in CloudTrail's userIdentity.principalId field. In a traditional IAM user setup you get the IAM username — which is often something like john.smith-prod-002, a per-account artifact with no link to the canonical identity. With Identity Center you get AROAEXAMPLE:john.smith@company.com consistently across every account.

Key Design Decisions

Tradeoffs and Alternatives

Closing Thought

The shift from per-account IAM users to Identity Center is not primarily a security improvement — it is an operational simplification that happens to improve security as a side effect. When access is centralised, offboarding is one action. When credentials are always temporary, rotation is not a process. When MFA is enforced at the IdP, it applies everywhere without per-account policy work.

The organisations that resist this change usually do so because the migration feels disruptive — existing automation uses IAM access keys, existing runbooks reference per-account usernames. That friction is real. But every month of delay adds more IAM users, more access keys, and more accounts to migrate later. The cost of migration scales with account count; the earlier you do it, the cheaper it is.

Start with read-only access for all engineers via Identity Center before you migrate administrative access. A ReadOnlyAccess permission set with a single account assignment per engineer has no blast radius and immediately gives you visibility into whether the access portal and IdP integration work correctly. Migrate elevated permissions account by account once the foundation is stable.

Official AWS Reference

AWS Documentation — IAM Identity Center User Guide — covers identity source setup, permission set creation, account assignments, ABAC attribute mapping, and the access portal configuration. The ABAC tutorial section is particularly thorough on the session tag propagation model.