Offboarding an engineer from AWS: the access IT checklists miss
To offboard an engineer from AWS, disable their SSO or IAM Identity Center access, then revoke what that doesn’t touch: deactivate and delete their IAM access keys, revoke any active sessions, and clear the EKS, CodeCommit, CI, and EC2 credentials they held. The mistake most teams make is assuming that removing someone from SSO cut off their access. On AWS it doesn’t, and the leftover keys are where offboarding quietly fails.
Why disabling SSO isn’t enough
Removing someone from IAM Identity Center or your identity provider stops them logging in through SSO. It does not revoke a long-lived IAM access key they created, and it does not kill an STS session token that’s already been issued, which stays valid until it expires. Both keep working, because neither was tied to the SSO login you just disabled.
That’s the gap between IT offboarding and AWS offboarding. The IT checklist covers the SSO seat. The IAM layer underneath it is where an engineer can still reach production after they’ve left.
The AWS access to revoke
Go through what the engineer actually accumulated in the account:
IAM access keys they held or created, deactivated and then deleted. Their IAM user, or their assignments in Identity Center, plus group memberships and any inline policies attached directly to them. Active STS sessions, revoked so already-issued temporary credentials stop working. EKS access entries and any kubeconfigs on their machine. CodeCommit HTTPS credentials and SSH keys. CI and deploy tokens scoped to their account. EC2 key pairs they used to reach instances. And any cross-account roles they were trusted to assume from another account.
Access keys are the big one
Long-lived IAM access keys are the credential offboarding misses most, because they don’t expire on their own and nothing prompts you to remove them. An engineer who generated a key for a one-off script two years ago still has a working key today. Check the access key age and last-used data in IAM, deactivate first so you can confirm nothing breaks, then delete. Better still, use an organization policy or SCP to discourage long-lived keys existing at all.
Speed matters more than completeness
For a sensitive departure, deactivate the IAM access keys and revoke active sessions first, before you do anything else. Every minute a working key lives after someone leaves is a minute of exposure. A partial revocation in five minutes beats a complete one in five hours.
The better default: less to revoke
Offboarding on AWS is hard because there’s so much standing access to hunt down. The fix isn’t a better checklist, it’s less standing access. If access is granted per task and expires on its own, most of it is gone before anyone leaves. Moving toward zero standing privileges turns offboarding from a scavenger hunt into a non-event.
The same problem exists on other clouds with different mechanics: see offboarding from GCP and Azure.
Where Korvalis fits
On AWS the leftover problem is long-lived keys. Korvalis hands out access that expires on its own, so there are far fewer standing keys to hunt down when someone leaves. And because it watches live sessions and cuts off a destructive command before it finishes, it covers the gap between the moment someone walks out and the moment the last key is gone. It installs inside your own AWS account.
Frequently asked questions
Does removing someone from IAM Identity Center revoke their access? Not fully. It stops SSO logins, but long-lived IAM access keys and already-issued STS sessions keep working until removed or revoked.
What do people forget to revoke? IAM access keys, active sessions, EKS access, CodeCommit credentials, CI tokens, and EC2 key pairs. The long-lived access keys are the most common miss.
How fast should you revoke? Deactivate keys and revoke sessions first, ideally within minutes for a sensitive departure, then do the full sweep.
If you’d rather have little left to revoke, see how Korvalis handles access or join the waitlist.