Offboarding that actually ends access.
When someone leaves, their access should leave with them: laptops, servers, cloud, code and every key they registered. Here’s a checklist you can use today, and how Bastyx is designed to do it in one step.
Concept UI with sample data. The product is in development and details will change.
Why offboarding leaves access behind
Most teams disable the identity provider account and consider the job done. But at a technical company, much of the access that matters never went through the identity provider in the first place.
- SSH keys live on servers, not in your directory. Suspending an account doesn’t remove them.
- Tokens outlive accounts. Cloud access keys and personal access tokens keep working until someone revokes them explicitly.
- Shared secrets can’t be un-shared. Anything a person could read in a shared vault has to be rotated.
- Nobody has the full list. Access was granted by different people in different tools over months or years.
The access offboarding checklist
Work through every area, even if you think it doesn’t apply. The access that gets missed is usually the access nobody remembered granting.
Identity and sign-in
- Suspend the identity provider account and end active sessions
- Remove the person from groups that grant access elsewhere
- Revoke registered passkeys and security keys
Devices
- Disable sign-in on every laptop and workstation they used
- Recover company hardware, or lock and wipe it remotely
- Remove local admin accounts created for them
Servers and SSH
- Remove their public keys from every authorized_keys file
- Rotate any shared account keys they had access to
- Check jump hosts and bastions separately
Cloud
- Delete or disable IAM users and their access keys
- Remove role assignments and federated access
- Review resources they created that grant access, such as keys and service accounts
Code and CI
- Remove them from the source-control organization
- Revoke personal access tokens and deploy keys they created
- Check CI secrets and runners they configured
Shared secrets
- Rotate passwords in shared vaults they could read
- Rotate API keys and database credentials they handled
- Update break-glass credentials if they knew them
Records
- Record what was revoked, when and by whom
- Keep the record where your next security review can find it
One action instead of a checklist
Bastyx is designed so the access on that checklist is granted through one identity in the first place. That makes revoking it a single step:
Offboard the person
Now, or scheduled for their last day.
Every path is revoked
Device sign-in, SSH, cloud roles, apps and registered keys.
The record is kept
What was removed, when and by whom, ready for review.
Offboarding questions
How quickly should access be revoked?
For a planned departure, at the end of the last working day. For an involuntary departure, before or during the conversation. The goal is that access ends when employment does, not days later.
Can we schedule an offboarding in advance?
That’s part of the planned design: set a date and time, and Bastyx revokes everything then, so nobody has to remember at 5pm on a Friday.
What about access Bastyx doesn’t control?
Bastyx can only revoke what it manages. The planned access inventory shows what’s covered, so the remaining manual steps are explicit rather than forgotten.
Does offboarding delete the person’s audit history?
No. The design keeps their event history intact after offboarding, because that history is exactly what you need if questions come up later.
Revoke once. Revoke everywhere.
Your developer left Friday. Their access should end Friday. Join early access and help us build it.