Overview
In multi-account environments, IAM user centralization facilitates greater user control. User access beyond the initial account is then provide via role assumption. Centralization of users can be accomplished through federation with an external identity provider or through the use of AWS Organizations.
Centralizing IAM user management to a single identity provider, reduces complexity and thus less access management errors.
Remediation guidance
From Console
Perform the following action to check:
For multi-account AWS environments with an external identity provider
- Determine the master account for identity federation or IAM user management.
- Sign into the AWS console and open the IAM Dashboard.
- In the left navigation pane, choose Identity providers.
- Verify the configuration.
For all accounts that should not have local users present. For each account
- Determine all accounts that should not have local users present
- Sign into the AWS console and open the IAM Dashboard.
- Switch role into each identified account.
- Click Users.
- Confirm that no IAM users representing individuals are present.
For multi-account AWS environments implementing AWS Organizations without an external identity provider
- Determine all accounts that should not have local users present.
- Sign into the AWS console and open the IAM Dashboard.
- Switch role into each identified account.
- Click Users.
- Confirm that no IAM users representing individuals are present.
Note: The remediation procedure might vary based on the individual organization's implementation of identity federation and/or AWS Organizations with the acceptance criteria that no non-service IAM users, and non-root accounts, are present outside the account providing centralized IAM user management.
Multiple Remediation Paths
AWS
SERVICE-WIDE (RECOMMENDED when many resources are affected): Deploy centralized guardrails and remediation using AWS Config Conformance Packs and (if applicable) AWS Organizations SCPs.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml
ASSET-LEVEL: Apply the resource-specific remediation steps above to only the affected assets.
PREVENTIVE: Add CI/CD policy checks (CloudFormation/Terraform validation) before deployment to prevent recurrence.
References for Service-Wide Patterns
- AWS Config Conformance Packs: https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html
- AWS Organizations SCP examples: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
Operational Rollout Workflow
Use this sequence to reduce risk and avoid repeated drift.
1. Contain at Service-Wide Scope First (Recommended)
- AWS: deploy/adjust organization conformance packs and policy guardrails.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name <pack-name> --template-s3-uri s3://<bucket>/<template>.yaml
2. Remediate Existing Affected Assets
- Execute the control-specific Console/CLI steps documented above for each flagged resource.
- Prioritize internet-exposed and production assets first.
3. Validate and Prevent Recurrence
- Re-scan after each remediation batch.
- Track exceptions with owner and expiry date.
- Add preventive checks in IaC/CI pipelines.
Query logic
These are the stored checks tied to this control.
No stored query bodies are attached to this entry.
