Bitwarden Roadmap

Updated May 2025

End user experience and autofill
End user onboarding and UI: browser extension onboarding nudges to guide users on key features of the browser extension upon initial installation
End user onboarding and UI: logging into the browser extension post-account creation on web to accelerate browser extension setup
End user onboarding and UI: post-account creation, guide users to download the browser extension, pin the browser extension, and understand how to generate passwords, save logins, and autofill.
Improving performance load times for extension and autofill
Bitwarden Authenticator: synced vault items between Password Manager and Authenticator
Bitwarden Send: expanding Bitwarden Send to allow Send creators to require email verification via OTP to open the Send by the recipient
Desktop (MacOS) auto-type of passwords
Desktop (Windows) auto-type of passwords
Desktop (MacOS) native use of passkeys
Desktop (Windows) native use of passkeys
Credential Exchange Protocol (CXP) support on mobile
Bitwarden for business
SSO w/ trusted devices: enabling device approvals on the browser extension
Access Intelligence Limited Preview: New Risk Insights dashboard that allows organizations to roll-up credentials into applications, categorize the criticality and risk of applications, and send guided alerts to end users to update weak, reused, or exposed passwords. Reach out to [Sales] (https://bitwarden.com/contact-sales/) to enable your organization for Access Intelligence.
Policies: Expansion to individual vault policy that will allow creation of default collections, called My items, for enterprise users to have a personal space to save business items to
Collection permissions: Edit item permission will now include the ability for users to delete items from collections. If you prefer to restrict deletion of items to users with the Manage collection permission, organization owners will have access to a new setting, Limit item deletion to users with the Manage collection permission.
Policies: new enterprise policy that allows organizations to disable use of credit card item type
Policies: expansion to Vault Timeout policy to separate lock and logout actions
Policies: new policy to set default match URI detection policy for autofill
Reporting: improving performance load times for large organizations
Collections: Improving performance load times for large organizations

Transparency
Items listed on the roadmap are active, in-development initiatives from the Bitwarden product and engineering team. As the Bitwarden team releases new features, this roadmap will be updated as a living document so that the Bitwarden community will know what new items are in progress as well as items likely to be released near-term.

Any dates provided by Bitwarden team members on any initiatives are targets and will be continually revised as the team gets closer to release. As with all features, the top priority is ensuring security and product stability.

Previous releases
You can also review previous release notes to learn more about recently launched features.

Posting a feature request
Start here :arrow_left: to learn how to post a feature request.

Bitwarden Password Manager

Bitwarden Secrets Manager

Bitwarden Authenticator

Bitwarden Passwordless.dev

17 Likes

Can someone explain what this means? My first reaction is that it sounds like it may create a new attack surface for the browser extension…

Just to double-check: Bitwarden Unified not appearing on the roadmap probably means we should not expect it to leave beta any time soon, correct?

Can someone explain what this means? My first reaction is that it sounds like it may create a new attack surface for the browser extension…

Shared state refers to both shared login state and shared unlock state. That is, logging into your web vault, will log you into your browser extension, and vice versa, and, unlocking/locking one of them would unlock/lock both.

3 Likes

Does this require any IPC that may create a potential new vulnerability?

Yes, this requires a new IPC layer at large (currently being built), a new transport layer encryption (Most likely Noise), and new ways to determine trust. I.e

  • “How does the web vault (locally) know it’s talking to the browser before handing over secrets”
  • “How does the browser extension know it’s talking to the web vault (locally) before handing over secrets”

Passive sniffing, or secrets being swapped to disk is prevented by the transport layer encryption. The interesting part here is trust. (I don’t know the current progress on trust, so I won’t comment on that).

Of course, as always, this is covered by regular audits, is open source, and reviewed internally for security issues before releasing.

4 Likes

Thank you for providing the additional detail. Do you know if there are any plans for an opt-out option for those who don’t need this feature?

The most critical scenario is being able to log into the browser extension from the web, given that most users start with account creation on the web and the goal is to accelerate onboarding to the browser extension. For now, this may be limited to new users post-account creation. This is still in early technical research.

1 Like

OK, thanks for the additional information. Having the Web Vault login automatically authenticate the browser extension would be a useful work-around to the delayed (or abandoned?) implementation of passkey login for the browser extensions.

However, forcing the browser extension to log out whenever the Web Vault logs out (which I think is what was implied by @Quexten’s “vice versa” comment above) does not seem to serve any useful purpose.