Unable to unlock Bitwarden desktop app on app start using Windows Hello

[Quexten]

This is an intentional change, but not one for which the decision was easy. It was the only option that the constraints of Windows’ security model and APIs provided. @Neuron5569 provided good links already, especially to the GitHub PR. This is not a security change, but a bug-fix.

The short version is that Windows has two APIs for Windows Hello, the former just provides a “authorized, not authorized” response but works reliably. The latter provides a deterministic signature, from which a cryptographic key can be derived. This functionality broke on newer Windows versions leading to a very frustrating and inconsistent user experience Chrome extension biometric unlock not functioning correctly with Windows Hello · Issue #13291 · bitwarden/clients · GitHub , where the window would not consistently focus. Further, this lead to authorization requests frequently breaking entirely. This experience was not acceptable from most users, since Windows Hello, when used via the browser, would be consistently broken. All workarounds for this, such as attempting to focus the window via Windows APIs failed to deliver a reliable solution. The only option forward was to remove the usage of this API, leaving only the authorization-only API.

As of version 2025.8.0, to access and decrypt your vault data while the Desktop app is open but locked, an attacker would need to do two things: (1) Trick you into completing a Windows Hello authorization; and (2) Do a memory dump and find the clientKeyHalf. If the Desktop app is closed, then the attacker will be unable to decrypt your vault contents unless they can obtain or guess your master password (or PIN, if you have enabled PIN unlock).

This was the case prior to 2025.8.0, with the inconsistently working API. If you did not have “require master password on restart” checked, you would actually only require a Windows Hello authorization, no memory dump, and the app did not have to be running.

As of 2025.8.0, you require just a memory dump, and no authorization, when locking with Windows Hello on Windows. There are memory-protection APIs that are under investigation to prevent this: [BEEEP] Secure memory kv store by quexten · Pull Request #15191 · bitwarden/clients · GitHub . While the app is closed, there is no way to access your vault. But in 2025.8.0, the protection you get is adequate only against attackers without extensive technical know-how.

As for solutions to restore “allow master-password on restart”, the Windows security model does currently not seem to allow this. Approaches that have been tried so far in similar tools, such as Chromiums app-bound-encryption have historically failed to give adequate protection measures GitHub - xaitax/Chrome-App-Bound-Encryption-Decryption: Fully decrypt App-Bound Encrypted (ABE) cookies, passwords & payment methods from Chromium-based browsers (Chrome, Brave, Edge) - all in user mode, no admin rights required. . All known existing solutions can be bypassed with various levels of effort required, and would leave Windows Hello to provide a false sense of security, unless the risk is adequately communicated.

However, there are various ways the UX around this could be improved - like the initial unlock being performed in either the browser or desktop app, instead of the current cumbersome approach of having to use the desktop app first.

I dont like the idea of having to keep Bitwarden app running there all the time just incase I might want to sign into something. Id would rather just open it when needed and the shut it down when browsing in the net etc. something. Using Windows Hello PIN is perfect for this, because it offers quick way to open the whole app securely if needed and keeping it open only when needed.

I would recommend using “Unlock with PIN”. It offers far better security for your vault than Windows Hello PIN.

[mmja]

Wait, are you @Quexten saying, that the current implementation of the Windows Hello to (logged in, running, but session locked) Bitwarden app is “insecure version” of the Windows Hello API?!?

I thought that the bug only affected “logged in, not running, session being started” status of Bitwarden, ie. opening the non-running app via Windows Hello (after you have signed into it before)?

If so, then this is huge and absolutely the Windows Hello should not be used at all to even that purpose, since it offers no strong cryptographic protection for the Bitwarden vault.

[Neuron5569]

@Quexten

As of 2025.8.0, you require just a memory dump, and no authorization, when locking with Windows Hello on Windows.

For 2025.8.0, since the master password is always required on restart for Biometrics unlock, are you saying that even when the app is locked, the attacker can just memory-dump, without biometrics authentication, and get the decrypted vault? Or did I misunderstand the context?

[Quexten]

Security is often not as black and white as “insecure” or “secure”. Whether you should use Windows Hello in the current version - just like whether you should use it before the update - depends on your threat model. If an attacker with high forensic experience running code on your unlocked system after you lock your vault is within your threat model, then you should not use Windows Hello unlock. In many cases, this attacker model may be too strong, and the aforementioned scenario occurring may be not worth considering. (If your system is locked, they’d need to unlock it. If your system is shut down, the keys are gone and your vault is no longer accessible without the master-password).

Such an attacker with full access to your system could also already steal all session cookies from your browser, since the encryption measures browsers do take can be circumvented, as shown by the previously linked GitHub project on chrome’s ABE, without ever going to your vault.

So, whether or not the current Windows Hello implementation meets your needs, and whether you should use it is up to you.

(Note: The above does not affect MacOS touch-id or Linux system authentication unlock. Apple Keychain is separated per signed app context, and on Linux, the process holding the keys uses special kernel features that prevent debugger / memory access).

[Neuron5569]

I appreciate the explicit answer and your analysis. It’s unlikely I would have found this out otherwise. I will definitely be reconsidering how or if I should be using Windows Hello to unlock Bitwarden! Thanks.

[grb]

@Quexten Thanks for shedding light on these important changes — especially about the loss of the key half derived from the Windows Hello signature! It seems that biometrics now works in a similar way to the pre-2023.4.0 versions, when it served only as access control.

@Quexten

The above does not affect MacOS touch-id or Linux system authentication unlock

If that is the case, I am curious why biometric unlock on app-start is only possible on macOS, but not on Linux systems.

@Quexten

If an attacker with high forensic experience running code on your unlocked system after you lock your vault is within your threat model, then you should not use Windows Hello unlock.

Is my understanding correct, that the “forensic experience” required refers to the attacker’s ability to actually identify the needed keys within the memory dump (along with being able to implement the decryption algorithm based on publicly available methods)? Would any other knowledge be required?

And it’s unclear to me what keys are now held in process memory when using biometric unlock (although I understand if this is information that you prefer not to disclose) — is clientKeyHalf still there, based on the password/PIN entry on app-start? Do I understand correctly that this is is now the only key (so no longer a key-half) protecting the user key? So the memory dump of a biometrics-locked app would yield the protected user key as well as the key to decrypt the protected key?

Finally, it seems that an attack without running code on the targeted system is also possible — if the computer is left unlocked and unattended (with vault locked using biometrics), then a bad actor could exfiltrate a memory dump (along with a copy of the local vault cache) and carry out their forensic analysis elsewhere.

[Neuron5569]

@grb

It seems that biometrics now works in a similar way to the pre-2023.4.0 versions

except that the previous versions probably also stored keys in the credential manager.

@grb

(along with a copy of the local vault cache)

There are presumably still the accessToken and refreshToken in the credential manager, along with encryption keys held in the process credential manager(?) that can be dumped (presumably not from the credential manager’s but Bitwarden’s process).

Edited: crossed-out based on the answer provided below.

[Preet]

@Quexten

I would recommend using “Unlock with PIN”. It offers far better security for your vault than Windows Hello PIN.

I am still wondering how BW PIN offers better security than Windows Hello PIN since Ai suggests that due to TPM its much better to use Windows Hello PIN vs BW PIN

[grb]

@Preet

since Ai suggests

Never entrust your vault security decisions to an “AI” generative LLM. The generated text in your screenshot is full of errors (which is no surprise, since the “AI” actually understands none of the text that it is spitting out).

The correct explanation is in the comment posted by @Quexten above. @Quexten is a Bitwarden developer, and probably the most knowledgeable person on this forum when it comes to matters concerning Bitwarden vault security. If you’re going to trust somebody based on authority (perhaps because you may not have the background expertise to conduct your own critical reading of the source material), then you should trust @Quexten’s recommendations over some random word salad generated by a half-baked “AI” model.

The long and the short of it is that if you use a Windows Hello PIN, then the encryption keys that allow your vault data to be decrypted are available without protection in the device memory (and can be stolen by somebody who has access to your device). In contrast, if you use a Bitwarden PIN, then the same encryption keys are not present in memory in a usable form — the memory only contains a protected version of the key, which means that the key itself has been encrypted using a second key; the second key is a 256-bit number which cannot be guessed, and which can be re-created only with knowledge of your PIN. Thus, an attacker would have to steal or correctly guess your unlock PIN before they can access any of your vault secrets — if you have locked your vault using a Bitwarden PIN.

[Quexten]

If that is the case, I am curious why biometric unlock on app-start is only possible on macOS, but not on Linux systems.

MacOS has a persistent key-chain that isolates per-app, which survives reboots. The key to unlock the vault can just be persisted here and only the correctly signed desktop app can access it.

Linux does not have this, as the keychain equivalent, libsecret fails to isolate between apps. Instead on first unlock a key is set to memory, that does not get wiped when the vault locks. The per-app isolation in Bitwarden-desktop on Linux stems from using PR_SET_DUMPABLE(2const) - Linux manual page , which prevents userspace processes from accessing the memory. Any known solution for persistent storage would have the same issues as on Windows.

Is my understanding correct, that the “forensic experience” required refers to the attacker’s ability to actually identify the needed keys within the memory dump (along with being able to implement the decryption algorithm based on publicly available methods)? Would any other knowledge be required?

That understanding is mostly correct. I left out the Windows credential manager in my summary, which is still used. But Windows credential manager offers no additional security for the case of defending against software running in userspace. So there is no meaningful security added by it added for the specific case of defending against userspace software / compromised userspace.

I am still wondering how BW PIN offers better security than Windows Hello PIN since Ai suggests that due to TPM its much better to use Windows Hello PIN vs BW PIN

The LLM summary is misleading and leaves out a lot of technical details here, and a judgement as to whether one solution is better depends on your specific threat model.

[Nail1684]

@Quexten

I would recommend using “Unlock with PIN”. It offers far better security for your vault than Windows Hello PIN.

… it probably would fill a gap – and would be a nice timing – if we had FIDO2 unlock (and FIDO2 login) options available…

[Basje (Bas)]

I have been reading up and am really confused after reading Unable to unlock Bitwarden desktop app on app start using Windows Hello - #21 by Quexten .

My main concern, and hopefully most of the users share this, is whether or not it is safe to use Windows Hello for unlocking your vault.

• I have “Unlock with Windows Hello” enabled in the app and the browser.
• I usually have the BW app running on Windows start-up in the background.
• If I open it, it will say: “Your vault is locked” and I can unlock it via the master password.
• The first time I the vault, I:
  • Unlock the app with my master password,
  • Open the browser extensions which then allows me to use “Windows Hello” to unlock it in the browser.
  • I can then access my vault.
• Browser and App lock after 1 minute and the app remains running in the background.
• The next time I need a password, I unlock it via Windows Hello from the browser.

So is this a safe way of using Bitwarden?

[grb]

@Basje Welcome to the forum!

@Basje

So is this a safe way of using Bitwarden?

It depends on your security posture, your threat model, and your appetite for risk. As explained above, an attacker with temporary access to your unlocked device can in theory extract the vault encryption keys either from process memory or from the TPM (doing so may not be a trivial undertaking, but it is possible). They can also copy the local encrypted vault cache, or use session tokens stolen from the TPM to obtain an encrypted vault copy from the cloud servers. With these data, they can decrypt your vault contents without resorting to brute-force guessing.

Personally, I would not feel comfortable taking this risk, but if you have excellent operational security for your devices (e.g., always lock the device when unattended, and never allow others to access the device), as well as strong malware defenses, then perhaps the reduction in security is acceptable.

I would say that the risk is not dissimilar from what would happen if you set your Vault Timeout to “Never”, but always manually lock your Bitwarden apps and browser extensions when they are not actively being used.

[Neuron5569]

It’s hard to compare the risks involved if we have to say things ambiguously to cover what Quexten has said, so I propose a model that most likely isn’t what was implemented but may be used as a conceptual model.

When locked, the encrypted vault in memory is encrypted by the account encryption key. The account encryption key is encrypted using a “randomly generated” key that is kept in the credential manager. To access the account encryption key in memory, you would have to forensically examine the memory (the Bitwarden app does use “Address Space Load Randomization”) to figure out which number to decrypt with the credential manager key; the attacker would need to access BOTH the credential manager as well as the process memory containing the encrypted account encryption key.

If so, then having just the encrypted vault or the vault downloaded by refreshToken/accessToken and the credential manager key aren’t enough; you have to examine the running process memory as well.

On the other hand, if the account encryption key is kept unencrypted in the credential manager, you just need the account encryption key and the encrypted vault on disk or the encrypted vault downloaded with refreshToken/accessToken. No examination of the Bitwarden process memory is required.

Obviously, the first scenario is preferable. How does this compare to PIN unlock? Presumably, for PIN unlock, if you require a password on restart, all the encryption keys are kept in memory. When locked, you have to forensically examine the memory and crack the PIN to access the account encryption key. If you don’t require the password on restart, then the account encryption key (or combined encrypted materials) is encrypted using the PIN, which is then kept on disk/in the .json file. You crack the PIN, and you can eventually access the account encryption key.

Compared to the new biometrics unlock, PIN unlock requiring a password on restart is better because the PIN has to be cracked. Compared to PIN unlock not requiring a password on restart, when the app isn’t running, biometrics unlock is better because no key (encrypted or unencrypted) is persistently kept. When the app is running, biometrics unlock may be better from the standpoint of having to access the credential manager instead of the more common file access and requiring a memory dump, while PIN is better from the standpoint of needing to crack it.

So, maybe in term of “safety”, the unlocking methods’ “safety” would be ordered:

• Password > PIN requiring password on restart > Biometrics ≥ PIN not requiring password on restart.

[Basje (Bas)]

Thanks for the responses. But given the current implementation and “password on restart” enabled, is unlock with PIN safer than unlock with biometrics? Is the vault encrypted when locked with PIN -and/or biometric-unlock?

[Neuron5569]

This is the answer from the developer above:

I would recommend using “Unlock with PIN”. It offers far better security for your vault than Windows Hello PIN.

Since Windows Hello PIN is the backup to Windows Hello biometrics, the answer is still that Bitwarden PIN is safer than Windows Hello.

The vault is encrypted when the app is locked. The discussions pretty much evolved around how the encryption key (to decrypt) the vault is protected, and with the current implementation, Bitwarden PIN offers a “better” protection.

[m.snapka (Marek Snapka)]

While understanding the technical reasons, I would really appreciate that next time Bitwarden decides to remove features, to properly communicate such undertaking in time so that helpdesks have time to communicate it to their users, change policies, test it all, change documentation and prepare people. How this has change was done was a fricking cowboy style.

While technical security is important, I have 100 users in 20 countries relying on login with Windows Hello on ISO 27001 compliant laptops with enforced memory encryption, pentested every year.

After the change, 10 users had to get their vaults deleted because they forgot their master passwords which under normal circumstances can safely be stored into Bitwarden with biometric access on both phone and the PC. However, if the phone logs out for some reason unknown to me (happened multiple times in the past without any such policy configured while I am 100% sure they left my table at onboarding with fully working Bitwarden app), and if the user does not remember his passwords, we have to delete the vaults in certain cases since recovery only started being available from certain time in the past and we can’t enroll everyone forcefully.

We are trying to do professional work here, however, with no warnings, we can’t do it and not only that IT looks like a bunch of idiots afterwards, but it also brings a lot of wasted time and money for all parties involved.

[dwbit]

Thanks for the feedback @m.snapka it has been passed along to the team.

In the meantime, if you enabled Account Recovery Administration after already onboarding some users, you can see in the admin console who has self enrolled and who hasn’t, and ask department managers to follow up with those individuals using the steps outlined here: Account Recovery | Bitwarden

[Neuron5569]

I would also like to offer a different perspective against one other password manager, KeePassXC. KeePassXC also sets the user up for Windows biometrics unlock by default when opening the database. So, after you enter the master password for the first time, the subsequent unlock can be done via Windows Hello, just like Bitwarden. Therefore, KeePassXC would have the same general problem as Bitwarden: how to protect the key to decrypt the database.

As far as I can tell, KeePassXC keeps this decryption key in memory, although it’s unclear if the key is additionally encrypted and this additional key kept in memory as well. They would face the same threats that would deter people from using Bitwarden’s Windows Hello now. The difference is that typical users might not be aware of this “problem,” as the user base isn’t as large and active, and it is a highly trusted FOSS. KeePassXC does have a solution allowing an appropriate hardware key (the more expensive sort) to be used along with Windows Hello authentication.

Based on one password manager comparison, it seems that Bitwarden probably went the extra mile trying to make biometrics safer. It comes at great costs too: lots of disruptions, complaints and headaches. If the prior (two-key-half) implementation had been reliable, it would have been safer for BW biometrics users in general, even without the more expensive hardware key (or a Mac!).

So, another comparison can be made: would you have used the convenient Windows Hello unlock feature in KeePassXC out of the box? Would you continue using it after learning that it may have the similar memory dumping/look-for-the-key-in-memory threat? But still, for Bitwarden, PIN is now a safer (but less convenient) method.

[grb]

@Basje

Is the vault encrypted when locked with PIN -and/or biometric-unlock?

When the vault is locked, the decrypted secrets are cleared from memory, and the only vault data on your device is the local vault cache, which is always encrypted. This is true no matter what method you use to lock the vault. The issue at hand is how difficult it is for an attacker to obtain the encryption keys required to decrypt the vault cache. For comparison, some people store an extra house key outside their house (incase they are locked out) — do they store it inside a lockbox (safer) or under a rock (unsafe)?

@Basje

is unlock with PIN safer than unlock with biometrics?

Unlock with PIN can be just as safe as unlock with master password. The only limitation is the entropy of your chosen PIN. The easier your PIN is to crack, the less safe it is, compared to locking with a master password. In my opinion, though, locking with PIN of any complexity is safer than using biometrics for unlocking.

@Neuron5569

Compared to PIN unlock not requiring a password on restart, when the app isn’t running, biometrics unlock is better because no key (encrypted or unencrypted) is persistently kept.

I see what you’re saying, but I don’t necessarily agree with your conclusion. Yes, persisting a protected key on the hard drive creates an attack surface that is still present when the app/browser is closed (and for unencrypted drives, even when the device is shut down). However, the persisted key is protected by encryption (using a key derived from the PIN), so the user can mitigate this risk. In contrast, with biometric unlock, there appears to be no meaningful protection of the encryption keys (other than “security by obscurity” as the attacker has to find the proverbial needle in the haystack), so the only way to mitigate risk is to shut down the apps and browsers when not using the vault — which would then defeat the point of biometric unlock (as a PIN or password would have to be entered each time the app or browser extension is restarted).