Offboarding

Deactivating an account stops future access, but a person who leaves may own a personal work vault, be Custodian of shared vaults, and have seen passwords that are still valid. The Offboarding screen handles all of that in one step.

Running an offboarding

Open System → Offboarding, or choose Offboard user next to an account in the user list. Vaultigen refuses to finish until two kinds of decisions are made:

1. Each personal work vault the user owns:
   • Convert to a shared vault: keep every entry and folder, and name a new Custodian and Manager.
   • Archive: keep it, frozen.
   • Mark for purge: freeze it now; it is removed permanently after the retention period.
2. Each shared vault the user is Custodian of gets a new Custodian. A vault can never be left without one.

When you submit, the account is deactivated and all its sessions, trusted devices and reset tokens are revoked in the same transaction. Every decision is recorded in the audit log.

Credentials to rotate

Revoking access cannot make someone forget a password they saw. Vaultigen therefore tracks which entries a person revealed, and the offboarding report lists them as credentials to rotate: entry title, vault, type and when it was last revealed. Never the value.

The list records what Vaultigen delivered, not whether the person copied it. Treat every listed entry as potentially exposed.

Rotating external credentials

The same procedure applies after an offboarding or an emergency access session:

1. Group the affected entries by the external system they belong to.
2. Change the credential in the external system first, then update the Vaultigen entry. That way the old password stops working before the new one is stored.
3. For API keys and tokens, revoke the old value instead of only adding a new one.
4. Record what you rotated, and note anything you could not rotate.
5. If the person revealed the installation’s own admin credentials, reset those too and treat the event as an admin compromise.