I fully appreciate the security motivations behind Bitwarden’s decision to require a password or PIN on app start — but eliminating the option to use biometric unlock on restart without warning feels heavy-handed.
Many users, including myself, rely on Windows Hello for rapid, secure access. This change not only disrupts our workflows but also erodes trust in the reliability of Bitwarden as a premium, user-centered product.
A better approach would have been to disable biometric unlock by default for security, but still offer it as an opt-in option — with a prominent “Use at Your Own Risk” disclaimer. That respects both security needs and user choice.
As a paying customer, I find this inconsistency a dealbreaker — especially when it impacts daily usability so significantly. If we’re not trusted to control our own risk profiles, it may be time to consider alternatives.
This is even more complicated. You have to logout very time. Then you have to enter your mail address again, open the Bitwarden App on the smartphone and in my case enter the two factor authorization. Bitwarden should really reconsider the login process.
Hi @Gemini_6-7, the comment of mine that you quoted was a response to the preceding comment by @KenMuir, not a general suggestion addressed to you or to the other thread participants.
I was simply stating that for a master password, a four-word passphrase is superior to a 16-character password string like 6~"1rudO\fmC\;)s, as a response to the complaints by @KenMuir that their master password was “complex…to remember”, and that entering the password required them to “laboriously type”. A passphrase is superior in both of these regards.
I think you do not get the point. I could open the Bitwarden Windows software by using a fingerprint sensor before, a simple touch. Now I have either to enter a PIN (more typing) or enter a master password, which should be not easy to hack and the longer the better (even more typing). And this every time I start up my PC and want to use the Bitwarden Windows software. This is not efficient, time consuming and not elegant to what was existing before.
The problem for some of us is that it wasn’t this way before. And how it was before worked for us how we wanted it to work.
The whole reason people use password vaults is because some of us are not great at remembering or typing long/secure passwords. That doesn’t mean we disagree with security, it means we need help with it.
And a system that is meant to help with the issue but forces us to run into it is rather counter-intuitive.
If we wanted to be constantly typing in passwords, we wouldn’t be using Windows Hello.
I know there’s the “Use A Bitwarden PIN” option but that would require me remembering yet another PIN. And guess where I’d need to store it…?
Also, is there a reason it can’t login using a PassKey or via other-device authentication?
Passkey login is still unavailable on the desktop. “Login with Device” will be available if you log out from the lock screen first, enter your email, click continue, and on the next page, you will be presented with “Login with Device.”
OK, just tried it. Had to log all the way out and go through full login process again.
Not much, if any, of a time save than entering the master password. And nowhere near as convenient as the version that used to work just fine.
I hope this gets sorted soon. I don’t want to have to start the hunt for a new password manager as Bitwarden does pretty much everything else I need out of a password manager.
But the other stuff is nice-to-have. Hello-unlock on startup, for me, is a must-have.
(Side-note: If you have to put a topic on slow-mode, it’s a sure sign something’s wrong and needs fixing.)
Here is another workaround, which is usually not recommended because of security/no-update problems. Download the 2025.7.2 version and install it, set the user environment variable ELECTRON_NO_UPDATER=1, and stick with that until “it’s no longer safe” or things have changed for the better.
Hey all, I wanted to jump in and provide an update on where Bitwarden is with this issue, as well as address some common themes in the comments.
First, an update. As @grb noted, we are researching ways to restore the previously supported behavior without downgrading the security of our implementation. We will let you know if this research leads to changes, but so far we’ve seen some encouraging results.
Second, a clarification as to why this change was introduced. The previous solution provided good security, and optionally let users who wanted more security turn off the ability to use biometrics after relaunching the app. However, the previous solution was also buggy, because the Windows API used sometimes led to the Windows Hello prompt not being focused when triggered from the browser extension, leading to a bad user experience. To fix this, Bitwarden switched to a different, less secure Windows API. To maintain user security we could no longer offer the ability to unlock with Windows Hello after app start.
Third, then, to users questions around “why not give us an option to choose our own security stance?" Bitwarden generally supports this! In this case, the API we were using and the way that Windows sandboxes apps meant that such an option would give any process running on your machine access to your encrypted vault data even when your vault was locked or the Bitwarden app was not running. You might as well use the “never” lock option.
I hope this helps clear some things up. As ever, thank you for the feedback and engagement!
To me that sounds like a situation we do not want. If a vault is locked, I expect it to be safely encrypted in memory. Because of this, I now use Bitwarden PIN. Could you clarify this?
Until you get a response from a more authoritative source, my understanding is as follows:
Whenever a Bitwarden client app is locked, its decrypted vault data is purged from process memory, but an encrypted vault cache exists in persistent storage (e.g., on your hard drive), where it could be copied by an attacker who has access to your device. However, since 2025.8.0, if a vault is biometrically locked, the encryption key (which can be used to decrypt the encrypted vault cache) is available in an unprotected, non-scrambled form in the process memory, which could be dumped and exfiltrated by an attacker who has access to your device. The main challenge for the attacker (as I understand it) is that they would have to sift through the memory dump to determine which 16-byte sequence actually contains the vault encryption key. But assuming that the relevant bytes are stored sequentially, they could just brute-force their way through the data dump until they find the correct sequence.
To make my statements you link more concise and hopefully provide a direct answer:
As of 2025.8.0, the vault is encrypted, the key needed to decrypt the vault when unlocking via Windows Hello is protected by a secret held in memory of bitwarden-desktop after the first time you unlock, and a secret held in the Windows keychain. On most Windows installations, it is possible for any program (aside from Windows Store apps) running under the user to access the memory of any other application running under the same user [1]. It is also possible for any program running under the user to read all keychain items without any further authentication step.
Therefore, currently Windows-Hello unlock is not sufficient to protect against attackers that are able to perform the previously mentioned steps, provided the attacker gains access to your unlocked device, after-first-unlock of Bitwarden.
The main challenge for the attacker (as I understand it) is that they would have to sift through the memory dump to determine which 16-byte sequence actually contains the vault encryption key. But assuming that the relevant bytes are stored sequentially, they could just brute-force their way through the data dump until they find the correct sequence.
@grb I would argue that the main challenge is getting code running onto an unlocked device after first unlock in the first place. If you can do that, you can also already steal all session cookies from the browser, so the hurdle is relatively high. But yes, provided an attacker can do that, getting the key from the memory dump in 2025.8.0 is not a significant challenge, with the steps you describe here.
[1] Note: Many corporate Windows installations are configured to not allow debugging / memory dumping by default, in which case this does not apply
What type of challenges would the attacker face? If they find an unlocked and unattended device, wouldn’t it be straightforward to use a USB key containing some utilities like HxD and LaZagne to extract the data? And isn’t some subset of users vulnerable to installation of malware that could achieve the same results remotely?
And just for my understanding, where is this protected key held?
Wow - you turn your head for a few days and everything has changed!
My 16-character Master Password (like the example you provided) is difficult to use for two reasons -
I know what it is, but I can’t ‘spell’ it without concentrating. It’s like I’m 9-years old and back in school trying to spell ‘irreplaceable’ or similar. I still find that the password doesn’t burst into my memory thanks to a mnemonic - which is a good thing from a security point-of-view.
Thanks to BitWarden I rarely had to use my Master Password. The biometric access to the desktop app and to the browser extension covered 90+% of my requirements. So my fingers have never learned a fluent muscle memory for typing it, like other English language words and phrases.
That aspect - the ease of use - is my only issue. Having calculated permutations, substitutions, entropy etc I’m happy with the level of security it provides.
I’m not sure I completely buy in to the four-word passphrase being a superior method of securing my Bitwarden vault. I’ve tried reading various explanations of this. The classic xkcd example of “Tr0ub4dor&3” as weak, and “correct horse battery staple” as strong is compromised from the outset. That 4-word phrase may be a better example than that password, but my password is already very much more secure than all.
Like a couple of others here, I’m disappointed that I didn’t realise the consequences of Bitwarden’s recent change with regard to biometric login. Biometrics just suited my workflow so well that any change away from that was bound to be seen as retrograde, at least initially. Bitwarden has still got a lot of excellent features, so I’m not quite jumping ship yet. Let’s see if I can learn to spell first!
