Logging in with SSO seems to be one of the exceptions:
(source: New Device Login Protection | Bitwarden)
PS: Ah, I forgot: Welcome to the forum, @edwasa !
Got it. Thanks!
⌠as I think that site (New Device Login Protection | Bitwarden) was updated, I only now saw, that passkey-login is also one of the exceptions (we speculated recently about that here in the forum):
So, having some âlogin-with-passkeyâ-passkeys would also be a possible âbackup-loginâ method, especially for all who fear to lose access due to the new device verification, right @Micah_Edelblut ?
Though âlogin-with-passkeyâ is still in beta and only works with the web vault⌠But if that âpolicyâ would stay - being able to login-with-passkey to the other Bitwarden apps, would become even more interesting now, as it would avoid âevery problemâ with the new device verification (possibly). 
Yeah, the passkey that decrypts the vault is really seamless on desktop web app. Not bad on mobile device either (website isnât responsive) but I found it did ask for master password, but does successfully skip 2FA (chromium browsers only currently I believe).
Think of the factors as more definitional. My go-to authoritative reference is NIST 800-63B-4, draft 2. It definitionally states:
- §3.1.1: A password is âsomething you knowâ
- §3.1.4: A single-factor OTP authenticator is something you have.
Even when written down a password remains âsomething you knowâ. Similarly, when protected with a password or when the secret key is memorized, TOTP remains âsomething you haveâ.
Iâm pretty sure thatâs been in the help document since the start, but yes. For those of you noticing it, setting up a login passkey is a way to access Bitwarden from an unrecognized device without going through new device verification. Today, this is only available on the web app, but Bitwarden plans to expand to other apps soon.
The attacker would also need to know what authenticator app your friend uses. Some attack vectors that reveal the master password might grant them this knowledge, but others, like phishing, wouldnât. Itâs not perfect, as others have pointed out, but I would also say itâs approximating 2FA fairly well while optimizing for recoverability with a single remembered secret.
I have found that the perfect âPassword protected JSONâ created by a Bitwarden Export is to import the JSON file to a KeePass vault, where it is secure, and directly usable as a password manager. The KeePass executable can be run from a Thumb drive or a folder on your computer â it doesnât need to be âinstalledâ in Windows or Linux for example.
Some of the Android forks of KeePass wonât import JSON, but the original KeePass has supported this for years.
Agreed, KeepassXC portable is great. I donât use it as a password manager, but I do keep a my current export in it so I can spot-check entries as much as I want to build confidence my backup is good. Plus, If Bitwarden were to somehow explode, I have instant access to an (outdated) vault while I recover.
Thatâs masterâs level paranoia, though. This thread is mostly dealing with those who have not learned disaster-prep in the school of hard knocks.
No offence, but I think you confuse the original KeePass with the âforkâ KeePassXC. As far as I see, the original KeePass doesnât even allow any JSON import, but KeePassXC does.
This is a classic case of enshittification. Forcing âsecurityâ on users that will cause users to lose access to all of their online accounts. When a company employee (Micah) tells you âThen youâve shot yourself in the foot.â, blaming you for losing access to your account when in fact THEY caused you to lose access to your account, you should listen. Bitwarden is telling you that they are willing to accept the backlash and loss in revenue due to screwing over their users for whatever corporate agenda theyâre seeking.
Making a change and seeing the backlash itâs caused and only then saying it will be optional, but still not being clear on what âoptionalâ means is clear evidence of very poor management.
So are you going to force users to use 2 factor auth, but after that release youâre going to make it optional? So are you generously giving people the opportunity to be locked out forever before giving them the chance to opt out? You also said itâs optional, but are not clear what that means. Do you mean nothing has to change or they will still need to have some form of 2 factor auth?
Nothing short of a public apology will keep me from canceling my subscription, especially considering the blatant disregard for userâs livelihoods.
Iâm thinking that Iâll maintain a small KeePass file with recovery keys, TOTP seeds or Passkeys as needed. That file can be kept on a cloud (Google, OneDrive, iCLOUD etc) or on a USB Thumb drive with the KeePass executable(s) for Windoze, Android, Linux etc.
I already import my BW exported .JSON backups into a KeePass file as it is a great way to securely store a .JSON exported backup ⌠put it into KeePass where you can even use it as a complete PW manager until you restore your BW vault.
But like any other solutions here, it requires the user to memorize yet another master password.
Earlier messages indicated that they will not release Device Verification until they actually implement the feature to allow one to go to their account settings to opt out of Device Verification without needing 2FA set up. So it sounds like those who want to turn off Device Verification w/o actual 2FA enabled will encounter Device Verification on login at least one time before they can turn it off completely.
Checked that reference, and I see the following:
The multi-factor OTP authenticator is âsomething you haveâ activated by either âsomething you knowâ or âsomething you are.â
Welp, okay. I guess we can roll with that, haha.
Can I list more than one email address for MFA? We use this for work, home, and mobile devices and have different phone numbers and email addresses. How will this work in practice, given the situation many of us face?
@Micah_Edelblut I do have an account set up with passkey login but without 2FA, and when logging in to this account (using my passkey), I am still being shown the device verification notice that asks about my email access.
The logic for the notice is not the same as the logic for the feature. We show the notice to any user who might need to fetch a code from their email in the future. The logic for the feature itself is documented in the FAQ article linked above.
This is a great security update! Adding verification for new devices strengthens account protection, especially for users without 2FA. Itâs a smart move to prevent unauthorized access.
If I have enabled 2FA and I use my Bitwarden Two-step login recovery code, will I be sent a verification email?
Imagine Iâve nuked my phone so I do not have a working Authenticator app or email.
No, if you have enabled 2FA for your account, you are âexcludedâ from the new device verification:
(â> https://bitwarden.com/help/new-device-verification/#who-is-excluded-from-this-account-email-based-new-device-verification)
Though, if you use the 2FA-recovery code, then you deactivate 2FA for your account. And then, the new device verification could get activated for you - unless you set up 2FA again, directly. 
You can somewhat prevent the loss of the authenticator app, when you store the TOTP seed code e.g. on your emergency sheet. With that seed code (or secret key), you can set up your TOTP with any authenticator app again, at any time.
(and you still should have your 2FA recovery code on your emergency sheetâŚ)
As long as you donât deactivate 2FA - and donât activate it again directly - then losing âemail accessâ shouldnât be relevant, as the device verification is not active for you. (though it may be not a bad idea, to store the login credentials to your email address also on the emergency sheetâŚ)