Offboarding: keys to reissue
1. Close their access
2. Reissue keys they could read
No services selected yet.
FreeNo sign-up
Offboarding checklist: what to reissue when someone leaves
Pick the services the person could reach and get an ordered checklist: close their access first, then reissue each key, with a link to where you make a new one, then check what happened. Copy it into a ticket or print it.
Runs in your browser. Nothing you type is sent anywhere.
The tool is code on this page. It makes no network requests while you use it, stores nothing in cookies or local storage, and keeps working if you go offline after the page loads.
Offboarding checklist generator
Runs in your browser
Appears only in the copied text and the printout.
Checklist
How to use it
- Tick every service the person could reach. When unsure, tick it: an extra item costs minutes, a missed key stays valid.
- Add a name or role if the checklist goes into a shared ticket.
- Copy it as Markdown into a GitHub or GitLab issue, where the boxes become checkboxes, or print it.
- Work through it top to bottom. Ticking boxes here helps you keep your place, but nothing is saved: close the tab and the list is gone.
Use it as a ticket template
The Markdown version uses - [ ] items, which GitHub and GitLab issues render as checkboxes. Keep a copy as an issue template, and generate a fresh one for each departure so the service list matches what the person could actually reach.
Why this order
Close access first
If the person can still sign in to your vault or your Git host while you reissue keys, they can read the new values as they arrive. Removing access first makes everything after it count.
Reissue everything they could read
A key someone could read has to be treated as known, whether or not they ever looked. Without records of who decrypted what, the safe list is every key in every environment they had access to.
Revoke the old key last
Issue the new key, deploy it, confirm the app works, and only then revoke the old one. Services that let both keys work at the same time make this a change with no downtime; the rest need a short planned window.
How Crunu handles this
A checklist built from what the person could decrypt
Crunu's offboarding wizard starts from records instead of memory: an exposure report of which versions of which environments the person received, when and from where, and a checklist of values to reissue at providers, without the values themselves. It revokes what they carry, such as tokens, access links, invitations and machine enrollment codes, and changes the keys of the environments they could read. Crunu doesn't reissue keys at your providers; it lists which values to reissue and stores the new ones once you save them.
Read about offboarding in CrunuQuestions about this tool
Found a case the tool gets wrong? Write to support@crunu.com
Do I really need to reissue every key?
Every key the person could read, yes, unless you have records showing they never received it. That's why the list starts from services, not from what you remember them using.
What about personal access tokens?
On GitHub and GitLab, removing someone from the organization or group cuts what their personal tokens can reach there. Keys created inside a shared account, such as an AWS IAM user's access key or a Stripe restricted key, stay valid until you delete them.
Is my checklist saved anywhere?
No. It lives in this tab until you close it. Copy it or print it before you leave the page.
A service I use isn't on the list.
The list is based on the service directory the Crunu app uses. For anything else, add it to the copied Markdown with the same four steps: issue, store and deploy, confirm, revoke.
Read more
Other free tools
- Secret key generatorRandom secrets in Base64, Base64URL, hex or letters and digits, from 128 to 512 bits, with a ready .env line.
- .env linterFinds lines that loaders read differently, values that run as commands when sourced, duplicates and values that look like real keys.
- .env converterTurns a .env file into JSON, YAML, a Docker --env-file or a systemd EnvironmentFile, and back again.
- Compare two .env filesShows which variables exist in only one file and which have different values, with values hidden until you ask.
- OIDC trust policy builderTrust policies and credentials for GitHub Actions, GitLab CI and Bitbucket Pipelines on AWS, Google Cloud and Azure, with the CI snippet.
When the values need a home
Crunu is a vault for your team's environment variables and keys. Values are encrypted on your devices, so the server stores them only as ciphertext. Free during early access.