Offboarding a teammate

When someone leaves the team, or can no longer be trusted, they still have everything they already saw. Crunu can't erase that. What it does is cut off new access, change the keys, and tell you exactly which values to replace.

Example. Kiteline is a fictional company. Tom Halvorsen is leaving. Priya removes him with the wizard, downloads the report for the security team, and works through the reissue checklist.

Removal does three things:

• The server stops serving the person anything in this organization at once.
• Environment keys change wherever they had a key, so their old key opens no new version, even if they later get hold of the ciphertext.
• The exposure report shows which versions of which environments the server gave them and when, and the reissue checklist lists the values they saw that are still in use.

If the person was an admin or owner, they knew the organization's signing and recovery keys. The wizard then also moves the organization to a new key generation: every certificate is reissued and every shared environment gets a new key.

Who can do it

An owner or admin, in the web app. Only an owner can remove an admin or another owner. The wizard rotates keys in your browser, so keep the page open until it finishes.

1. Open the wizard

Members, the person, Remove from organization….

If the person isn't leaving but has lost their password and Secret Key, use Employee recovery… first to move their personal data to a new account.

2. What the employee has

The first step shows:

• The exposure report. For each environment: their current access, Versions received, when, from which addresses, and whether they had the current key or an earlier one. It comes from the server's delivery record.
• The reissue checklist. Values they received that are still in use. Your browser compares the versions they received with the current ones. Only file paths and field names are shown, never values.
• What they could have carried away. Service tokens they created and saw, machines not yet approved whose enrollment code they may have kept, invitations and share links they created. Tick what to revoke.

3. What will be done

Check the plan:

• removal from every environment and every access profile;
• new keys for the environments where they had a key, or a new organization key generation for an admin or owner;
• a new signed revocation list, so agents and apps stop accepting signatures they make after the removal;
• revocation of what you ticked.

Confirm that you understand, then choose Remove and rotate keys.

4. Run

Keep the page open. If you close it, what's done stays done, and the rest appears in Pending actions.

5. Report

For each environment the result says, for example, access removed, environment key rotated.

• Download report and keep it. It's the document for your security team and auditors. The report and your "reissued" ticks exist only on this page, because the member is already removed.
• If some environments are waiting for a key holder, open Pending actions and ask someone who holds the key of those environments to open the web app. The rotation runs for them.
• If the person had a personal project and recovery of personal environments is on, you can open it with the organization recovery key, take what you need, and delete it. If their personal environments were sealed only to their own key, the organization can't read them, by design.

6. Reissue values at providers

Go through Reissue at providers. For each value: issue a new secret where it came from, such as a new cloud access key or a new database password, save the new value in the environment, and tick the item. Where to reissue links to the provider for known services.

7. Everything outside Crunu

Crunu doesn't manage access elsewhere. Remove the person from your providers' consoles, repositories and CI separately. If they had access to your server's hosting or its .env file, rotate the server key. See Rotate the server key.

How to check

• The person is no longer in Members. The audit log shows the removal, the new revocation list and a key rotation for each environment.
• Pending actions is empty.
• The reissue checklist is done.
• Their sessions no longer open the organization. Their account itself remains, because it may belong to other organizations.

What removal doesn't do

• What they already saw stays with them until you reissue it.
• Signatures they made before the removal stay valid, otherwise old versions couldn't be read. Apps compare signature times with when the server received them, and the revocation list stops their signatures made afterwards from being accepted.