Manage Extension Settings for Enterprise Deployments

Our company is a macOS + Google Workspace shop. We are using cloud hosted Bitwarden with Google Workspace SSO and trusted devices. Our employees do not have master passwords for their vaults.

We have automated the installation of the Bitwarden desktop app and Chrome extension on our endpoints, but currently have to guide employees through manually setting up biometric unlock and vault timeout. Is there a way to configure the extension settings via modifying a local configuration file?

We’re aware that the vault timeout can be set via policy in the organization admin console. However, that setting has not been ideal for us. We want the vault timeout to lock the vault and for employees to be able to use biometrics to unlock the vault. If the policy is configured to lock the vault without biometrics being configured in the extension, then employees have to intuitively log out then log back in to “unlock” the vault (a side affect of trusted devices w/o master password). Is there anyway to enable biometrics programmatically?

Hi @Panic1077 and thanks for joining the Bitwarden community. I understand your request. Currently biometrics does need end user action on devices which I am not sure can be instrumented completely programmatically.
That said, the team continues to look at ways to enhance the options with Trusted Devices and is always evaluating onboard scenarios. This feedback is helpful for that.

Thank you for responding! I feared that might be the case, but glad to hear that the team is looking at ways to enhance the trusted devices configuration.

One improvement for the Vault timeout organization policy that might help to improve the experience for our employees as well as other organizations using trusted devices would be if the client could override the policy (or even the client settings) to log out instead of locking in the scenario where the user does not have a master password AND neither a pin or biometric unlock option has been configured in the client. Thought here is that the locked state isn’t really a valid state for such a user as they would have no means to perform the unlock operation without a master password and have to logout and back in anyway. If the client behaved like this, that would allow us to still enforce a vault timeout policy that locks the vault without worrying about the confusion it causes users who haven’t configured biometric unlock yet.

Would it be best to start a new post requesting such a feature in the Feature Request category?