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.