I’d like to request a feature enhancement to better support organizations using SSO as their identity and access management solution.
Request:
Please consider introducing an administrative control or policy that allows organizations to disable the ability for users to configure additional two-step login (2FA) methods when SSO is enabled and used as the sole authentication method.
Business Justification:
We recently experienced a case where a user added a TOTP-based 2FA method to their SSO-enabled company-provided and owned Bitwarden account. The user then lost access to their TOTP device and had not retained the recovery code. Despite using SSO for login, Bitwarden enforced the additional 2FA, effectively locking the user out of their vault. Due to Bitwarden’s zero-knowledge architecture and the inability for admins to override or remove 2FA, this situation rendered the vault inaccessible and required account deletion causing significant delays in service delivery to our clients.
This outcome is problematic in enterprise SSO environments where the SSO/IdP already handles all multi-factor authentication.
In these scenarios, additional user-configured 2FA creates an unnecessary risk of user lockout with no administrative recourse. While we understand and value Bitwarden’s zero-knowledge model, the lack of a control to prevent or disable user-configured 2FA in SSO environments is a significant gap.
This is why we should be evangelizing emergency sheets to our users. Data loss happens.
Although your focus is recovering the employee’s enterprise account, there is more to it. Enterprise accounts come with free family plans. Users need training in disaster preparedness because there is no ability for the enterprise to recover a spouse’s account despite the fact that the enterprise was complicit in providing the license.
I would also like to note that after provisioning a new Bitwarden account for the user, an administrator had to reassign hundreds of collections to the user manually.
As you used the title “Ability to Disable User-Added 2FA When SSO Is Enforced” I would like to ask you which of those two possible things you meant for this feature request:
You would like to have the ability (for an organization) to indeed disable a 2FA that a user set up (which probably would also be a request to essentially circumvent the existing 2FA of a user) or
You would like to enforce this as any other policy – and when there is a user who already set up 2FA for themselves they would have to deactivate their 2FA themselves to comply with the policy
?
Could you please clarify what exactly you meant for that part?
Both aspects are important for this request. Ideally, administrators would be able to configure a policy before going live that prevents end-users from setting up 2FA at all. Since that option doesn’t currently exist and some users may already have enabled 2FA, it would also be valuable to have a policy that (1) blocks new 2FA setup going forward and (2) automatically disables 2FA for users who previously configured it.
Hopefully this explanation clarifies the intent of the request.
I think what happens with users that don’t already have 2FA enabled is undisputed.
So, for users who do have 2FA already enabled, you indeed would like the organization to be able to deactivate that 2FA for users automatically = force them out of their 2FA, so to speak. Right?
I’m asking because, we have a similar new feature request (Add an Enterprise Policy to forbid users from enabling two-step-login) but OP there wouldn’t want the organization to disable 2FA for the users, but that the user would deactivate 2FA themselves “to become compliant before their access can be restored.”
Like it is with other policies when enforced:
warning
Organization members who are not owners or admins and do not comply with this policy will have access revoked when you activate this policy. Users who have access revoked as a result of this policy will be notified via email, and must take steps to become compliant before their access can be restored.
So the question was, if your two feature requests could (and should) be merged when and if they are same – or if they differ and should stay separate. (and the difference should then be made more clear also)