Options to disable or dismiss permanent "Change at-risk password" warnings

[grb]

As of version 2025.12.0, Premium subscribers have been saddled with a new feature that displays a permanent (non-dismissible) warning banner stating “  Change at-risk password”, when viewing items for which Bitwarden has determined that the password is “at-risk”.

Bitwarden needs to provide the users the option to dismiss these warnings on a per-item basis (so that the warning banner is never displayed again). I personally would also like an option to disable this new feature altogether (so that I am never confronted by the the warning banners).

There are many false-positive situations in which Bitwarden’s algorithm will deem a password to be “at-risk”, when there is in fact no security risk, and other situations in which the user has no power to make the password less “risky”. Thus, users will be always be presented with these warning banners, with no remedy available for removing the warning.

This is not only an annoyance (making the UI ugly, wasting valuable screen real-estate, pushing valuable information below the scroll), but it will make users less secure — by contributing to Banner Blindness, and thereby making it likely that a user will simply ignore (or literally fail to see) a warning banner that is warning of a true security incident (e.g., a recent data breach), due to the frequent exposure to irrelevant warnings.

Here is a list of scenarios in which the “at-risk password” warning does more harm than good:

• Passwords that are weak but cannot be made stronger (e.g., voicemail PINs, padlock combination codes, passwords for services that have overly restrictive password length rules)

• Logins that use AD/SSO/etc., for which Bitwarden users must create multiple login items sharing a single password, because different services require different usernames for the same password.

• Passwords for services that use high-cost KDF algorithms for hashing (e.g., Bitwarden itself), such that the entropy required to produce a secure password is lower than what the “at-risk password” algorithm (presumably zxcvbn) deems acceptable. For example, a random 8-character string (e.g., c8t.P>2[) has 52 bits of entropy, and is therefore practically uncrackable if used as a Bitwarden vault master password; nonetheless, Bitwarden’s “at-risk password” algorithm deems such a password to be weak.

For scenarios such as the ones listed above, it is essential to allow the user to dismiss the warning banner.

Beyond that, password strength testing is largely futile (e.g., easy-to-crack passphrases such as it was the best of times or the good the bad and the ugly are not detected as “at-risk”) , so I would want an option to disable the warning banners altogether, or at least to decide what criteria should be used for identifying a password as “at-risk”. Presumably, the current algorithm checks three things:

1. Does the zxcvbn tool deem the password to be “weak”?
2. Has the password been re-used within the user’s vault (or in an organization vault)?
3. Does the password appear in a breach known to HIBP?

It would be nice if the user had the ability to separately enable/disable each of these tests.

[Cris70 (Cris)]

Hi @grb and thank you for creating this FR.

I mostly agree, but I would like to add one thing that I think is fundamental: if the user is given the possibility to dismiss the “at-risk” banner, this should only apply as long as the reason for assigning the label is the same as the reason for which it was dismissed.
To be clearer: if I have a password that is deemed “at-risk” because it is re-used and I dismiss the banner, the banner should not return UNLESS BW deems it is at-risk for a different reason (e.g. a breach).

And, obviously, if the password is updated every user-initiated dismissal should be reset.

[Nail1684]

I would hope for any such additional options to be “synced” instead of “per client”…

[jschlie]

I really would have expected that something like this would have been thought through a little more before it was pushed out. It’s a great idea, but the implementation is lacking. There’s too little information presented, zero control on the user side and the the option to reset passwords often fails when redirecting you to sites such as Microsoft.

[kpiris (Kiko Piris)]

@jschlie

I really would have expected that something like this would have been thought through a little more before it was pushed out. It’s a great idea, but the implementation is lacking.

Exactly this is, sadly, the feeling I have with most of the new features added to Bitwarden since several months ago.

[Andr]

I completely agree that this “feature” should be both dismissible and optional.

It would be hilarious if the only way to eliminate this annoyance was to stop paying.

[PRNG12]

+1 on disabling per-site or per-login. I was worried my AD admin credential had somehow been breached, but it was just BW checking if I had the same credential between vault items. In this scenario for me it’s a few internal AD-authenticated sites that aren’t SAML-authed through our IDP, so BW helps there.

I’ll vote on this one when I’m able to. I reset my AD pass, updated my handful of BW vault items, and it still gave me the warning so now I’m quite sure it’s not a breached credential.

[DenBesten]

In a corporate AD environment, I have multiple computers that use the same federated login, but with different username formats (e.g. domain\username, username@domain.com, and even username). Most of the problem children want their specific format and are not willing to accept any of the others.

This use case would be best solved by implementing the FR below, but until then, I would like to disable the false-positive alert.

Field References (Ability to set different usernames for different websites using the same password)

Multiple entries can share a common field (username, password, …), and by changing the actual data entry, all other entries will also use the new value. https://keepass.info/help/base/fieldrefs.html

[InnovateWithEric]

Lots of great feedback on this thread. I hope by now that it is clear to Bitwarden that there are issues with the current implementation of this feature.

I believe these issues can be addressed to make this feature highly useful instead of highly annoying.

Treat the feature as risk management.

A) The warning must indicate each “why” for being unsafe so I can determine if I need to address it. There are several examples in the comments on this thread of scenarios where it needs to be what it is.

SOLUTION: Include some information (like a simple code or codes for multiple reasons) that can be used to determine why it’s flagged.

B) There needs to be a mechanism to “ACCEPT” the risk, so that the message can stop annoying me RIGHT NOW, and so that users don’t end up programmed to habitually ignore the warnings because most are not of concern to their scenarios. Some have raised legit concerns with this:

1. If I accept it & it’s completely hidden, in the future, new information could make the risk more relevant to the point I would want to know, or maybe my use case changes and I need to see them.
2. If I accept it with an understanding that it’s flagged for a specific reason(s) & new information becomes known that could impact the ACCEPT decision, there should be some indication so I know to consider the new information. Examples:
   1. another reason for flagging arises (perhaps it becomes available on dark web, or a new flagging rule is implemented)
   2. My context changes (perhaps an employee is fired, or a new internal directive requires reassessment) and I need to review them again

SOLUTION: Accepting the risk causes the warning to be suppressed by replacing it with some subtle indicator that there is accepted risk associated with the password. When new flags are detected for an accepted risk, there needs to be some indication that additional consideration may be needed. This could be subtle like a different indicator that means: “Previously Accepted, but there is new information), or it could be less subtle like showing the risk again (see below)

Note that it could become really annoying if, for example, a password is flagged for low password complexity, then reviewed and accepted, then the password complexity rule changes and now everything that was previously accepted appears again. I hope Bitwarden will think through the use cases & scenarios and streamline the work flows. For example, maybe use 1) a different state for flagged passwords which were previously accepted & now there are new reasons to flag it, & 2) a way to easily mass process re-flagged previously accepated passwords to bulk accept them.

In general, a mechanism for reviewing & updating risk decisions, including bulk update would help a lot.

[grb]

@InnovateWithEric Welcome to the forum!

@InnovateWithEric

A) The warning must indicate each “why” for being unsafe so I can determine if I need to address it.

FYI (for you and anybody else who agrees with you), there is now a separate feature request topic that proposes this:

"Change at-risk password" warnings should state reason why the password was flagged

First off, I like the thought behind the feature. Making me aware of the security reports, leaks, weakness, etc. in the UI directly without me having to navigate to the security reports themselves is very nice, imo. What bugs me is the ambiguity of the message. If there are specific reasons for flagging the password as “at-risk” then it would be much better if that reasons was named directly in the message banner.

[chips (Chris)]

+1 I have this AD scenario and also this similar scenario:

I have a login for the company I work for - let’s call them CompanyA. They use CompanyB to provide some employee services. CompanyA assigns a username to use with CompanyB - the usernames are not even remotely similar. We must also use the same password at both companies (CompanyB sync’s, federates behind the scenes from CompanyA, or something similar).

As a consequence, I have a vault entry for each company. My employer is very large (+1million). The chances of them changing how logins work just to satisfy an over-zealous password manager is vanishingly small.

Showing a vague warning with no information or ability to address it promotes alert fatigue, which presumably undermines the point of the feature.

[Ish (Ish Rashad)]

So here’s my problem with the message: It came up on two logins (my first two logins today).
So I dutifully (and with some anxiety) changed both passwords.
And it still comes up on the same sites.
I’m finding that I am starting to move password managers every couple of years because the developers and design teams seem to keep wanting to fix things that ain’t broke. A creeping disease, it appears.
But this one is kinda bad.
Someone should get the BW people to read the fable about The Boy Who Cried “Wolf !”
And fix this thing.

[silversword (John D)]

Was there discussion anywhere other than internally in Bitwardens non-public issue tracking system before this feature was force released to all users?

All these issues could and should have been discussed, and remedied before public release.

Where is the Bitwarden beta program for things like this?

Bitwarden’s extension install stats is 5 million+

Any extension with more than 1 million should have a thorough and extensive beta process with regression testing. Not buggy monthly releases.

LTS and Stable Release Channels for Bitwarden Client Apps

Can I request there be a LTS like chromium based Bitwarden extension that lags far enough behind that all the new (usually UI interface) bugs are minimized across the millions of install base. I’m an IT Consultant, that is trying to get my client base to use and be confident in Bitwarden. The constant UI changes, new bugs that your QA dept isn’t finding before releases that non technical users are constantly encountering is constantly giving Bitwarden a bad look. login counts on browser icon …

[OdyAsh (Ashraf Haress)]

I second this! That disable/enable functionality is much needed. Thank you!

[dwbit]

Hey there, is a deleted duplicate in the trash? Can you let me know if any of the items are currently coming up on any of the individual reports you can run in the web app, and if so, which one?

[kpGrelling (Kevin Grelling)]

I love Bitwarden - thank you for a wonderful open source solution!

As a paying customer, I am a MSP who uses BitWarden for literally 1000’s of passwords. Here is what I would like to see:

1. The ability to enable/disable this feature by source (duplicate, weak, breach) GLOBALLY
2. The ability to enable/disable this feature by source on an ENTIRE VAULT
3. The ability to enable/disable this feature by source on a PER-LOGIN-CARD basis.
4. Implied Priority (which one takes precedence if conflicting selections occur):
   1. Highest: LOGIN CARD
   2. VAULT
   3. Lowest: GLOBALLY

I also would like to see the source of the warning (duplicate, weak, breach) in any warning message presented anywhere.

---

Note: For my specific use case, I have 100s of logins that present the same piece of hardware from two or more different addresses (multi-homed network) that show up as duplicate passwords. All of my passwords are unique 16 character random strings without duplication. I know I could add alternate URLs to the login cards and consolidate multiple cards into one getting rid of apparent duplicates - but it is WAY too much manual effort AND the UI does not present a way to “add URL” to an existing card when logging in. Finally, many of the login items are NOT my own and customer’s have told me NOT to change the passwords. I need a way (via enable/disable above) to not make them display the overly-scary message “Change at-risk password”.

Thanks!

– Kevin

[dwbit]

Thanks for the feedback @kpGrelling! The team is continuing to work on making the notifications as useful as possible, stay tuned!

[grb]

@dwbit

The team is continuing to work on making the notifications as useful as possible

Are they also working on options to disable and/or dismiss the warnings (the topic of this feature request)?