AWSOverview
AWS console defaults to no check boxes selected when creating a new IAM user. When creating the IAM user access type you have to determine what type of access they require.
Programmatic access:The IAM user might need to make API calls, use the AWS CLI, or use the tools for windows powershell. In that case, create an access key (access key ID and a secret access key) for that user. AWS Management Console access: If the user needs to access the AWS Management Console, create a password for the user.
After user profile is created, user can create access keys for programmatic access which will provide an indication that it is needed for their work. User can also put a support ticket to have access keys created for them.
Remediation guidance
From Console
Perform the following action to check if an access key is created during user creation:
- Sign into the AWS console and navigate to the IAM Dashboard.
- In the left navigation pane, choose Users.
- Click on the User name where column
Password ageandAccess key ageis not set to None. - Click on Security credentials tab.
- Compare the user
Creation timeto the Access KeyCreateddate and time. - For any that match, the key was created during initial user setup.
Note: Keys that were created at the same time as the user profile and do not have a last used date should be deleted.
Perform the following action to delete access keys:
- Sign into the AWS console as an Administrator and navigate to the IAM Dashboard.
- In the left navigation pane, choose Users.
- Click on the User name for which access key is to be deleted.
- Click on Security credentials tab.
- Click on the Make inactive to
deactivatethe keys that were created at the same time as the user profile but have not been used. - Now click X (delete) for the
Inactivekeys.
From Command Line
aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>
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.
Do not setup access keys during initial user setup for all IAM users that have a console password
Connectors
Covered asset types
Expected check: eq []
iamUsers(where:{hasIAMUserCredentials:{OR:[{accessKey1Active:true,accessKey1LastUsedDate:null}{accessKey2Active:true,accessKey2LastUsedDate: null }]}}){...AssetFragment}
