AWS IAM Identity Center: the 50-engineer transition that closes most audit findings

Figure 1: Visual representation of the BeyondTrust vulnerability chain

A startup spins up its first AWS account. The founders create three IAM users — one each — with AdministratorAccess. They use the console to deploy the early infrastructure. The application gets to production.

The team grows. The 4th engineer joins. The CTO creates an IAM user, attaches AdministratorAccess, sends them the credentials over Slack. The 5th engineer joins. Same drill. By the 10th engineer, the pattern is "create an IAM user, attach AdministratorAccess, get them shipping."

By the 50th engineer, the AWS environment has 47 active human IAM users, mostly with AdministratorAccess. The off-boarding workflow ("disable the IAM user when someone leaves") has been followed inconsistently, so probably 6-8 of those users belong to people who have not worked at the company in months. The audit credentials those users created (AWS access keys for CLI use) are scattered across laptops, dotfiles, and one or two Vault entries that nobody updates.

This is the situation that SOC 2 Type II audits surface as a "significant deficiency in access management." It is also the situation that a one-week project closes.

Three structural reasons mid-market AWS shops drift into the 50-individual-IAM-users state:

1. The path of least resistance. The AWS console makes it easy to create IAM users. The IAM Identity Center setup process is more involved (you connect it to your IdP, you define permission sets, you assign access, you train the team to log in differently). When you are growing fast, the easy path wins.

2. AWS documentation lags reality. Until AWS renamed AWS SSO to IAM Identity Center in 2022, the marketing emphasis was on "AWS users." Many engineering teams learned AWS in an era where IAM users were the default and nothing else was prominently surfaced. The documentation is much better now, but the muscle memory persists.

3. The cost of changing course feels high until it is forced. Migrating 47 IAM users to Identity Center sounds like a project. Migrating them to fix a SOC 2 audit finding sounds like THE project. The cost feels different.

The reality is that the migration is a one-week effort with high payoff. Most teams do not realize how achievable it is until they actually do it.

Figure 2: How the authentication bypass vulnerability works

IAM Identity Center (formerly AWS SSO) is AWS's service for centralizing human access to AWS accounts. It provides:

1. A single sign-on portal. Engineers log in via SSO (typically connected to your IdP — Microsoft Entra ID, Okta, Google Workspace, or built-in Identity Center directory) and see a list of AWS accounts they have access to.

2. Permission sets. Reusable templates of IAM policies that define what an engineer can do in an account. "ProductionReadOnly" might be one permission set; "DeveloperFullAccess" might be another. You define the permission sets once and assign them to users for specific accounts.

3. Time-bound credentials. When an engineer assumes a permission set, AWS issues short-lived credentials (typically 1-12 hours). When the credentials expire, the engineer logs in again. This dramatically reduces the credential-leak risk.

4. Centralized provisioning. Add an engineer to an Active Directory group → they automatically get access to the right AWS accounts and permission sets via SCIM provisioning. Remove them from the group → access revokes automatically. The off-boarding problem largely solves itself.

5. Audit trail. Every access assumption is logged in CloudTrail. Auditors can see who accessed what account at what time with what permission set, end-to-end.

The SOC 2 audit findings around access management evaporate when this is in place properly.

A typical mid-market 50-engineer migration we run takes 5 working days end-to-end:

Day 1: Identity Center provisioning

Enable IAM Identity Center in the AWS Organizations management account. Connect it to your IdP (most commonly Entra ID via SAML + SCIM, or Okta via the same). Test the SSO login flow with one volunteer engineer. Confirm SCIM provisioning works (add engineer to an AD test group, see them appear in Identity Center).

Day 2: Permission set design

Define the permission sets your team needs. A typical mid-market structure:

• OrgAdmin: Full access to the management account + audit account. Reserved for 2-3 senior engineers.
• ProductionAdmin: Full access to production workload accounts. Reserved for the on-call rotation.
• ProductionReadOnly: Read-only access to production. The default for engineers without explicit production change need.
• DeveloperFullAccess: Full access to dev/sandbox accounts. The default for engineers.
• BillingViewer: Read-only access to billing dashboards. For finance team members.
• AuditorReadOnly: Read-only access across all accounts for SOC 2 auditors and security team.

Each permission set is a JSON IAM policy plus optional permission boundary. Define them carefully; they are reusable.

Day 3: Assignment + parallel access

Map your engineering team to the permission sets they need in the accounts they need them. Assignments via Identity Center, propagated by SCIM from your IdP groups.

Critical: do not yet disable the existing IAM users. Both paths are live in parallel for the next 48 hours so any setup issues surface before the cutover.

Let engineers test the new login flow. Surface any permission gaps and adjust the permission sets accordingly.

Day 4: Cutover

Communicate to the team that legacy IAM user access will be disabled at end of day. Ensure everyone has tested the Identity Center flow successfully.

End of day: disable (do not delete) the legacy IAM users. Disable any AWS access keys those users had. Engineers now log in exclusively via Identity Center.

Standby for issues — but if days 1-3 went well, the cutover is uneventful.

Day 5: Lockdown + cleanup

Apply Service Control Policies at the OU level that prevent creation of new IAM users in any account. This blocks regression to the old pattern.

Audit the disabled IAM users. Delete the ones whose owners cannot identify use cases for. Migrate any service-account use cases (CI/CD pipelines, integrations) to IAM roles with proper trust policies — this is genuinely service account work that does belong on IAM, but on roles, not users.

Document the new model. Write a runbook for "how a new engineer gets AWS access" that points to the IdP group and not "ask the CTO to create an IAM user."

Figure 3: Privilege escalation from user to SYSTEM level

The SOC 2 access management section that used to be a significant deficiency now reads cleanly:

• All human access is via SSO from a centralized identity provider.
• Access provisioning is automated via SCIM from IdP groups.
• Off-boarding is automatic — removing from the AD group revokes AWS access.
• Permission sets are defined as code, version-controlled, and reviewed quarterly.
• Time-bound credentials limit the exposure window of any leaked session.
• CloudTrail shows full audit trail of access assumptions.
• No human IAM users exist in the environment.

The auditor moves on to the next section. The engagement converts from "significant deficiency, must be remediated" to "controls operating effectively."

This same migration also closes most of the IAM-related cyber insurance questionnaire concerns. "How do you manage access to your cloud infrastructure?" goes from a worried "we have IAM users with access keys" to a confident "we use IAM Identity Center with SSO and time-bound credentials."

The migration above is about human users. Service accounts (CI/CD pipelines, monitoring tools, integration scripts) are a separate concern.

The right pattern for service accounts in 2026:

• IAM roles with trust policies, not IAM users with access keys.
• Roles assumed by GitHub Actions / GitLab CI / Jenkins / etc. via OIDC federation.
• Roles assumed by EC2 instances, ECS tasks, Lambda functions via instance profiles.
• IAM users only for legacy systems that genuinely cannot use any other auth method — and even then, with strict access keys rotation and IP allowlisting.

The migration to IAM Identity Center for humans makes the service-account cleanup easier because the IAM users you find left over after the human migration are almost all service-account use cases that need to be modernized.

The free 90-minute IT health check we run for prospective clients includes an IAM audit: count of IAM users vs Identity Center assignments, AdministratorAccess sprawl analysis, off-boarding effectiveness check, and a 5-day migration roadmap if you are still on individual IAM users. Yours to keep either way.

The full AWS positioning page is at /aws. The Well-Architected security pillar (which IAM Identity Center sits inside) is at /aws/well-architected. The case-study gallery covers the IAM sprawl pattern as one of six common AWS failure modes at /aws/case-studies.

The 50-engineer transition is a one-week project. The audit findings it closes have typically been blocking SOC 2 attestations for months. The math is overwhelming.