Offboarding employees from shared vaults — what actually needs to happen

Credential offboarding is one of the most consistently underdone steps in employee offboarding. IT departments disable the SSO account, revoke device access, and recover hardware — then mark offboarding complete. The shared credentials the departing employee had access to remain unchanged. An ex-employee who knows the shared API key, the admin panel password, or the social media account credentials retains access to those systems regardless of whether their vault access has been revoked.

Password managers make this problem more visible but don't automatically solve it. Removing an employee from the vault prevents them from using the vault to retrieve credentials. It doesn't change the credentials they retrieved before access was revoked. The vault is a distribution and management layer; it is not a technical enforcement layer that invalidates credentials at the source.

Complete credential offboarding requires both vault access removal and rotation of shared credentials the departing employee had access to. Both steps are necessary; either alone is insufficient.

The assumption 'removing SSO access removes vault access' depends on implementation. If the company password manager is integrated with SSO and access is provisioned/deprovisioned via SCIM, disabling the SSO account may propagate to vault access immediately. If vault access was provisioned independently of SSO, the two systems need to be deprovisioned separately. Verify the dependency before assuming.

A second assumption is that audit logs show everything the employee accessed. Vault audit logs show credential views within the vault interface. They don't show credentials that were retrieved and stored in the employee's personal systems before departure, or credentials shared externally through the vault's sharing features. Audit logs are useful for post-incident investigation; they are not a complete record of credential exposure.

A third assumption is that urgent departures (involuntary terminations, resignations with immediate effect) allow time for organised offboarding. For security-sensitive roles, the offboarding should be designed so that SSO account disabling immediately removes access to all systems, including the vault — before any conversation about the termination takes place. Credential rotation is a separate subsequent step, not something to do during the conversation.

The complete offboarding checklist for shared credential access: (1) Revoke vault access via admin console (immediate). (2) Identify which credential collections the employee had access to, using audit logs and access records. (3) Rotate shared credentials in those collections — this is the step most organisations skip. (4) Verify SSO and SCIM deprovisioning have propagated correctly. (5) Check for directly-shared credentials (One-Time Shares, Bitwarden Sends) that may have been created by the departing employee and are still active.

Rotation prioritisation: rotate high-consequence credentials (administrative access, financial systems, production infrastructure credentials) within hours of departure. Rotate medium-consequence credentials (internal tools, project management systems) within the same day. Low-consequence credentials (team streaming accounts, shared communication tools) can be rotated on the next cycle.

Systems with individual account access (email, SSO-linked services) handle their own access control through SSO deprovisioning. Systems with shared credentials — social media accounts, shared API keys, database passwords, administrative portals — require credential rotation because there is no individual account to disable.

This guide addresses shared credential offboarding. Individual account offboarding — email accounts, SaaS accounts with individual logins, cloud platform user accounts — is handled by SSO deprovisioning and is outside this scope. The shared credential problem is a separate, complementary concern.