The Developer Offboarding Credential Checklist (What Most Teams Miss)
When a developer leaves your company, there's usually a clear offboarding process for the obvious things: return the laptop, remove the email account, revoke the GitHub access. But credentials are different. Developers accumulate access to dozens of services over their time at a company — and most teams have no systematic way to find it all when they leave.
This guide covers what good developer offboarding looks like for credentials specifically, and provides a practical checklist you can start using immediately.
Why Developer Offboarding Is a Credential Security Problem
Developers have more credential access than any other role at a typical technology company. They set up integrations, create API keys for services they're building against, own database connections, and generate tokens for third-party platforms. Over time, each of these represents a potential attack surface that survives their departure.
The challenge is that credential ownership is invisible without a system tracking it. If a developer generates an AWS access key for a side project they were leading, and that project is later deprioritised, that key often lives indefinitely in a config file somewhere — with no reminder to rotate it when the developer leaves.
What Happens When Offboarding Is Done Wrong
The consequences of incomplete credential offboarding are usually not discovered until something breaks.
A real scenario: An S3 bucket stopped responding three months after a developer's departure. Investigation revealed that the AWS access key used for that bucket had been generated under the departed developer's personal IAM account — which had been deactivated. The team had to regenerate credentials under a service account, update three separate services, and coordinate a deployment across two environments. One hour of work that should have been done during the offboarding process turned into an emergency.
A worse scenario: A former employee retains a valid GitHub personal access token they generated before leaving. GitHub tokens don't expire by default and can survive an account deactivation if they were generated before the account was removed from the organisation. Without a systematic inventory, no one knows the token exists.
The common thread: things that were set up informally, tracked nowhere, and never handed over properly.
The Complete Developer Offboarding Credential Checklist
This is not a checklist you fill out when someone is leaving. It's a checklist you build the capacity to fill out — which requires having a live credential inventory before anyone leaves.
Before the last day:
- [ ] Enumerate every project the developer is a member of
- [ ] List every credential they added (tracked via
addedByin your credential management system) - [ ] List every credential they had visibility access to
- [ ] Identify any credentials only they could see or access
- [ ] List every external service they set up or own
Access revocation:
- [ ] Rotate any credentials only they had visibility on — generate new values
- [ ] Revoke personal access tokens they generated under their own account
- [ ] Remove from GitHub organisation and all private repositories
- [ ] Remove from cloud provider accounts (AWS IAM, GCP, Azure AD)
- [ ] Remove from deployment platforms (Heroku, Vercel, Railway, Fly.io)
- [ ] Remove from SaaS tools they had admin access to
- [ ] Revoke API keys generated under their account for third-party services
- [ ] Remove from database access (direct DB users, not just app-level)
- [ ] Remove from monitoring and alerting tools (PagerDuty, Datadog, etc.)
Handover documentation:
- [ ] Document which credentials were rotated and what they connect to
- [ ] Record who the new owner of each credential is
- [ ] If they were the sole owner of a service account, transfer ownership formally
- [ ] Update any runbooks that referenced their personal accounts
How to Make Offboarding Faster and Less Stressful
The checklist above is only completable if you have the information to fill it out. Most teams don't — and that's the real problem.
Maintain a live credential inventory. A credential management tool that tracks who created each credential, who has visibility, and which project it belongs to turns a chaotic offboarding into a query. You can answer "what did this person have access to?" in minutes, not days.
Assign credential ownership at creation time. When someone creates an API key, it should be recorded under a project and a team — not just their personal account. If it lives in a team vault, offboarding automatically transfers custody.
Automate the revocation steps where possible. Many platforms support programmatic access removal (GitHub API, AWS IAM API, etc.). For large teams, automating the mechanical steps reduces the chance of something being missed.
The Goal: Zero Standing Access for Ex-Employees
The target is simple: from the moment a developer's departure is confirmed, their countdown to zero access should begin. By their last day, or shortly after, every credential they personally owned should be either rotated or transferred. Every personal token should be revoked. Every cloud account removed.
This does not require a huge process overhaul. It requires a credential inventory — knowing what exists, who owns it, and where it is. Once you have that, a thorough offboarding checklist becomes a 30-minute task instead of a 3-week investigation.
Don't find out the hard way what access someone still has.
SlateBeaver tracks every credential by project, owner, and visibility. When someone leaves, you can audit their access in seconds and offboard completely — no missing keys, no standing access, no surprises months later.