Offboard Users via Directory Connector from both Organization and Personal Vault

Feature name

  • Offboard Users via Directory Connector from both Organization and Personal Vault

Feature function

  • What will this feature do differently?
    Currently, automatic sync via Bitwarden Directory Connector will offboard users from Organization, but not from Personal Vault. We would like Personal Vault not to be accessible when user is de-provisioned from the source directory. Currently, user has to be deleted from the System Administrator Portal.
  • What benefits will this feature bring?
    Easier user termination process - fully automated.

Related topics + references

Another good request @MilicaMij :slight_smile:

This is actually on our todo list for Q4 or so - stay tuned!

Thanks a lot for the update! :slight_smile:


Is there any update on this?

Thank you in advance.

The roadmap has updated timelines for this feature :+1:

Thank you for fast and prompt reply! :slight_smile:


May I ask for an update when this will be implemented?

Thank you in advance.

1 Like

Hi @MilicaMij, it’s on our 2022 Roadmap, but we don’t have a specific ETA at this time, subscribe to the release notes to be notified of changes automatically.


Is there any update on this?


The team is working on this one and we will share information as it becomes available.


Hi, is there any update on this? We are an Enterprise customer with 285 seats and really would love to this implemented. Mostly all other self hosted software we use that is integrated with our Active Directory automatically blocks or deletes users as soon as they are blocked in our AD. We have several people coming and leaving our organization every month. Removing them manually each time from Bitwarden is really annoying and error prone, especially in fast offboardings.

Hi @richardklose and welcome to the community :tada:

Just to give a quick update on this. This will be part of “Account Management and De-Provisioning” which is on our Roadmap

Depending on your environment and requirements, you might be able to use SCIM instead. SCIM is a standardized way of integrating with IdPs and supports the On/Off-boarding process.

More information about SCIM can be found here

Kind regards,

1 Like

We use SCIM already and it doesn’t block access to the personal vault when an account in AD is deleted, just the company vault.
I’ve looked at the roadmap for 2023 and don’t see any callouts that would resolve this.

Hey @martin.tig while the team reviews, you can see details for advanced offboarding, including administrative take-over here: Onboarding and Succession | Bitwarden Help Center

Using the Master password reset policy, owners and admins in your organization can reset a user’s master password during offboarding.

Resetting a user’s master password logs the user out of all active Bitwarden sessions and resets their login credentials to the ones specified by the administrator, meaning that administrator (and only that administrator) will have the keys to the user’s vault data, including items in the individual vault. This vault takeover tactic is commonly used by organizations to ensure that employees don’t retain access to individual vault items that may be work-related and can be used to facilitate audits of every credential an employee may have been using.

Thank you for the information. We have reviewed the master password reset option in the past but it does not allow the “zero admin access” we require since an admin can reset the users password.

Compare this with LastPass where you can trigger a delete without knowing the password or signing in as the user. You can also suspend a users access totally or just revoke from company access.

Today we can only revoke company access, but cannot delete without access to the mailbox nor can we suspend access to personal vault (disable account, for example if employee is on FMLA and we lock out their accounts for the months they are away from work). We work around the suspend issue by requiring SSO and stopping it on the SSO side, but that doesn’t work for admin accounts.

If you control the email domain, you can also use the following to Delete an Account or Organization | Bitwarden Help Center

I believe they meant more so “cannot delete without having to access the mailbox”
See the comments from their related feature request.

So it seems they are already taking advantage of and using advanced off-boarding procedures in place currently with Admin Password Reset, and passwordless email-only account deletion.

As mentioned, I am personally very eager to see what additional features this will bring and how this can add to better management and deprovisioning of corporate user accounts.

One thing though as an aside, I wonder how much of this becomes moot seeing as a user can currently alter their login email. There are no enterprise policies to restrict users to a specific domain or prevent email changes.
Perhaps with the introduction of the domain verification this could be used to require a user of the Org has an associated email with that domain, or possibly just an enterprise policy to restrict users from changing their login email.

Oh wow, I somehow had no idea this was possible and this opens up so many other issues.
Really the only way I can see to get around this is disabling personal vaults and forcing each user to have their own collection, but that’s a major issue at scale. Plus it doesn’t allow for “zero admin knowledge” of passwords.

I too will be waiting eagerly for this to complete.

Hey @martin.tig the team is also working on ‘flexible collections’ which will allow for self-serve collection creation, even at the user level (don’t have to be a manager), as well as functionality to enable zero admin knowledge.

1 Like

@dwbit this is great news, because if I am understanding this correct, when implemented, we can disable personal vault and when a person is revoked from the org their passwords are gone too, regardless of it they changed the login email or not. And they can make the collection themselves and manage it without an Admin having access.