AWS IAM Identity Center Attack Paths: Permission Set Abuse and Hardening Guide

AWS IAM Identity Center (formerly AWS Single Sign-On) is the recommended mechanism for managing human access to multi-account AWS Organizations. Its centralised architecture is an operational strength — one place to manage identities and access across dozens or hundreds of accounts — but it’s also a blast-radius amplifier. A compromise at the Identity Center layer affects every account in the Organization simultaneously.

This guide maps the four most commonly exploited attack surfaces and provides concrete hardening steps and audit commands for each.

How IAM Identity Center Works

Identity Center operates at the management account level (or a delegated administrator account) and manages two things: identity sources and permission sets. Identity sources determine where users come from — the built-in Identity Center directory, Active Directory via AWS Managed Microsoft AD or AD Connector, or an external SAML 2.0 identity provider (Okta, Entra ID/Azure AD, Ping Identity, etc.). Permission sets are IAM policies packaged as reusable bundles that get provisioned into member accounts as IAM roles.

When a user authenticates through Identity Center, they assume a role in a target account. That role’s permissions are derived from the provisioned permission set. The key point: the permission set and account assignment live in Identity Center, not in the member account. This centralization is what creates unique attack paths.

Attack Surface 1: Over-Provisioned Permission Sets

The most pervasive issue. Permission sets containing AdministratorAccess proliferate in large Organizations when platform engineering teams accumulate users over time, or when a permission set built for break-glass access becomes the default for an expanding developer group.

Audit command — list all permission sets containing AdministratorAccess:

INSTANCE_ARN=$(aws sso-admin list-instances \
  --query 'Instances[0].InstanceArn' --output text)

aws sso-admin list-permission-sets \
  --instance-arn "$INSTANCE_ARN" \
  --query 'PermissionSets[]' \
  --output text | tr '\t' '\n' | \
while read -r ps_arn; do
  result=$(aws sso-admin list-managed-policies-in-permission-set \
    --instance-arn "$INSTANCE_ARN" \
    --permission-set-arn "$ps_arn" \
    --query "AttachedManagedPolicies[?PolicyArn=='arn:aws:iam::aws:policy/AdministratorAccess'].PolicyArn" \
    --output text 2>/dev/null)
  if [ -n "$result" ]; then
    echo "AdministratorAccess found in: $ps_arn"
  fi
done

For each AdministratorAccess permission set found, enumerate which users and groups are assigned to it across which accounts. The acceptable answer is usually two to three named individuals for break-glass purposes; anything broader warrants review.

Attack Surface 2: External IdP Federation Trust Abuse

When an external IdP is configured as the identity source, Identity Center trusts SAML assertions from that provider. A compromise of the IdP — an Okta admin account, an Entra ID Global Administrator, a Ping admin with SAML certificate access — allows an attacker to forge SAML assertions and assume any permission set assigned to users in that IdP.

This is the same trust abuse pattern used in the 2020 SolarWinds campaign and the 2023 MGM Resorts breach: once you control the identity provider, you control everything the identity provider can authorize.

CloudTrail detection — suspicious SAML federation events:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithSAML \
  --start-time $(date -u -v-24H +%Y-%m-%dT%H:%M:%SZ) \
  --query 'Events[].{Time:EventTime,User:Username,IP:CloudTrailEvent}' \
  --output json | jq '.[] | {Time, User, IP: (.IP | fromjson | .sourceIPAddress)}'

Alert on AssumeRoleWithSAML calls from IP addresses not in your IdP’s known egress range, and on calls occurring outside business hours for accounts without documented on-call schedules.

Key hardening control: Enable MFA enforcement at the Identity Center level separately from IdP MFA. An IdP-level MFA bypass does not then automatically bypass Identity Center’s own MFA requirement.

Attack Surface 3: Permission Set Assignment Escalation

sso-admin:CreateAccountAssignment is a high-privilege action that lets the holder assign any user or group to any permission set in any account. It’s functionally equivalent to iam:AttachRolePolicy across the entire Organization.

Dangerous IAM policy pattern (look for this in management/delegated admin accounts):

{
  "Effect": "Allow",
  "Action": [
    "sso-admin:CreateAccountAssignment",
    "sso-admin:ProvisionPermissionSet",
    "sso-admin:PutInlinePolicyToPermissionSet",
    "sso-admin:AttachManagedPolicyToPermissionSet"
  ],
  "Resource": "*"
}

Anyone holding these permissions can self-assign to AdministratorAccess in any account in the Organization. Treat this permission set as equivalent to root-level IAM write access.

Audit who has assignment permissions:

# Find all IAM entities with sso-admin:CreateAccountAssignment
aws iam get-account-authorization-details \
  --query 'UserDetailList[].{User:UserName,Policies:AttachedManagedPolicies}' | \
  jq '.[] | select(.Policies[].PolicyName | contains("SSO") or contains("Admin"))'

Restrict sso-admin:CreateAccountAssignment to a dedicated automation service account and named break-glass admin roles. Treat any human principal with this permission as a tier-0 identity requiring equivalent monitoring.

Attack Surface 4: Stale Assignments and Orphaned Accounts

Identity Center does not automatically deprovision users when they leave an external IdP directory. Terminated employees can retain active account assignments until an administrator explicitly removes them — and because Identity Center isn’t typically integrated into HR offboarding workflows, stale access persists.

Audit current assignments across all accounts:

INSTANCE_ARN=$(aws sso-admin list-instances \
  --query 'Instances[0].InstanceArn' --output text)

# List all account assignments for a specific permission set
aws sso-admin list-account-assignments \
  --instance-arn "$INSTANCE_ARN" \
  --account-id 123456789012 \
  --permission-set-arn "arn:aws:sso:::permissionSet/ssoins-xxx/ps-xxx" \
  --query 'AccountAssignments[].{Principal:PrincipalId,Type:PrincipalType}' \
  --output table

The practical fix is quarterly access certification — export account assignments, cross-reference against HR records, and remove assignments for former employees or users who have changed roles. Automate this with a Lambda function that cross-references Identity Center assignments against your directory’s active user list.

Hardening Checklist

• Restrict AdministratorAccess to a maximum of 3 named break-glass users; all other permission sets should be scoped to least privilege
• Enable Identity Center MFA independently of IdP MFA — defense in depth for federation trust abuse scenarios
• Lock down sso-admin:CreateAccountAssignment in the management account; audit current holders immediately
• Alert on CreateAccountAssignment in CloudTrail — legitimate use is infrequent enough that every event warrants review
• Move Identity Center admin to a delegated admin account separate from the management account, reducing management account exposure
• Quarterly access certification — automate assignment export and flag accounts not in active directory
• Enable SCPs at the Organization level to prevent member accounts from modifying their own Identity Center role trust policies

The Architectural Point

Identity Center is fundamentally different from account-level IAM. A misconfiguration here isn’t a misconfiguration in a single account — it’s a misconfiguration in the control plane for every account. The security controls, access reviews, and alerting you’d apply to root-level IAM access in your most critical accounts should apply to Identity Center administration too.