Skip to main content

Removing Unused IAM Access Keys

Overview​

This tutorial walks through deleting or deactivating an active IAM access key that hasn't been used in 90+ days. Unused active keys are a security liability — they exist, they can authenticate, and nobody's watching their activity pattern because there isn't one. If such a key leaks, an attacker could use it for months without triggering any anomaly.

The Sentasity finding identifies the specific access key by its Key ID and shows the Last Used date. Use those details to locate the exact key to remove.

The right action for an unused key is almost always delete (or deactivate first, confirm nothing breaks, then delete). There's no point rotating a key that nobody is using — rotation just creates another dead credential.

Cost Impact: No direct cost savings. IAM access keys are free. This is a pure security cleanup.

Prerequisites​

  • Access to the AWS Console for the affected account
  • IAM permissions to manage access keys (iam:UpdateAccessKey, iam:DeleteAccessKey)
  • A way to verify the key is truly unused (check CloudTrail, application logs, deployed configuration)

Step 1: Confirm the Key Is Really Unused​

Before deleting, verify nothing you don't know about depends on this key.

In CloudTrail, search for the Access Key ID in the last 90 days of events. If no results, the key has not been used recently.

In deployed configuration, check:

  • CI/CD pipeline secrets
  • AWS CLI profiles on team laptops
  • Application config or environment variables
  • Secrets Manager entries (perhaps an application is configured with the key but hasn't run lately)

If anything still references the key, investigate before deleting.

Step 2: 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 the finding. Confirm the Last used column shows 90+ days (or "Never") — matches what Sentasity reported.

Step 3: Deactivate First (Safety Net)​

Even if you're confident the key is unused, deactivate it before deleting. If something silently breaks, you can reactivate the key in a minute.

Click Actions → Make inactive. Confirm in the dialog. The key immediately stops authenticating.

Wait 1-7 days. Monitor CloudTrail, application logs, and any on-call pages for failures that might point back to this key.

Step 4: Delete the Key​

Once the deactivation observation period is clean, delete the key. 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 key is gone.

Check the IAM user again — if they have no other access keys and no console password, consider whether the user itself is also unused (Sentasity's iam-users-unused finding will surface this separately).

Alternative Approaches​

CLI Deletion​

# Deactivate
aws iam update-access-key --user-name <username> --access-key-id AKIA... --status Inactive

# Delete (after verification period)
aws iam delete-access-key --user-name <username> --access-key-id AKIA...

Policy-Driven Auto-Cleanup​

Deploy an AWS Config rule or Lambda scheduled task that automatically deactivates keys unused for N days. Pair with a grace period and notification before deletion.

Eliminate Keys Entirely​

If the IAM user exists solely to hold an access key for a workload, migrate the workload to an IAM role with STS AssumeRole. The user and its keys can then be deleted entirely.

Summary​

  • Security impact: Removes an unauthenticated attack surface
  • Default action: Delete, not rotate — rotating an unused key just creates another dead credential
  • Safety net: Always deactivate first, then delete after a verification period
  • Preferred long-term fix: Migrate to IAM roles and eliminate long-lived credentials