Compliance Frameworks
BETA// Beta Mapping Disclaimer
Framework mappings are currently in beta. These references are generated based on technical specifications and common industry alignments. Mappings may be incomplete or inaccurate; always consult with a qualified auditor for official compliance validation.
Overview
Deploy AWS IAM Identity Center as the sole human access mechanism for all landing zone accounts, integrated with an external IdP, and enforce via SCP that direct IAM user creation and console access are blocked in member accounts.
IAM Identity Center is enabled in the Management account and applies organization-wide. It serves as the single control plane for human identity: users authenticate through the corporate IdP (Entra ID, Okta, Google Workspace) via SAML 2.0 or SCIM provisioning, are assigned to permission sets that define scoped IAM policies per account, and access accounts through the AWS access portal without long-lived credentials. This control mandates three things.
- Identity Center is active with an external IdP connected - the built-in directory is not acceptable for production landing zones.
- All central accounts (Management, Log Archive, Audit) have permission set assignments covering at least read-only and administrator tiers with MFA enforced at the Identity Center level.
- SCP prevents the creation of IAM users, login profiles, and access keys in member accounts, closing the bypass path that would otherwise allow teams to circumvent Identity Center. Break-glass IAM users in the Management account are the only permitted exception and must be documented under the exceptions section of AWS-IAM-001.
Long-lived IAM user credentials - passwords and access keys - are the most common credential-based attack vector in AWS. Identity Center eliminates them for human access: sessions are short-lived, MFA is enforced centrally, and access is revoked by removing the IdP group assignment rather than hunting for individual IAM users across dozens of accounts. The audit trail in CloudTrail is attributed to the federated identity rather than a shared IAM user, making incident investigation significantly more precise.
Remediation Strategy
Enable Identity Center in the Management account, connect the corporate IdP, create permission sets for each access tier, and assign them to accounts and groups. Apply the SCP to prevent IAM user creation bypass. Existing IAM users in member accounts must be migrated before the SCP Deny takes effect.
Enable IAM Identity Center in the Management account (one-time, cannot be done via CLI - use the Console or CloudFormation).
Configure the external IdP connection via SAML 2.0 or enable automatic SCIM provisioning.
Create permission sets for each access tier: ReadOnly, PowerUser, Administrator - each with a session duration of 8 hours maximum and MFA required.
Assign permission sets to IdP groups for each central account using account assignments.
Audit and remove existing IAM user login profiles and access keys in member accounts before applying the SCP.
Apply the DenyIAMUserCreationAndCredentials SCP to the organization root or member accounts OU.
# Get Identity Center instance ARN and identity store ID
aws sso-admin list-instances \
--query "Instances[0].{InstanceArn:InstanceArn,IdentityStoreId:IdentityStoreId}" \
--output table
# Create a ReadOnly permission set (8h session, MFA enforced at IdP)
aws sso-admin create-permission-set \
--instance-arn "<INSTANCE_ARN>" \
--name "ReadOnly" \
--description "Read-only access to all services" \
--session-duration "PT8H"
# Attach AWS managed policy to the permission set
aws sso-admin attach-managed-policy-to-permission-set \
--instance-arn "<INSTANCE_ARN>" \
--permission-set-arn "<PERMISSION_SET_ARN>" \
--managed-policy-arn "arn:aws:iam::aws:policy/ReadOnlyAccess"
# Assign the permission set to a group for a specific account
aws sso-admin create-account-assignment \
--instance-arn "<INSTANCE_ARN>" \
--target-id "<ACCOUNT_ID>" \
--target-type AWS_ACCOUNT \
--permission-set-arn "<PERMISSION_SET_ARN>" \
--principal-type GROUP \
--principal-id "<GROUP_ID>"Enforcement Logic
Detection operates at two levels. First, verify Identity Center is active and an external IdP is configured by checking that the instance exists and that the identity source type is not IDENTITY_STORE (which indicates the built-in directory rather than an external IdP). Second, verify that no IAM users with active login profiles or access keys exist in member accounts - their presence indicates Identity Center is being bypassed. Security Hub control IAM.21 flags accounts where IAM users have active console access alongside active permission set assignments.
# Confirm Identity Center instance is active
aws sso-admin list-instances \
--query "Instances[*].{ARN:InstanceArn,Store:IdentityStoreId,Status:Status}" \
--output table
# List all IAM users with active login profiles (console bypass indicator)
aws iam list-users --query "Users[*].UserName" --output text | \
tr '\t' '\n' | while read USER; do
aws iam get-login-profile --user-name "${USER}" 2>/dev/null && \
echo "ACTIVE_CONSOLE_USER: ${USER}"
done
# Check active permission set assignments for a central account
aws sso-admin list-account-assignments \
--instance-arn "<INSTANCE_ARN>" \
--account-id "<ACCOUNT_ID>" \
--permission-set-arn "<PERMISSION_SET_ARN>" \
--query "AccountAssignments[*].{Principal:PrincipalId,Type:PrincipalType}" \
--output tableBreak-glass IAM users in the Management account are permitted as an emergency fallback when Identity Center or the IdP is unavailable. These must have no active access keys, must require MFA, must be documented in AWS-IAM-001, and must be audited monthly.
Service accounts requiring long-lived programmatic credentials (e.g. CI/CD pipelines not yet migrated to OIDC) may retain IAM users with access keys but must not have a login profile enabled. These are exempt from the SCP via the LandingZoneAdminRole carve-out and require documented approval renewed annually.
IAM Identity Center cannot be enabled via AWS CLI - the initial activation requires the Console or a CloudFormation stack set. Subsequent configuration (permission sets, assignments) is fully API-driven. The sso-admin API namespace is used for administration; the identitystore API namespace is used for user and group lookup. Identity Center is a global service deployed to a single home region - all API calls must target that region regardless of where member accounts are located. The SCP carve-outs for LandingZoneAdminRole and BreakGlassRole must reference the exact role names used in your organization; wildcards in ArnNotLike apply to the account segment only (arn:aws:iam::*:role/Name matches any account). Azure AD is now named Microsoft Entra ID - update IdP documentation accordingly.