The onboarding and offboarding checklist every dev team skips

Most engineering teams have some version of an onboarding process. Fewer have an offboarding process that gets the same attention — and that asymmetry is where credential sprawl and security gaps quietly build up.

Why onboarding usually works out fine

New hires create urgency. Someone wants them shipping code in their first week, so a manager or a teammate personally walks them through getting access to the repositories, staging environment, and any third-party services they need. It is manual, but it works, because someone is motivated to make it work quickly.

The problem is that “manual but motivated” does not scale, and it leaves no record of what was actually granted.

A better onboarding checklist

A documented onboarding checklist should answer, for any new hire, exactly what they need and where it lives:

  1. Repository access — which repos, and at what permission level.
  2. Environment credentials — staging and local values for every service the role touches; production access granted separately and only when actually needed.
  3. Third-party accounts — cloud provider console, CI/CD dashboard, error tracking, analytics — whatever the team actually uses day to day.
  4. SSH access — their own key pair added to the relevant servers, never a shared key.
  5. A vault invite — access to the team’s shared credential workspace, scoped to the projects they are actually working on.

Written down once, this becomes a checklist instead of a conversation that happens slightly differently every time — and it gives you a record of exactly what any given person has access to, which is the piece most teams are missing entirely.

Offboarding is where teams fall behind

Offboarding does not have the same built-in urgency. The person is leaving anyway, so revoking their GitHub seat and disabling their email often feels like enough. It rarely is.

Here is what a real offboarding pass needs to cover, ideally on the day someone leaves rather than “sometime that week”:

  • Revoke repository access across every repo, not just the ones that come to mind first.
  • Rotate any shared credential they had access to. If a production database password or API key was ever visible to them, treat it as compromised the moment they leave — not because you distrust them, but because credentials that are not rotated on departure are credentials nobody can account for.
  • Remove their SSH public key from every server’s authorized_keys.
  • Revoke third-party service access — cloud console, CI/CD, monitoring, analytics, payment processor dashboards if applicable.
  • Check for personal API tokens they may have generated under their own account for CI or automation, which do not disappear automatically when their seat is removed.

Why “rotate everything” sounds extreme but usually isn’t

Teams often push back on rotating every shared credential a departing person had access to, because it sounds like a lot of work for someone who left on good terms. But the point is not distrust — it is that once access has been granted, you can no longer prove it has not been retained somewhere: a laptop backup, a password manager export, a note file. Rotation is the only way to close that gap with certainty, and it is far cheaper to do routinely than to do under pressure after an actual incident.

This is exactly where a project-based vault helps: if every credential for a project lives in one place, rotating “everything this person touched” is a bounded, checklist-sized task instead of an open-ended search across a dozen tools.

Making both processes actually stick

The checklist only works if it lives somewhere durable and gets used every time, not just when someone remembers. A short, written document — even a simple shared checklist — beats institutional memory, because institutional memory leaves the building along with whoever was carrying it.

Bottom line

Onboarding gets attention because someone wants a new hire productive fast. Offboarding deserves the same urgency, because every day of delay is a day a departing person’s old credentials remain valid. Treat both as first-class processes with a written checklist, and the gap between “who has access” and “who should have access” stops being a guess.