Rotating Stale IAM Access Keys
Overview
This tutorial walks through rotating an active IAM access key that hasn't been rotated in 90+ days. Long-lived access keys are a primary attack vector — if leaked, they provide persistent access to your AWS account until someone notices and deletes them. Rotating keys regularly limits the blast radius of any future credential leak.
The Sentasity finding identifies the specific access key by its Key ID (e.g., AKIAIOSFODNN7EXAMPLE) and shows when it was created. Use that Key ID to locate the exact key to rotate.
The remediation involves creating a new replacement key, updating any applications or scripts that use the old key, deactivating the old key to verify nothing breaks, and then deleting it once you're confident.
Cost Impact: No direct cost savings. IAM access keys are free. However, rotating keys reduces breach risk, which can prevent costly incidents.
Prerequisites
- Access to the AWS Console for the affected account
- IAM permissions to manage access keys (
iam:CreateAccessKey,iam:UpdateAccessKey,iam:DeleteAccessKey) - Knowledge of which applications or scripts use the key being rotated
- A secure location to store the new credentials (e.g., AWS Secrets Manager)
Step 1: Locate the Specific Key
Navigate to the IAM user's Security credentials tab at: https://us-east-1.console.aws.amazon.com/iam/home#/users
Select the user named in the Sentasity finding, then click the Security credentials tab.
Under Access keys, match the Access key ID to the Key ID surfaced in Sentasity's finding. That's the one to rotate.
Step 2: Create a Replacement Key
Click Create access key to generate a new key.
Select the appropriate use case for the key. For most remediation scenarios, choose Application running outside AWS or Other.
Click Next. Optionally add a description tag such as "Replaces AKIA... — rotated
Important: Copy or download the new access key ID and secret access key now. This is the only time the secret key will be shown. Store it in AWS Secrets Manager or your team's secrets store.
Click Done once the new credentials are saved.
Step 3: Update Applications Using the Old Key
Before deactivating the old key, point the applications or scripts that use it at the new key. Common locations to check:
- CI/CD pipeline secrets (GitHub Actions, CircleCI, etc.)
- AWS CLI profiles on local machines (
~/.aws/credentials) - Application configuration files or environment variables
- Secrets Manager entries consumed by Lambda/ECS/EC2 workloads
Roll out the change and confirm the applications are running with the new key.
Step 4: Deactivate the Old Key
Back in the Security credentials tab, find the old key (the one from Sentasity's finding). Click Actions → Make inactive. This immediately stops the key from authenticating but keeps it available to reactivate if something was missed.
Confirm deactivation in the dialog. Wait 24-48 hours to verify no applications silently fail before deleting.
Step 5: Delete the Old Key
Once you've confirmed nothing depends on the old key, delete it permanently. Click Actions → Delete next to the old key.
Type the access key ID in the confirmation field and click Delete. This action is irreversible.
Verification
Return to the user's Security credentials tab. The user now has only the new active access key. The old key is gone.
Alternative Approaches
CLI Rotation
# Create new key
aws iam create-access-key --user-name <username>
# Deactivate old key
aws iam update-access-key --user-name <username> --access-key-id AKIA... --status Inactive
# Delete old key (after verification period)
aws iam delete-access-key --user-name <username> --access-key-id AKIA...
Automatic Rotation
Set up AWS Secrets Manager automatic rotation with a Lambda rotator to rotate keys on a schedule. This eliminates the manual rotation burden entirely.
Eliminate Keys Entirely
Migrate the workload to IAM roles with temporary credentials (STS AssumeRole) where possible. This is the most secure approach and eliminates the rotation problem at the root.
Summary
- Security impact: Eliminates persistent-credential risk from a stale key
- Best practice: Rotate active keys every 90 days or less
- Preferred long-term fix: Migrate to IAM roles with STS AssumeRole
- Always deactivate before deleting to avoid disrupting running applications