Following up here again. Really hoping to take our MSP to Bitwarden and bring our clients along but a masterpasswordless SSO option is a must-have.
Has there been any movement on this? It appears the last post is over a year old. We are new to Bitwarden and would like to implement SSO, but it seems unnecessary to do so if you are still required to enter the Master Password too.
Hi @brianknight Yes! You can check out SSO with Trusted Devices About Trusted Devices | Bitwarden Help Center
Has there been any update on this? The last post is from 7 months ago.
1Password is now able to do this by only requiring your Azure Entra ID credentials to unlock your vaults on their cloud hosted version (not sure if they have a self hosted version).
Trusted Devices are not really the benefit I was looking for. Removing the second step (Masterpassword or Device Approval) would be preferred, not replacing it.
The more so as a Browser Update seems to trigger the need for re-approving all browsers of the company! So we just approve everything we get⦠but the user needs to wait and we have a lot of support effort ā¦
This is still a feature that organizations want desperately. Weāve just signed on for Bitwarden Enterprise and the SSO process requiring an additional MP entry after the fact will add major annoyance to our users. Hopefully, this feature can see some prioritization for Cloud-hosted Enterprise Customers in 2025 ![]()
What makes things (kind of) even worse is that they now have trusted device for SSO but it is only for logging in and not for unlocking which is an epic failure.
I was really hoping for trusted device unlock. I donāt see why it isnāt possible if it can be done when logging in since when you login you are also unlocking.
I am really wanting unlocking (decryption) with our own identity provider. 1Password currently supports this via trusted device.
It would be nice if bitwarden implemented this too. By not having this for organizations/enterprises, itās like bitwarden is playing in the minors leagues while 1Password is playing in the major leagues.
As of now, the only somewhat seamless configuration is to have our users setup a PIN after unlocking their vaults.
Users can trust a device, after which future logins will unlock with only the SSO flow. It is only the first time logging in on a new device that a user needs to use their other device or get admin assistance to unlock.
Iād appreciate if it would be like that already. But please Bitwarden. Start listening!
Itās not even āTrusted Deviceā, itās āTrusted App on Deviceā. Browser, Browser Plugin, Windows App, Mobile App ⦠they all need an extra approval! Approving a new Windows Laptop once, that would be better already. But three times for Windows only? Users are confused, technicians annoyed, IT simply approves everything without looking, bc you canāt verify if Mr. Bean or Mr. Hacker wantās to register this new Device.
Thatās random! Additionally clearing the Browser cache/cookies for some IT-Support Troubleshooting ends in a user being locked out of Bitwarden! Thatās ridiculous.
And you got solutions at hand ⦠please listen!
Iāll give this a try again but when I tested on Monday it was wanting me to enter my master password to unlock the web browser extension.
Iām pretty sure the Trusted Device in the web browser extension is based off of the hardware ID of the browser and the browser is not capable of grabbing the actual hardware ID of the computer. This is a limitation of the browser and not Bitwarden.
This is why if you ever take a survey and the survey only allows 1 submission but if you go in to In-Cognito/Private Browsing mode, you can submit the survey as many times as you want.
Again, this is a limitation of the browser and not the actual computer or Bitwarden.
I guess something to bear in mind is that the app has a session timeout, that the user can configure, that will determine when the app locks or logs the user out.
For a user who has a master password, the default values for those timeouts are to lock the vault after 15 minutes. Again, you can adjust this. You can set up unlock with PIN or biometrics to give yourself other unlock options, or extend or shorten the time as you like.
For users who donāt have a master password, the default values are to log the user out after 15 minutes. On a trusted device, they can log in again going through the SSO flow and unlock is automatic after SSO. Or, these users can set up PIN or biometrics, so that they donāt have to go through SSO to unlock.
But our devices are known by Intune and fulfill compliance policies to be allowed to access Bitwarden. Devices not known by our AntiVirus, IdP and MDM Management canāt access Bitwarden anyway even if the Device is ātrustedā by Bitwarden mechanism.
So we are being limited by Bitwarden because they are bound to the limitations of the browser but donāt allow us to empower us ourselves.
On the same boat too here. Adding some noise ![]()
Havenāt got staff that are willing to accommodate SSO + Additional Master Password authentication on the Cloud Enterprise of BitWarden. Seen the above regarding the trusted devices, which I will check more into, but as others have mentioned itās not ideal as the SSO would be good enough through our IdP with itās own conditional access. Itās frustrating as limiting users reliance on passwords is the goal and having an option for SSO only required logins is the way.
To further add to this conversation now that I have a bit more experience with it both as a User and an Administrator. Once I understood that only Admins are required to have a Master Password in Single Sign-On enabled scenarioās⦠I have found that the two-step verification process (for users) is actually a fairly seamless experience.
After a user has setup a 2FA app two-step method in their account, installed the browser extension and desktop app, configured Biometric and PIN unlock, Windows Hello for Business, etc. It all makes a bit more sense and is a smoother sign-in experience. (Yes I know, shocking revelation.)
For users joining the organisation in a SSO scenario, they donāt need a Master Password so are not prompted to create one, and just have to use a two-step verification method initially and member/device approvals for the user are required by an Administrator.
For anyone who stumbles across this, thinking the user sign-in experience is really convoluted and what not. Yes, it is a bit at first, but if you setup the additional stuff mentioned above and understand that users donāt need master passwords when using SSO, everything is a bit clearer ![]()
Admittedly, it is a slight annoyance when users continuously attempt to sign-in with a Master Password, not realizing they need to use the grayed-out Single Sign-On login method in the login form, and you have to remind them dailyā¦
(Hopefully, maybe, Bitwarden can improve this in future.)
Last week I was testing this as well as converting my SSO from going directly to my Keycloak server to Azure so I could use a CA policy for Duo.
I can confirm also, the experience between a Bitwarden administrator and Bitwarden end user are two different experiences.
Bitwarden Administrators have to use a master password so they donāt get locked out of their cloud instance which makes sense.
Iām using SSO and trusted device and the user experience is somewhat seamless.
However, I did run in to 3 problems.
-
I wasnāt receiving the emails once the end user accepted the invite but other admins did. I check my spam folder and Outlooks rules and even the exchange server but never received it.
-
When clicking the enterprise login button, the text box for the master password would error out in red text saying you need to enter a password but then would proceed to the enterprise SSO login.
-
When new user devices needed to be approved, we were not reviewing emails to let us know it needed approval.
On your point 3. I confirmed with Bitwarden support that this is a missing feature.
Youāre correctācurrently, Bitwarden does not send out email notifications for device approval requests. The only way an Admin or Owner would be notified is if the user informs them about the request, or if they happen to check the Admin Console.
However, I want to reassure you that this is on our development roadmap, and weāre working on adding email notifications for device approval requests in a future update.
So they are aware and it should be implemented soon ![]()