(The listed release number is for the Bitwarden Server, other version numbers released in this cycle also include Web 2025.11.2, iOS 2025.11.0, and Android 2025.11.1)
Password Manager
Log in with passkeys: Now generally available in the browser extension and web app, log in to your Bitwarden account faster and more securely using passkeys.
Policy name update: The Automatically log in users for allowed applications policy has been renamed to Automatic login with SSO.
Self-host
Bitwarden Lite general availability: Bitwarden Lite, formerly Bitwarden Unified, is now generally available.
Environment variable update: The self-host environment variable globalSettings__syslog__destination has been deprecated. Learn more about Self-hosted environment variables.
Security
No logout on KDF change: Changing KDF algorithm will no longer log you out of client applications.
Is it possible to limit this to unlocking or at least require one previous login with master password and 2FA? Otherwise, in case someone obtains my hardware key, all that stands between the attacker and my vault is a (short) PIN.
I canât answer that (no insight into BWâs developmental processes).
Sounds like a feature request.
Well, given your PIN is random â and not absolutely too short â the risk might be smaller than you think. Also, because e.g. with YubiKeys, after 8 failed attempts, the FIDO2 function of the key gets blocked entirely. (I canât say, if every hardware security does it exactly the same as Yubico)
If you still donât feel your PIN would be strong enough â then make it stronger:
Personally, I would oppose this (unless optional), as it would stand in the way of using Private/Incognito mode browsing, and complicate the commissioning of new devices.
The PIN can have up to 63 characters (including non-numeric characters), and should be set to have an entropy commensurate with your threat model.
Remember also to take into account that you are much more likely to quickly become aware of the physical loss of a hardware key (compared to a remote theft of digital secrets), so you will have a fighting chance to disable passkey login on your account before the PIN is cracked.
I know, my hope was that someone (not especially you) would know about an existing feature request or GitHub issue.
To be totally honest: My PIN is 4 digits. Thatâs because I use my hardware key only as a second factor, so a very short PIN is fine in that case (at least for me). That changes of course once I use it to unlock my vault without the master password.
Hm, never thought about that. Is that really a common use-case?
Is that true for all FIDO keys, like part of the spec?
However, the proposed standard allows for an optional maxPINLength parameter, which may further restrict the maximum PIN length to be 8 Unicode code points (represented by 8â32 octets), at a minimum. If the maxPINLength parameter has not been set, then the default value of maxPINLength is 63 code points.
So I think that (once the standard is adopted), we can be guaranteed the ability to use PINs consisting of at least 32 ASCII characters.
To make âdisable passkey loginâ a bit more clear â it wouldnât be necessary to disable all login-passkeys then, but only the one that was lost / stolen / became inaccessible - as login-passkeys luckily can be removed individually in the web vault (Settings â Security â Master password â Log in with passkey).
@marlin What is your use-case? Why do you use passkey login at all? A better solution for you might be to wait for the implementation of passkey unlock, and to disable passkey login altogether.
Hmmm⌠the âpasskey unlockâ PRs on GitHub have the titles âPRF unlockâ. Probably we have to wait if there will be new and separate âunlock passkeysâ we can set up â but for now, my assumption was, that we probably will be able to use the existing âlogin-passkeysâ (and then only those with encryption â when itâs âPRF unlockâ) for passkey unlock⌠and then, it wouldnât be possible to delete the login-passkeysâŚ
I would like a convenient but secure option to unlock the browser extension.
Right now I use the desktop application with a fingerprint sensor that I bought just for this use-case. Unfortunately I am not allowed to install the Bitwarden desktop app on my work laptop, so I am limited to âunlock with PINâ there.
As I donât use the yubico otp feature I programmed slot 1 to emit a static password (randomly generated with ykman otp static -g 1 -l 38 -k MODHEX) that has 190 bits of entropy.
I use that static password as the unlock PIN. And with its strength Itâs relatively safe to uncheck the require master password on device restart option.
The main risk with a static password emited by a security key is that itâs very easy to leak it by accidentaly typing it where you shouldnât. In that case I simply generate another one and change the unlock PIN to the new one.
Nowadays, that login with passkey is a thing in the browser extension, I donât need to uncheck the require master password on device restart option and I just set a weak pin that I type manually to unlock.
Riffing off this idea, what if @marlin gets two keys (e.g., a new Series 5 Yubikey in addition to their current SoloKey)? Then they could use the Yubikey static password to emit a high-entropy PIN for user verification on the SoloKey. As long as both keys donât get stolen at the same time, then the SoloKey could be safely be used for passkey login into Bitwarden.
