Offboarding done right: revoking AWS access when someone leaves
A practical checklist to remove every trace of AWS access when someone leaves: IAM Identity Center, open sessions, access keys, secrets and CloudTrail checks.
When someone leaves a company, their laptop is collected on the last day. Their AWS access often stays alive for weeks: an IAM user nobody remembers, an access key in a CI pipeline, an active console session.
Working on Tracix, a tool that audits user access across identity providers like Entra ID, Okta and Google Workspace, I see offboarding as the moment where access reviews matter most. Here is a practical checklist to make sure nothing stays behind on the AWS side.
1. Centralize access first: IAM Identity Center + your identity provider
The best offboarding is the one you don't have to do manually in AWS.
- Connect AWS IAM Identity Center to your identity provider (Entra ID, Okta, Google Workspace…) with SAML for sign-in and SCIM for automatic user and group provisioning.
- Grant AWS access through groups and permission sets, never to individual users.
Result: when HR disables the user in the identity provider, SCIM removes or disables them in IAM Identity Center. One action, all AWS accounts.
2. Kill the sessions that are already open
Disabling a user does not instantly end what they already have:
| What's still alive | How to end it |
|---|---|
| AWS access portal session | IAM Identity Center → Users → select the user → Active sessions → delete them |
| Temporary role credentials already issued | They expire on their own (permission set session duration). For immediate revocation, use Revoke active sessions on the IAM role, which denies credentials issued before now |
💡 Keep permission set session durations short (1 hour is the default) so leftover credentials die quickly.
3. Hunt the long-term credentials
This is where most leftovers hide:
- IAM users created "temporarily" for this person → disable console access, deactivate then delete their access keys, remove their MFA device, then delete the user.
- Access keys used by scripts or CI that were created under their name → rotate them to a service identity (an IAM role) before deleting.
- SSH keys / EC2 key pairs they had → remove them from instances.
- Secrets they knew (database passwords, API keys in Secrets Manager) → rotate them.
The IAM credential report (IAM console → Credential report) lists every IAM user, password and access key with their last-used date. It's free and takes seconds.
4. Check what they owned
- Resources tagged with their name (use Tag Editor or Resource Explorer across regions).
- Resource policies that trust their personal AWS account ID (an IAM Access Analyzer external access analyzer will flag these).
- Pending invitations, shared AMIs or snapshots.
5. Verify with CloudTrail
After offboarding, search CloudTrail for any activity from the user's name or access key ID. No events after the departure date = clean offboarding.
The checklist
| ✅ | Step |
|---|---|
| ☐ | User disabled in the identity provider (SCIM syncs to IAM Identity Center) |
| ☐ | Active portal sessions deleted |
| ☐ | Role sessions revoked if needed |
| ☐ | IAM users, access keys, MFA, SSH keys removed |
| ☐ | Shared secrets rotated |
| ☐ | Owned resources and resource policies reviewed |
| ☐ | CloudTrail checked for activity after departure |
Offboarding is a security control, not an HR formality. Automate the first step, and make the rest a checklist you run every single time.
How does your team handle offboarding on AWS today: fully automated, or a manual checklist? 👇
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article