Ensure access keys are rotated every 90 days or less

Perform the following to rotate access keys:

1. Go to the Management Console

2. Click on Users

3. For each affected user, click on Security Credentials

4. As an Administrator, click on Make Inactive for keys that have not been rotated in 90 Days

5. As an IAM User, click on Make Inactive or Delete for keys which have not been rotated or used in 90 Days

6. Click on Create access key

7. Update programmatic call with new Access Key credentials

Via CLI

1. While the first access key is still active, create a second access key, which is active by default. Run the following command:

aws iam create-access-key

At this point, the user has two active access keys.

2.Update all applications and tools to use the new access key. 3.Determine whether the first access key is still in use by using this command:

aws iam get-access-key-last-used

4.One approach is to wait several days and then check the old access key for any use before proceeding.

Even if step Step 3 indicates no use of the old key, it is recommended that you do not immediately delete the first access key. Instead, change the state of the first access key to Inactive using this command:

aws iam update-access-key

5.Use only the new access key to confirm that your applications are working. Any applications and tools that still use the original access key will stop working at this point because they no longer have access to AWS resources. If you find such an application or tool, you can switch its state back to Active to reenable the first access key. Then return to step Step 2 and update this application to use the new key. 6.After you wait some period of time to ensure that all applications and tools have been updated, you can delete the first access key with this command:

aws iam delete-access-key

References

1. CCE-78902-4

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.