When a user is offboarded, it’s a pain to remove their account completely. Revoking from the Org is one thing, deleting their personal vault is another.
Either I need to redirect their email to a mailbox I have or I need to know their master password. Neither is a good idea.
My request is to provide an option that an admin can delete an account WITHOUT needing a verification email. Limit it to just accounts in the org with revoked permissions.
According to this comment from a Bitwarden team member on another post, it appears this may be covered in an upcoming planned roadmap feature labeled under Account management and deprovisioning.
Hi @cksapp
I did review that topic before posting this one - you can see my reply in there - but that has to do with automated offboarding and this request has to do with an administrator being able to trigger it on demand.
That post specifically is regarding automation of User management with the directory connector yes, though this simply makes calls to the Public API for adding/removing those users from the Organization.
So if some type of improvements and features are added for better corporate account management and deprovisioning I would also expect them to be prevalent in the web-vault as well most likely.
I guess we’ll just have to wait and see what the future holds , the additions may take care of your request here but no telling until they are added and released.
Possibly this topic can be revisited once those features go live.
I agree we will just have to wait and see what the future holds. Hopefully you are correct and the additions mentioned there will directly resolve this request as well.
This is rather risky though, if the personal vault is still maintained by the user. For example, I have my personal vault and I joined an organization for my company’s plan. I certainly wouldn’t want the company to be able to delete my personal vault.
Ahh, this really isn’t ideal and IMHO where there should be an enterprise policy (whether an organization uses it or not would be up to them) to allow for a simple domain allow-list and restrict users’ account email.
Bitwarden does not recommend you combine work and personal credentials as this is considered unsafe.
Best practice would be to have a work Bitwarden account associated with your work email for any of those logins.
Any personal items can be stored in a Bitwarden account tied to your personal email, and can easily be facilitated with the use of account switching currently.
Bitwarden offers an actually useable and wonderful free plan, or if available you can take advantage of the Enterprise Families Plan Sponsorship by redeeming this to your personal email.
Regardless of what they consider safe, most people will want to use one password vault. The ability to invite users to join an Organization isolates that particular vault from the personal one. I’ve already gotten confused looks from people as I explain the difference between their personal vaults and the organization vault.
Account switching is not easily done and it’s a time-consuming process (especially with MFA enabled). With LastPass, you were able to share passwords with another user fairly simply (even without exposing the password itself). That is not the case with Bitwarden, so having two or three Bitwarden accounts adds overhead and complexity to users who are just trying to maintain their passwords.
The problem is that it’s not hard to save work related information in the personal vault, regardless of if it’s intentional or not. So when a user is offboarded we need to be sure they no longer have access to the company information, regardless of where it’s stored.
You shouldn’t be doing anything personal in work - unrelated to Bitwarden - so this shouldn’t be an issue. In fact, in many companies, it’s against the acceptable use policy to use the company equipment for personal use. So this really shouldn’t be an issue to start with and for the few companies that allow personal use for company equipment, they won’t delete the vault. They will let the user have it and away they go. But for Enterprise customers we should have some way of ensuring that data is gone and can no longer pose a risk to the business.
As a business, I don’t care what makes my employees personal lives easier (I personally do, I’m speaking here as the business, not myself). They shouldn’t be using their PC for personal use. Work is for work and personal stuff needs to handled outside of work. Honestly there should be a policy that prevents signing into the Bitwarden personal account on a PC managed by the org. Some sort of setting I can push in the chrome/edge extension that says “this is a business account, here are the allowed domains, block all others”.
That is true, and in an ideal world, it would be fine, but in a small business environment with remote work-from-home situations, not everyone can afford to manage all of that.
Alternatively, you could enable the policy to disable the individual vault:
For the companies who are not ready to manage all that, they can just not delete the personal vault when offboarding a user.
The only issues with turning off personal vault is that then you need to make a collection for each user and an owner can see the contents.
We want to provide a “zero admin knowledge” place to store passwords for each user. So a collection per user, which also introduces a massive amount of work, doesn’t work. Nor does enabling admin password resets, because an admin can then just reset and see inside the personal vault.
But at the same time we need to provide a way to remove that data when the user is offboarded. As of right now all we can do is the “delete via email verification” option which doesn’t cover 2 cases:
The users mailbox is gone (in which case we either need to re-create it or redirect that email to another mailbox).
The user changes the email associated with Bitwarden to a personal one.
Option 1 is a massive pain to handle and this request is to make it easier. I’ll open a second feature request if I can’t find one to have a policy to disallow email changes for enterprise accounts to handle #2.