Yes, for any long term access key the person created or could read. AWS documentation recommends updating access keys when needed, such as when an employee leaves, and using last used information to remove keys safely. The better fix is to stop issuing long term keys to people and use temporary credentials through federation.
What AWS recommends
AWS's IAM best practices page makes three points that matter here.
- Human users should reach AWS through federation with an identity provider and temporary credentials. The page recommends IAM Identity Center for centralized access management.
- Workloads should use IAM roles and temporary credentials, so there is no need to distribute long lived keys to them.
- Where long term credentials are unavoidable, update access keys when needed, for example when an employee leaves, and use IAM access last used information to update and remove keys safely.
It also recommends regularly reviewing and removing unused users, roles, permissions, policies and credentials, using last accessed information.
Two situations, two answers
| Situation | What to do when the person leaves |
|---|---|
| They signed in through federation and held temporary credentials | Suspend them in the identity provider. Sessions expire. No keys to rotate |
| They own IAM user access keys | Deactivate the keys, watch for breakage, then delete |
| They created keys used by an application | Create a replacement owned by a role or service, switch the app, delete the old key |
| They knew shared keys | Rotate the shared keys, and move the workload to a role if you can |
A safe rotation sequence
- Inventory. List IAM users and their access keys, including creation dates and last used timestamps.
- Find the leaver's keys, and the keys they created for others. Naming conventions and tags help. Without them, CloudTrail history can show who created what.
- For each key, check last used. A key unused for a long time is a low risk removal.
- Create a new key, or better, a role, for the workload the old key served.
- Update the workload to use the new credential.
- Deactivate the old key rather than deleting it. Wait a few days.
- Delete once nothing has failed.
- Record the change.
Deactivating before deleting gives you a reversible step. If a forgotten job breaks, you can reactivate quickly while you fix the root cause.
Do not forget the other ways in
A person can also hold console passwords, MFA devices, SSH keys for CodeCommit if you use it, and service specific credentials. Remove each. AWS notes some services require IAM users with SSH keys or service specific credentials in particular cases, so check what yours uses.
Reduce the problem permanently
- Move people to federated sign in with temporary credentials.
- Move workloads to roles. For workloads outside AWS, AWS lists options such as IAM Roles Anywhere and web identity federation.
- Require MFA on any IAM user or root user that must exist.
- Review last used data on a schedule so stale keys go before anyone leaves.
Quick check
Is deleting the IAM user enough?
It removes that user's keys, but keys they created under other users or shared secrets they knew still need handling.
How do I know a key is safe to delete?
Check last used information, deactivate first, wait, then delete if nothing breaks.
Safeguard's asset discovery and policies can help surface long lived credentials and risky configuration in your environment. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
