To cut off AWS access from a lost laptop, revoke active role sessions with the IAM console's revoke action, sign the user out of IAM Identity Center sessions, deactivate any long lived access keys, and check CloudTrail for use after the loss time. Temporary credentials stay valid until they expire unless you revoke them.
Why this needs its own steps
Developers usually reach AWS through temporary credentials. They are short lived, which is good, but they remain valid until they expire. AWS says that when users have long console session durations, such as 12 hours, the credentials do not expire quickly, and if exposed, a third party has access for the duration of the session. A lost laptop with an unlocked session is that case.
Step 1: revoke role sessions
AWS documents a way to immediately revoke all permissions for a role's credentials issued before a certain time. In the IAM console, open the role, choose Revoke sessions, and confirm. AWS attaches a new inline policy to the role that denies all permissions, with a condition that applies only to sessions that assumed the role before the revocation time.
Three things to know:
- It applies to everyone using that role, not just the person who lost a laptop. AWS warns that users may lose unsaved work and must sign in again.
- Sessions started after the revocation time are not blocked, so the person can sign in again from a new device at once.
- You cannot revoke sessions for a service linked role.
Step 2: sign out of Identity Center
If your team uses IAM Identity Center with the AWS CLI, AWS describes signing in to a session and signing out of your IAM Identity Center sessions. Ask the user to run the sign out command from a trusted device if they can, and ask an administrator to end the user's sessions or disable the user for a short time if that is possible in your setup. Check your identity provider too, since that is where the main session lives.
Step 3: deal with long lived keys
If the laptop held IAM user access keys, in a credentials file or environment, deactivate them first, then create new ones only if you still need keys. A better fix is to move away from stored keys and use short lived access.
Step 4: look at the logs
Search CloudTrail for the user and the roles they use, from the time of loss. Look for new console logins, new access keys, new IAM users or roles, changed trust policies, and large data reads. If you see any, treat it as an incident and widen the response.
Order of operations
| Order | Action | Why |
|---|---|---|
| 1 | Disable or reset the user at the identity provider | Stops new sessions |
| 2 | Revoke role sessions | Ends existing sessions |
| 3 | Deactivate access keys | Closes the long lived path |
| 4 | Review CloudTrail | Tells you if it was used |
| 5 | Restore access on a new device | Back to work |
Prevent a repeat
Set shorter session durations for sensitive roles, avoid keys on laptops, and keep a written lost device runbook. The first hour checklist and the GitHub steps cover the other accounts.
Safeguard offers asset discovery, policy gates and compliance evidence automation, which help you keep an inventory and a record of what changed. It does not revoke your cloud sessions for you. Try the free scan.
Quick check
Does revoking sessions delete the role?
No. It adds a deny policy for sessions created before a set time. Sessions created afterwards work normally.
What if I only use Identity Center, not IAM users?
Then your main controls are at the identity provider and Identity Center, plus revoking sessions for the permission set roles. Confirm the exact process in AWS documentation.
Sources
- Revoke IAM role temporary security credentials, AWS IAM User Guide
- Configure the AWS CLI to use IAM Identity Center, AWS CLI User Guide
- Temporary security credentials in IAM, AWS
Last reviewed: 19 October 2026.
