Skip to content
Create free account
Create free account
Teams8 min read

An offboarding checklist for engineering teams

Removing an account takes seconds. Secrets outlive it. A practical checklist for engineering offboarding, from sessions and tokens to reissuing values.

Crunu teamPublished 8 min read

Example. Kiteline is a fictional company.
On this page

When someone leaves an engineering team, the HR checklist covers the laptop, the badge and the email account. The engineering part is harder, because engineers accumulate credentials: cloud access keys, API tokens, database passwords, deploy keys, the .env file from their first week. Disabling their sign-in stops new access. It does nothing about values they already saw.

This post is a working checklist. It applies whether the person is leaving the company, moving to another team or finishing a contract, and whether the departure is friendly or not. The order matters: some steps destroy the evidence you need for later ones.

The principle: access ends, knowledge does not

Every offboarding step falls into one of two groups.

  • Cutting access. Accounts, sessions, tokens, keys. This is quick, mostly reversible and fully under your control.
  • Dealing with knowledge. Secrets the person has seen and may have copied. You cannot make anyone forget a value. You can only make it worthless by replacing it at the provider.

Teams tend to do the first group well and skip the second, because it is slow and nobody has a list of what the person saw. A good process produces that list.

Before the last day

If the departure is planned, an hour of preparation saves a lot of guessing later.

  • Inventory systems. List every system the person could reach: identity provider, email, code hosting, CI, cloud consoles, the secrets vault, monitoring, chat, the password manager, production hosts.
  • Find shared credentials. Note which secrets were shared with the team rather than issued to the person: a shared AWS access key, a database admin password, a payment provider key. Those are the ones that need reissuing.
  • Hand over ownership. Repositories, cloud resources, scheduled jobs and on-call duties that are registered to the person should move to someone else. Jobs that run under a personal token stop when that token is revoked, and the outage tends to land on a Friday.
  • Pick a time. Do the removal at the end of the last working day, or immediately if trust has been lost.

Step 1: cut access to accounts and sessions

Start with the systems that issue all the others.

  1. Identity provider and email. Disable the account and end active sessions.
  2. Code hosting. Remove the person from the organization. On GitHub, a removed member loses access to private forks of the organization's private repositories, and pending invitations they sent are canceled. GitHub's documentation also notes that you are responsible for making sure people who lost access delete confidential information they still hold locally (GitHub Docs).
  3. Cloud consoles. Remove or disable their user in each cloud account.
  4. CI and deploy tools. Remove their account and check for jobs that run as them.
  5. The secrets vault. Remove them from the organization in the vault. This is where you will get the list for step 3, so do it with care.
  6. Chat and ticketing. Remove them last among the work tools, so that colleagues can still reach them during the handover.

Step 2: collect what they carry

Credentials do not only live in accounts. Some travel with the person.

  • Personal access tokens and API keys they created under their own user at GitHub, cloud providers and SaaS tools.
  • SSH keys they added to servers, deploy targets or bastion hosts, including entries in authorized_keys that are not tied to any central account.
  • CI tokens they created for pipelines, which may keep working after their account is gone.
  • Links and invitations they created: file shares, pending invites to tools, one-time links to secrets.
  • Enrollment codes or bootstrap credentials for machines that were never finished.
  • Local copies: .env files, ~/.aws/credentials, kubeconfig files, exported backups on their laptop. If the device is returned, wipe it. If it is not, assume the files are gone with it.

Step 3: work out what they saw

This is the step that turns a vague worry into a list. You want to know, for each environment, whether the person could read it, and which versions they actually received.

If your secrets live in a vault that records fetches, this is a report. If they live in chat and shared drives, it is detective work: search conversations and folders the person had access to, and assume that anything visible to them was seen.

Write the result down as a list of values, not a list of systems: "production Stripe secret key", "staging database password", "AWS access key for the deploy user". That list drives the next step.

Step 4: reissue values at the providers

For each value on the list, create a new one at the provider, deploy it, and disable the old one. The order avoids outages.

AWS access keys. AWS recommends a no-downtime sequence: create a second access key while the first is still active, update every application to use it, check the old key's last-used information, deactivate the old key rather than deleting it, confirm nothing broke, and only then delete it (AWS IAM User Guide). The same page names an employee leaving as a reason to update keys.

Stripe API keys. Stripe's dashboard can rotate a key and keep the old one working for up to seven days while you migrate. If you need longer, Stripe suggests creating a new key manually, moving to it, and then expiring the old one. Stripe also lists a team member with access leaving the organization as a reason to rotate (Stripe Docs).

Everything else. Database passwords, webhook signing secrets, SMTP credentials, third-party API keys. Most providers support either two active credentials at once or a grace period. Use it.

Prioritize by impact: payment and banking credentials, cloud account keys with broad permissions, production database passwords, then everything else. A grace period is a window in which the old value still works, so close it once your services have switched over.

Step 5: rotate the vault's own keys

If your vault encrypts environments with keys, the departing person's key access must end too, so that new versions are unreadable to them even if they somehow obtained the ciphertext. In a well-designed vault this happens as part of removal. If the person was an administrator, the vault's organization-level keys need replacing as well.

For self-hosted infrastructure, check whether they had access to the server that runs the vault, its configuration file or its backups. If so, rotate the server's own secrets.

Step 6: record what you did

Keep a short record with the date, the systems removed, the exposure list and which values were reissued when. It is useful for audits, and it is the first thing you will want if a leaked value turns up months later.

How Crunu handles the vault part

Crunu treats offboarding as a first-class flow called Member removal. Owners and admins run it from the member's page with Remove from organization…. It has four steps: What the employee has, What will be done, Run and Report.

  • What the employee has. An exposure report built from the server's record of fetches: for each environment, the person's current access, which versions they received, when, and from which addresses, and whether they held the environment key. Next to it, a reissue checklist of values they saw that are still valid, compared in your browser and shown by file path and variable name only. And a list of what they may carry: service tokens they created, machines awaiting approval whose enrollment code they may have kept, their invitations and share links.
  • What will be done. Removal from all environments and access profiles, rotation of the keys of every environment where they had one, a new signed revocation list, and revocation of whatever you ticked. If the person was an admin or owner, the organization moves to a new generation of keys and all certificates are reissued.
  • Run and Report. Rotation happens in your browser, so keep the page open. Anything unfinished appears under Pending actions. The report can be downloaded for your security records.

The server stops serving the person anything in the organization immediately. Their old keys cannot open any new version.

What Crunu does not do is equally important. It does not reissue values at AWS, Stripe or anywhere else; the checklist tells you which ones, and for well-known services it shows where to issue a new key. It does not manage access outside itself, so steps 1, 2 and 4 above remain yours. And if an environment's key was sealed only to people other than you, its rotation waits for one of them to open the web app. See offboarding a teammate and the offboarding feature.

The checklist

Copy this into your runbook and adapt it.

Contractors and agencies

Contractors deserve the same checklist, with one change: plan the ending when you plan the start. Grant them access through a named access profile rather than one environment at a time, so removal is a single action. For one-off files, use expiring share links instead of accounts; they stop working on their own. The post on sharing a secret with a contractor covers that case.

Offboarding is rarely urgent until it is. A process that produces an exposure list on the day someone leaves turns an open question about what the person had into a short list of values that were reissued, with dates.

Sources

Terms in this post