How to lock down long-lived AWS credentials

Summary

You will lock down long-lived AWS credentials by enforcing MFA and policy conditions, reducing permissions to least privilege, rotating and removing unused keys, and planning migration to IAM roles. Use this when you must retain some long-lived keys but want to limit risk; prefer removing keys via migration where possible.

Prerequisites

• IAM users with access keys in use (see How to create and rotate IAM user access keys, How to enforce MFA for IAM users).
• IAM permissions to attach policies, set permission boundaries, and manage access keys.

Steps

Step 1: Enforce MFA and conditions on policies

• Ensure every human user with access keys has MFA assigned. For programmatic use, long-lived keys cannot carry MFA; use a Deny policy so that sensitive actions (e.g. iam:, ec2:Delete) are denied when aws:MultiFactorAuthPresent is false. That blocks key-only use from performing those actions; users must use GetSessionToken with MFA for sensitive operations.
• Optionally restrict key-based calls by IP: add a Condition Deny when aws:SourceIp is not in your office or VPN range. This limits where the key can be used from. Document the allowed IPs and update when networks change.

Step 2: Reduce permissions to least privilege

• Replace broad managed policies (e.g. AdministratorAccess, PowerUserAccess) with custom policies that grant only the actions and resources the user or app needs. Use IAM policy simulator to validate.
• Set a permission boundary on the user so that even if more policies are attached later, the effective permission cannot exceed the boundary. Use a custom managed policy as the boundary that allows only the maximum set you are willing to grant.

Step 3: Rotate and remove unused keys

• Rotate access keys on a schedule (e.g. every 90 days). See How to rotate access keys used by applications and How to create and rotate IAM user access keys.
• Run get-access-key-last-used for each key and the credentials report; remove or rotate keys that have not been used in your threshold (e.g. 180 days). Prefer one active key per user unless you have a documented reason for two (e.g. rotation in progress).

Step 4: Plan migration to roles

• Identify each consumer of long-lived keys: EC2, Lambda, ECS, CI, on-prem. For each that can use an IAM role (instance profile, execution role, OIDC), plan migration (see How to migrate from access keys to IAM roles). After migration, delete the key and optionally the IAM user.
• Document any remaining long-lived keys (user, purpose, where used) and require a review and rotation schedule; treat them as exceptions and reduce their scope as much as possible.

Verification

• Users with keys have MFA; Deny conditions block sensitive actions without MFA (and optionally from disallowed IPs).
• Attached policies and permission boundaries are least privilege; no unnecessary broad policies remain.
• Keys are rotated on schedule; unused keys are removed; migration to roles is planned or completed for applicable workloads.

Troubleshooting

App breaks after adding IP condition — The app may run from a different IP (e.g. NAT, new datacenter). Add the correct CIDR to the condition or use a different control (e.g. VPC endpoint, private only) and document.

Permission boundary too strict — The user cannot perform an action they need. Broaden the boundary carefully (specific actions/resources only) or move the user to a role that does not need a boundary. Do not remove the boundary without a replacement control.

Cannot rotate because consumer is unknown — Use CloudTrail and last-used to see which key is used and from where; search code and config for the key ID. Once consumers are updated, rotate; if no use is found, deactivate and then delete after a short monitoring period.

Next steps

• How to rotate access keys used by applications.
• How to find leaked or compromised AWS credentials.
• How to migrate from access keys to IAM roles.