Team password managers in 2026: revisit Vaultwarden, Passbolt and Psono before you share another password in a spreadsheet

In most small companies the first password manager is a spreadsheet. It starts with five rows: the domain registrar, the office router, the AWS root account, the payment gateway dashboard and the Wi-Fi. Two years later it has three hundred rows, four tabs, a column called “updated?” that nobody fills, and a file name like Passwords-Final-v3. It is shared with “anyone in the company with the link” because one person could not open it during an outage.

The spreadsheet usually survives until one of two things happens. An engineer who knew half the production logins leaves, and nobody can say which passwords to change. Or a large customer sends a security questionnaire that asks how shared credentials are stored, who can see them, how access is removed on exit, and whether there is an audit trail. At that point someone searches for “open source password manager for teams” and finds three names again and again.

This post revisits those three self-hosted options for sharing credentials among people: Vaultwarden (the community server that works with the official Bitwarden apps), Passbolt (Community Edition, with notes on Pro) and Psono (Community Edition, with notes on Enterprise). We also look at Bitwarden’s own self-hosted server, because anyone choosing Vaultwarden should know what the official option costs and requires. The goal is not to find the “most secure” tool in the abstract. It is to understand what each one encrypts, what its server is trusted to do, how it fits your identity setup, and what your small team must do every month to keep it safe.

A few pieces of news set the scene. Vaultwarden 1.37.4 arrived on 6 October 2026 (IST) with seven security fixes, including a high severity one where a revoked or unconfirmed organisation member could keep read and delete access to organisation items. It was one of several security releases this year. Passbolt 5.17 shipped on 20 October 2026 with passkeys as a second factor in all editions, a new autofill engine and a security bulletin on 29 October. Psono server 7.5.6 came out on 30 October 2026 after a busy month of small security releases. On the Bitwarden side, a malicious version of the Bitwarden CLI npm package was briefly published in April 2026, a reminder that the client side of a password manager has a supply chain too.

This post is about passwords that humans use and share. Machine secrets, like database passwords that an application reads at start up, belong in a secrets manager; see Vault and OpenBao and, for Kubernetes, Kubernetes secrets delivery in 2026. Passwords that have already leaked into Git are covered in secret scanning in 2026. If the real problem is shared SSH keys and server logins, infrastructure access in 2026 is the better read. Single sign on itself is covered in Keycloak and its alternatives, and backing up the server you choose in backups in 2026 and PostgreSQL backups in 2026.

A scenario to keep us honest

We will use one invented company through the post. Alkapuri Ledger Systems is an invented example, not a real business. It is a software company in Vadodara that builds accounting and GST filing software for chartered accountant firms and small manufacturers in Gujarat. It has 38 people: 22 engineers, 6 in customer support, 5 in sales and 5 in finance and administration. Infrastructure is handled by a two person team led by Nidhi, who also does DevOps for the product.

What they share today:

  • A Google Sheet with about 300 rows: cloud consoles, the domain registrar, DNS, the SMS gateway, the payment gateway, social media accounts, the office firewall and CCTV recorder, and test logins for customer environments.
  • A second sheet that finance keeps for bank portals and the GST portal, shared with three people.
  • Personal password managers on some laptops. Several engineers already use Bitwarden personally, and two use KeePassXC.
  • Google Workspace accounts for everybody, with two step verification enforced.

What triggered the review: a senior engineer left in September. He had access to the main sheet and nobody could list which of the 300 rows he had actually used, so the team spent two weekends rotating everything that looked important. Then a lending company that is evaluating their software sent a vendor security questionnaire. It asks how shared credentials are stored, whether access is role based, how access is revoked on exit, and whether access is logged.

Nidhi’s questions: which tool can two people run safely for five years, can people sign in with Google, what happens when somebody forgets their master password, how do we prove who saw what, and what will it cost?

The short version

  • Choose by trust model first. All three encrypt secrets in the client, but they draw the line differently. In the Bitwarden model used by Vaultwarden, every member of an organisation receives the same organisation key and the server decides which collections you see. Passbolt encrypts each secret separately for each person who can read it. Psono encrypts each share with its own key and gives that key to the members of the share.
  • Vaultwarden is the easiest start for a small team: the polished Bitwarden apps, organisations, collections, groups, event logs, emergency access and OpenID Connect login, all in one small Rust server under AGPL. The price is a busy security release stream in 2026 and the need to patch quickly. It has no SCIM.
  • Passbolt is built for teams sharing credentials, with OpenPGP, per user encryption and careful permission handling. The Community Edition is generous, but SSO, LDAP and SCIM provisioning, account recovery and the activity log are in Pro.
  • Psono Community Edition is Apache 2.0, runs on PostgreSQL and has a clean share model, but LDAP, SAML, OIDC, SCIM and audit logging are Enterprise features, and its SSO modes require the server to help unlock user secrets.
  • Bitwarden’s own self-hosted server is a good option if you buy Enterprise. Its standard deployment uses Microsoft SQL Server, and the lighter “Bitwarden lite” image is meant for personal use and home labs, not business.
  • For Alkapuri, our plan is Vaultwarden with strict hardening, separate organisations for the most sensitive credentials, a written patch promise and a tested restore, with Passbolt Pro kept as the fallback if the customer insists on vendor support.

Where things stand on 1 November 2026

Vaultwarden

Vaultwarden is an alternative implementation of the Bitwarden server API, written in Rust and licensed under AGPL 3.0. It started in February 2018 as bitwarden_rs and was renamed Vaultwarden with release 1.21.0 in April 2021. The project states clearly that it is not associated with Bitwarden Inc, and that one of its active maintainers is employed by Bitwarden and contributes in his own time. You use the official Bitwarden browser extensions, desktop apps, mobile apps and CLI, and Vaultwarden ships a lightly modified Bitwarden web vault.

The latest release is 1.37.4 (6 October 2026, IST). Release 1.35.0 in December 2025 added login through OpenID Connect. The 1.37 line added trusted proxy settings, object storage support for attachments and a change that rejects an unrecognised database URL instead of silently falling back to SQLite. Two releases this year were tied to client versions: Bitwarden clients 2026.7.0 and later need Vaultwarden 1.37.0, and clients 2026.8.0 and later need 1.37.2.

The project’s advisory page lists 37 published advisories, most of them from 2026 and most about authorisation inside organisations. We come back to them in the security section.

Passbolt

Passbolt is developed by Passbolt SA, a European company, and its server is a PHP application on CakePHP, licensed under AGPL 3.0 for all editions. The current release is 5.17.0 (20 October 2026). Version 5, released in April 2025, brought a redesigned interface and encrypted metadata, so item names and URLs can also be encrypted, not only the secret itself. During 2026 Passbolt made SCIM provisioning generally available (5.11, April), took Safari support out of beta (5.12, May), started an offline mode beta (5.16, September, read only and explicitly for testing) and added passkeys as a second factor in every edition (5.17).

Passbolt publishes an incidents page with security bulletins and audit results, which is unusually open. In 2026 that page includes a Cure53 audit of the SCIM and directory components, a Quarkslab pre-certification audit, bulletins for 5.14, 5.15 and 5.17, and a notice about an emergency PHP patch for critical remote code execution bugs on 21 October 2026, which affects every PHP application, not only Passbolt.

Psono

Psono is developed by esaqa GmbH, and its source now lives under the esaqa group on GitLab. The Community Edition server is a Django application under Apache 2.0, with PostgreSQL as the only database. Around it sit a pure JavaScript web client, browser extensions, mobile apps, an admin portal and an optional file server for encrypted file storage. The Enterprise Edition adds directory and SSO integration, SCIM, audit logging, policy enforcement and a browser based gateway for SSH, RDP and VNC.

Psono moves in many small steps. Server 7.0 in January 2026 moved to Python 3.14, 7.4 in August added delegated administration, and October brought 7.5.0 to 7.5.6 with a finished upgrade of password hashing parameters and several security fixes. The web client reached 4.9.2 on 23 October 2026 with a Safari extension and an importer for Bitwarden exports. In October 2026 five CVEs were also published for issues fixed back in server 7.2.4.

Bitwarden’s own server

The Bitwarden server repository is AGPL 3.0 by default, but the code in its bitwarden_license folder, which holds many enterprise features, is under the Bitwarden License, a source available licence. Self-hosting is supported, but features are unlocked by an organisation licence file, and the business pricing page lists self-hosting with the Enterprise plan (USD 6 per user per month billed annually), not with Teams (USD 4). The standard self-hosted deployment runs several containers and Microsoft SQL Server. Bitwarden lite, a single container that supports SQLite, PostgreSQL and MySQL or MariaDB, is described in Bitwarden’s own documentation as intended for personal use and home labs, not business. Server 2026.10.1 came out on 28 October 2026.

Around them

  • KeePassXC with a shared database file works for two or three people who already share a drive, but it has no per user access, no audit log and painful conflict handling once the team grows.
  • Hosted services such as Bitwarden cloud and 1Password remove the server work entirely. For many small teams that is the right answer, so cost it honestly before you self-host.

The first questions to ask

  1. What must the server never see? Secret values, item names and URLs, who has access to what? Each tool gives a different answer.
  2. Where do your users already sign in? Google Workspace, Microsoft Entra ID, an LDAP directory, or nothing? SSO, LDAP and SCIM are where free and paid editions differ most.
  3. What happens when someone forgets their master password or loses their key? With true client side encryption, “reset the password” can mean “lose the vault” unless recovery was planned in advance.
  4. How fine grained must sharing be? Team folders, per item sharing, read only access, ability to share further?
  5. What do you need to prove? An audit trail of who viewed or changed an item, exportable to your log system?
  6. Who will patch it, and how fast? A password manager is a high value internet facing target. A two week patch delay is not acceptable.
  7. Which clients do people need? Browser extensions for every browser in use, mobile apps, a desktop app, a CLI for engineers?
  8. What does offboarding look like? Removing access is easy. Knowing which passwords the person has seen, and rotating them, is the real work.

How each one works

Vaultwarden: the Bitwarden model on a small server

In the Bitwarden design, the client derives a key from your master password and email, using PBKDF2 or Argon2id, and uses it to protect your account keys. Vault items are encrypted in the client before upload. When you join an organisation, the organisation’s symmetric key is encrypted to your public key, so every confirmed member holds the same organisation key. Collections and groups then decide which items the server sends to which member. This is simple and fast, but it means collection permissions are enforced by the server, not by cryptography. If a member of an organisation is wrongly sent an item from a collection they should not see, their client can decrypt it.

Vaultwarden implements this API in a single process. The defaults are small: SQLite in a data folder, with MySQL, MariaDB and PostgreSQL as options. The data folder holds the database, attachments, Send files, an optional config.json written by the admin page, and the RSA key used to sign login tokens. The web vault needs HTTPS, because browsers only expose the Web Crypto API on secure origins.

Organisation features include collections, groups, member roles, policies, event logs, admin password reset (account recovery) and the Bitwarden Directory Connector for LDAP or Entra ID sync. Two factor options include TOTP, email, FIDO2 WebAuthn, YubiKey OTP and Duo. Emergency access lets a trusted person request access to your vault after a waiting period you choose. Since 1.35.0 users can sign in with an OpenID Connect provider, but the master password is still needed to decrypt the vault, so SSO here replaces the login step, not the encryption key. There is no SCIM endpoint.

A hardened starting configuration looks like this:

DOMAIN=https://vault.example.in
SIGNUPS_ALLOWED=false
INVITATIONS_ALLOWED=true
ORG_EVENTS_ENABLED=true
EVENTS_DAYS_RETAIN=730
EMERGENCY_ACCESS_ALLOWED=true
ADMIN_TOKEN='$argon2id$...'   # generate with: vaultwarden hash

Two defaults deserve attention. SIGNUPS_ALLOWED is true out of the box, so anyone who can reach the server can create an account until you turn it off. Organisation event logs are off by default, so the audit trail you will need later does not exist unless you enable it.

Passbolt: OpenPGP for every user and every secret

Every Passbolt user has an OpenPGP key pair, generated in the browser extension during setup and protected by a passphrase. The server has its own OpenPGP key too, used in the login protocol. When you share a password with five colleagues, your extension encrypts the secret five times, once to each person’s public key, and the server stores five copies. When you share with a group, the secret is encrypted for each member of the group. Nobody can decrypt a secret that was never encrypted for them, whatever the server’s permission tables say.

Since version 5, item metadata such as names, URLs and usernames can also be encrypted. Passbolt offers two modes for shared metadata keys: a “zero knowledge” mode where the server never has the shared metadata key, and a “server knowledge” mode that makes some administrative tasks easier. User accounts, group names and the permission structure itself remain visible to the server. Passbolt prefers to call its model end to end encryption rather than “zero knowledge”, which is a fair description.

The server needs PHP, a web server, a database and correct time (the login protocol is time sensitive, so run NTP). MariaDB or MySQL is the default; PostgreSQL is documented for new installations, with a warning not to switch an existing one. Users work through the browser extension (Chrome, Firefox, Edge and Safari), the mobile apps for Android and iOS, and a Windows desktop app. The web interface is served by the extension, which reduces the risk of a modified page stealing the passphrase, but it means you cannot simply open a browser on a kiosk and log in.

The Community Edition includes folders, groups, granular sharing with read, update and owner permissions, TOTP storage, custom fields, import from KeePass and CSV, MFA and password expiry. Pro adds LDAP sync, SSO with Microsoft, Google, generic OpenID Connect, AD FS and PingOne, SCIM, account recovery, the activity log, syslog forwarding of action logs, password and MFA policies, tags and a support contract.

The account recovery point matters. In CE, if a user loses their private key or forgets the passphrase and has no recovery kit, nobody can decrypt their copies. Colleagues who still have access can share the items again to a new account, but personal items are lost. Pro’s account recovery escrows a copy of each user’s private key, encrypted to an organisation recovery key held by administrators, with an approval workflow.

Psono: shares with their own keys

Psono uses NaCl through libsodium compatible libraries: ecma-nacl in the web client, PyNaCl on the server and sodium on mobile. The client derives an authentication key from the password with scrypt and keeps the encryption key separate, so the server only sees a value it can verify. Each user has a key pair. Items live in datastores and shares; a share has its own secret key, which is encrypted for every user or group that has rights on it. Rights are read, write and grant, and they can be set per share.

The server is a Django REST application behind nginx, with PostgreSQL. It is stateless apart from the database, so you can run more than one server instance behind a load balancer, and the documentation describes a redundant setup. The settings.yaml file holds server keys and secrets that are needed to work with stored data, which makes it as important as the database in your backups. Since 7.4.1 installation also generates an admin recovery key pair; the documentation says to print the private part, store it offline and never put it on the server.

The Community Edition gives you users, groups, sharing, the admin portal, health checks, security reports for users, multiple factor types, link shares, emergency codes and the file server. Enterprise adds LDAP, SAML and OIDC with group mapping, SCIM (with SAML), audit logging, enforced 2FA, and policies that can disable exports, API keys, link shares, recovery codes and more.

Psono’s documentation is honest about a trade off. LDAP login means the client must send the user’s plain password to the server so it can check it against the directory, with a warning shown to the user. SAML and OIDC mean the server needs a way to access the user’s secrets so it can hand the client a random “fake password” to decrypt the vault. In both cases the server is trusted with more than in a pure client side setup.

Bitwarden self-hosted: the same model, the vendor’s server

The cryptographic model is the same as Vaultwarden’s, because the clients are the same. The differences are in the server: official support, the full enterprise feature set including SCIM, SSO with trusted devices and Key Connector, and Bitwarden’s own security process. The costs are the Enterprise licence, the Microsoft SQL Server based standard deployment and a licence file that must be refreshed after each renewal.

Sharing and access models in practice

The way each tool models sharing decides how you design your vault.

  • Vaultwarden and Bitwarden. One organisation, many collections, users and groups assigned to collections with view, edit or manage rights. Simple to explain. Because the organisation key is shared, treat an organisation as the real security boundary and collections as convenience. For Alkapuri that means a separate small organisation for bank, GST and root cloud credentials, with only the people who need them as members.
  • Passbolt. Items and folders are shared to users and groups with read, update or owner rights. Each share is real encryption work, so sharing a folder of 300 items with a group of 30 means thousands of encryption operations in the browser. Passbolt has been improving this, and 5.17 claims group additions for 300 resources dropped from 1.19 seconds to 514 milliseconds, a figure from Passbolt’s own test.
  • Psono. Shares can be nested inside your datastore and granted to users or groups with read, write and grant rights. The model is flexible and cryptographic, but new users need a short explanation of datastores and shares.

Decide two things early, whatever the tool. First, who can add people to the finance and production credentials, which is organisation membership in Vaultwarden and owner or grant rights in Passbolt and Psono. Second, whether personal items are allowed and what happens to them on exit. Also note that every tool lets users export what they can read; Bitwarden Enterprise and Psono Enterprise have policies to restrict exports, so check what your edition can limit.

Identity, SSO and provisioning

This is where the editions split most clearly.

  • Vaultwarden. OpenID Connect login since 1.35.0, with an option to allow only SSO. The master password still unlocks the vault. Directory sync through Bitwarden Directory Connector. No SCIM. In 2026 the SSO code had its share of fixes, including a login CSRF and an email auto link issue that could bind an existing account to an attacker controlled identity, both fixed in 1.36.0.
  • Passbolt. CE has local accounts with MFA, including TOTP and YubiKey, and since 5.17 passkeys. LDAP, SSO and SCIM are Pro. SCIM was audited by Cure53 in February 2026 before general availability, and Passbolt tested it with Entra ID and Okta.
  • Psono. CE has local accounts with several second factors. LDAP, SAML, OIDC and SCIM are Enterprise, with the trust trade off described above.
  • Bitwarden Enterprise. SAML and OIDC SSO, SCIM, Directory Connector and options that remove the master password through trusted devices or Key Connector.

For Alkapuri, Google Workspace is the identity source. SSO login is pleasant, but the bigger win is offboarding: when Google disables a leaver’s account, the password manager should stop accepting their login quickly. With Vaultwarden, SSO only mode blocks new logins once the Google account is disabled, but existing sessions on laptops and phones are a separate matter, so the leaver must still be revoked in every organisation. That is a step on the exit checklist.

Security record

All four have a real security history, and that is normal for software in this category. What matters is how quickly issues are found, fixed and explained.

  • Vaultwarden. 37 published advisories on its GitHub page. In 2026 they include CVE-2026-26012 (full cipher listing that ignored collection permissions, fixed in 1.35.3 in February), CVE-2026-27802 and CVE-2026-27803 (manager role privilege escalation, fixed in 1.35.4), CVE-2026-43912 and CVE-2026-43913 (cross organisation group binding and an unconfirmed owner able to purge an organisation vault, fixed in 1.35.5 in April), CVE-2026-47158 and CVE-2026-47164 (SSO flaws, fixed in 1.36.0), nine advisories in 1.37.0 in July and seven in 1.37.4 in October. In January 2025, CVE-2025-24364 was a remote code execution bug in the admin panel. Most of these need an authenticated user, and secret values stay encrypted, but remember the organisation key model: a bug that sends a member items from the wrong collection inside their own organisation does expose readable data to that member. The response has been fast and well documented, and recent releases are published as immutable, attested GitHub releases.
  • Bitwarden. Regular third party assessments, including several Cure53 reports in 2025 and an analysis by ETH Zurich’s Applied Cryptography Group under a fully malicious server model, published by Bitwarden in February 2026, which reported medium and low severity attacks; Bitwarden said most were fixed or being fixed and a few were accepted as design decisions. On 22 April 2026 (UTC; early 23 April IST) a malicious @bitwarden/cli 2026.4.0 package was on npm for about ninety minutes as part of a wider supply chain campaign, tracked as CVE-2026-42994. Bitwarden said it found no evidence that vault data was accessed and released 2026.4.1.
  • Passbolt. A long public record on its incidents page, from Cure53 cryptography reviews in 2021 to a Cure53 audit of version 5.1 in May 2025, which noted a known limitation around metadata integrity, a Quarkslab pre-certification audit and a February 2026 Cure53 SCIM audit with 12 findings, one high, which were fixed by 5.13 except one accepted denial of service item. The 5.17 bulletin fixes a server side request forgery bypass in SSO URL validation (CVSS 7.6, Pro), a blind SSRF through avatar upload, an MFA brute force limiter gap and two browser extension issues.
  • Psono. An X41 D-Sec cryptography review in mid 2024 (one high and three medium findings, with praise for the use of NaCl), a Cure53 audit of the browser extensions and API in March 2025 (eight findings, all fixed) and a Cure53 audit of the admin console in March 2026 (findings no higher than low). Five CVEs were published in October 2026 (CVE-2026-117468 to CVE-2026-117472) for medium severity issues such as a WebAuthn assertion replay and an API key scope bypass, all affecting versions up to 7.2.3. CVE-2025-1987 was an XSS in the Psono client as embedded in Bitdefender SecurePass, which is built on Psono.

The lesson is not “avoid the tool with the most advisories”. A busy advisory page can mean active review and honest disclosure. The lesson is that any of these servers must be patched within days, not quarters, and that the people running it must watch the project’s release and advisory feeds.

Licences and commercial models

  • Vaultwarden. AGPL 3.0, no paid edition, no vendor. Every feature it implements is free. Support is the community forum and GitHub. If you modify it and offer it as a network service to others, AGPL obligations apply; running it unmodified for your own staff is the normal case.
  • Bitwarden. Server AGPL 3.0 plus Bitwarden License for enterprise code; clients GPL 3.0 plus the Bitwarden License directory. Self-hosting for a company means the Enterprise plan, USD 6 per user per month billed annually on the published page. For 38 users that is USD 2,736 a year. Teams at USD 4 per user is cloud hosted.
  • Passbolt. AGPL 3.0 for CE and Pro code; Pro is a subscription with a key file. Pro is listed at USD 4.9 per user per month billed annually, minimum 10 users, with volume discounts after 100. For 38 users that is about USD 2,234 a year. If a Pro subscription lapses, the server keeps running but you lose updates and support. Enterprise is custom priced, with high availability consulting and shorter support response times.
  • Psono. CE under Apache 2.0, the most permissive licence here. Enterprise is free for up to 10 users; for larger teams the published price starts at EUR 2.5 per user for teams of at least 25 users. Ask for a written quote with the billing period. A hosted SaaS option also exists.

Remember the hidden cost in every self-hosted option: someone’s time for patching, backups, restore tests and helping users. For a team of 38, an hour a week is realistic.

Operations and day two

Backup and restore

  • Vaultwarden. Back up the whole data folder: the database, attachments, Send files, config.json and the RSA key. For SQLite, use the built-in command (since 1.32.1), sqlite3 .backup or VACUUM INTO rather than copying a live file; the project advises against relying on file system or VM snapshots alone. Backups are not encrypted by the tool and config.json can contain the admin token, so encrypt them, for example with restic.
  • Passbolt. Back up the database (with the bundled sql_export command), the server OpenPGP keys, the configuration files and TLS certificates. Restore into an empty database with mysql_import, put the keys back, then run the health check. Losing the server key does not expose secrets, but it breaks the login protocol for every user.
  • Psono. Back up PostgreSQL with your normal tools and the settings.yaml file. The documentation states plainly that you need settings.yaml to make use of the data. Keep the admin recovery private key offline, separate from both.

Here is a minimal nightly job for Vaultwarden in Docker, followed by an encrypted copy:

docker exec vaultwarden /vaultwarden backup
restic -r sftp:backup@nas.office.lan:/vault-backups backup /srv/vaultwarden/data
restic -r sftp:backup@nas.office.lan:/vault-backups forget --keep-daily 14 --keep-monthly 12 --prune

And for Passbolt in Docker, the documented pattern is:

docker compose -f docker-compose-ce.yaml exec passbolt \
  su -s /bin/bash -c "./bin/cake passbolt sql_export" www-data
docker compose -f docker-compose-ce.yaml exec passbolt \
  su -s /bin/bash -c "./bin/cake passbolt healthcheck" www-data

Then copy the export, the GPG keys and the configuration off the host. For any tool, the test is the same: restore to a fresh machine, log in with a real client, open a shared item and an attachment.

Upgrades

  • Vaultwarden upgrades are usually a container image change and a restart; database migrations run automatically. Read the release notes, because 1.37.4 changed how X-Forwarded-For is parsed and removed some legacy settings. Keep the server ahead of the clients, since recent Bitwarden clients refuse older servers.
  • Passbolt upgrades come as packages or images, and the major version notes list deprecated PHP and database versions; MariaDB 10.3 and 10.5 and MySQL 5 support ends in January 2027. Browser extensions update on their own from the stores, so the server must keep up.
  • Psono has very frequent releases, many of them dependency updates. Pin versions, upgrade server, client and admin portal together, and run migrations as the documentation describes.

High availability

A team of 38 rarely needs active high availability for a password manager; it needs a fast restore and offline access. Bitwarden clients keep an encrypted local copy that unlocks when the server is down. Passbolt’s offline mode is still a beta for testing. Psono’s server can run as several instances on one PostgreSQL. Plan for a two hour restore and a printed emergency sheet for the few credentials needed to rebuild the password manager itself.

Emergency access and offboarding

  • Joining. Invite through the tool, enforce 2FA, and in Vaultwarden enrol members in admin password reset by policy, so a forgotten master password does not mean a lost vault.
  • Leaving. Revoke the user in the tool, then rotate what they could read. All three can show which shared items a user had access to; Vaultwarden (with event logs enabled) and Passbolt Pro also record access events. Rotation is still manual, so give each item an owner.
  • Emergency. Vaultwarden has emergency access between users. Psono has emergency codes. Passbolt Pro has account recovery. For the owners of the company, write down who can get in if the two administrators are unavailable, and test it once.

Side by side

  • Trust model. Vaultwarden and Bitwarden share one key per organisation and enforce collections on the server. Passbolt encrypts every secret for every reader with OpenPGP. Psono encrypts each share with its own key, but its Enterprise SSO and LDAP modes give the server more trust.
  • Identity. Vaultwarden has OIDC login and Directory Connector for free, no SCIM. Passbolt keeps LDAP, SSO and SCIM in Pro. Psono keeps them in Enterprise, which is free for up to 10 users. Bitwarden Enterprise has the most complete set.
  • Clients. Vaultwarden uses the full Bitwarden client family, the most polished set here. Passbolt requires its browser extension for web use and has mobile and Windows apps. Psono has a web client, extensions and mobile apps.
  • Audit. Vaultwarden has organisation event logs once enabled. Passbolt’s activity log is Pro. Psono’s audit log is Enterprise.
  • Operations. Vaultwarden is one small container on SQLite. Passbolt is a PHP stack with MariaDB, MySQL or PostgreSQL and server GPG keys. Psono is Django on PostgreSQL with a settings file that holds keys. Bitwarden’s standard deployment is several containers on Microsoft SQL Server.
  • Support. Vaultwarden has community support only. Passbolt and Psono sell support with their paid editions. Bitwarden sells Enterprise support.
  • Performance. Server speed is rarely the limit at small team scale; browser extensions and autofill shape the daily experience. Figures quoted in this post are the vendors’ own measurements.

A worked plan for Vadodara

Nidhi’s team chooses Vaultwarden, with Passbolt Pro as the documented fallback. The reasons: people already know the Bitwarden apps, the free feature set covers groups, event logs, emergency access, admin password reset and Google login, and two people can run a single container. The risk they accept, in writing, is the patch burden.

  1. Week 1: design on paper. List the 300 rows by owner and sensitivity. Plan three organisations: “Alkapuri General” for most shared logins, “Alkapuri Finance” for bank and GST credentials (four members), and “Alkapuri Production” for root cloud accounts and the registrar (five members). Collections inside each organisation by team.
  2. Week 1: build. One small VM in the office server room or a cloud VM in Mumbai, Docker with a pinned Vaultwarden image, PostgreSQL or SQLite (SQLite is fine at this size), a reverse proxy with a valid certificate, SIGNUPS_ALLOWED=false, an Argon2 admin token, event logs on, SMTP configured, and the admin page reachable only from the office VPN.
  3. Week 2: SSO and policies. Configure OIDC against Google Workspace and test it with two users. Enable policies for two step login, master password strength and enrolment in admin password reset. Turn on emergency access for the two founders.
  4. Week 2: backup and restore. Nightly built-in backup plus an encrypted restic copy to the NAS and a second copy off site. Restore onto a spare VM and open a shared item from a phone. Repeat every quarter.
  5. Weeks 3 and 4: migrate. Import team by team from CSV, then delete the sheets, not just restrict them. Rotate the credentials the leaver had seen as part of the move.
  6. Ongoing: patching. Subscribe to Vaultwarden releases and advisories on GitHub. Promise, in the security questionnaire answer, that security releases are applied within three working days, and keep a log of each upgrade.
  7. Ongoing: offboarding. Add two lines to the exit checklist: revoke in every organisation, and rotate items the person could read, starting with the Production and Finance organisations.

When would they switch to Passbolt Pro? If the lending customer asks for a vendor support contract, SCIM provisioning or per secret encryption as a requirement, the cost is about USD 2,234 a year at list price, and the per user OpenPGP model answers the “server bug” question more strongly.

When not to adopt each

  • Vaultwarden. Skip it if nobody can commit to patching within days, if you need SCIM or a support contract, or if an auditor will not accept a community project. Also skip it if you want collection level separation to be cryptographic.
  • Passbolt CE. Skip it if you need SSO, directory sync or an audit trail but cannot pay for Pro, or if your users must log in from browsers where they cannot install an extension.
  • Psono. Skip it if you need SSO but want the server to stay blind to user secrets, or if your team cannot follow a fast stream of small releases.
  • Bitwarden self-hosted. Skip it if you will not buy Enterprise or do not want to run Microsoft SQL Server. Do not run Bitwarden lite for a business against the vendor’s own guidance.

A short history

  • 2015 to 2018. The Bitwarden server repository began in November 2015, Passbolt’s API in February 2016 and Psono’s server code in 2017. bitwarden_rs started in February 2018, the same year Passbolt 2.0 shipped.
  • 2021 to 2024. bitwarden_rs became Vaultwarden in April 2021. Passbolt 3.0 (2021) and 4.0 (2023) followed, Psono server 5.0 arrived in October 2024, and the Bitwarden SDK licence argument happened that same month.
  • 2025. Passbolt 5.0 with encrypted metadata in April. Bitwarden’s Unified image became Bitwarden lite in December, and Vaultwarden 1.35.0 added OpenID Connect login on 27 December.
  • 2026. A heavy year of security work in all four projects: many Vaultwarden advisories, the Bitwarden CLI npm incident, Passbolt’s SCIM audit and general availability, and Psono 7.x with several audits and CVEs.

Decision guide

You are a small team, already like the Bitwarden apps, and can patch quickly

Use Vaultwarden. Turn off sign ups, enable event logs, use separate organisations for the most sensitive credentials, and treat every security release as urgent.

You need SSO, SCIM, audit logs and a support contract, and the budget exists

Compare Passbolt Pro and Bitwarden Enterprise. Passbolt gives per secret encryption and an open incidents record, at the cost of a required browser extension and planned key recovery. Bitwarden gives the most polished clients and the widest enterprise feature set, with a Microsoft SQL Server deployment.

You want the most permissive licence and run PostgreSQL already

Look at Psono CE. If you are ten users or fewer, Enterprise is free, but understand what its SSO modes ask the server to do.

Checklist

  • An inventory of shared credentials with an owner and a sensitivity level for each.
  • A written trust model: what the server must never see, and which tool meets it.
  • Sign ups disabled, admin interfaces off the internet, admin credentials hashed and stored safely.
  • Two factor authentication enforced for every user, with phishing resistant options for administrators.
  • A recovery plan for forgotten master passwords or lost keys, tested with one volunteer.
  • Separate organisations, groups or shares for finance and production credentials.
  • Audit or event logging enabled and retained for the period your customers ask for.
  • Encrypted, off host backups that include keys and configuration, with a quarterly restore test.
  • A patch promise with a named owner, and subscriptions to release and advisory feeds.
  • An exit checklist entry for revoking access and rotating what the leaver could read.
  • The old spreadsheets deleted, not just hidden.

Common mistakes

  • Leaving open sign up on. Vaultwarden allows sign ups by default. Anyone who finds the URL can create an account.
  • Treating collections as walls. In the Bitwarden model they are server side filters inside one encrypted organisation. Use separate organisations for real separation.
  • Not planning recovery. With client side encryption, a forgotten password or lost key can mean lost data. Enrol users in recovery, or make sure recovery kits exist.
  • Letting clients get ahead of the server. Bitwarden clients update automatically and recent versions need recent Vaultwarden releases. An old server means users suddenly cannot log in.
  • Believing removal equals safety. Revoking a leaver does not make them forget passwords. Rotate.
  • Importing the spreadsheet and keeping it. The old file becomes the weakest copy of every secret.
  • Self-hosting with no owner. A well run hosted service is safer than an unpatched self-hosted one.

A small hands-on check

We ran one small drill for this post, on a loopback only test box, without Docker or any system packages. We extracted the Vaultwarden 1.37.4 binary and web vault from the official Alpine image, started it as a normal user on 127.0.0.1 with SQLite in a local folder, and checked a few behaviours from this post. With SIGNUPS_ALLOWED=false, a registration attempt was refused with “Registration not allowed or user already exists”. The server printed a notice at start up that a plain text admin token is insecure and suggested an Argon2 hash. A wrong admin token got a 401, and the right one let us invite a test user. The built-in backup command wrote a dated SQLite copy inside the data folder, which opened cleanly and passed an integrity check. Note that the copy sits next to the live database, so it must still be moved off the host and encrypted. We then stopped the process.

We did not test client side encryption, organisations, sharing or SSO, because those need real Bitwarden clients and HTTPS. We did not run Passbolt or Psono. Everything else about them in this post comes from their documentation, release notes, licence files, pricing pages and security publications, listed below.

Unlearn, re-learn

  • Unlearn “it is encrypted, so the server does not matter”. Re-learn that each tool trusts its server with different things, and that authorisation bugs matter more in some models than others.
  • Unlearn “SSO means no master password”. Re-learn that in client side encrypted tools, SSO either only replaces login or asks the server to hold more keys. Know which one you bought.
  • Unlearn “open source means free forever”. Re-learn that SSO, SCIM and audit logs often sit in paid editions, and that your time for patching is the biggest cost.
  • Unlearn “offboarding is removing an account”. Re-learn that offboarding is rotating what the person knew, and design ownership so that rotation is possible.
  • Practise a restore and a forgotten password recovery every quarter, and apply the smallest tool your team can patch within days.

Sources

Vaultwarden

Bitwarden

Passbolt

Psono

comments powered by Disqus

Releted Posts

Virtualization platforms in 2026: revisit Proxmox VE, XCP-ng and Incus before you migrate another virtual machine

Most virtualization migrations in India over the last two years did not start with an architecture review. They started with a renewal quote.

Read more

HTTP caching in 2026: revisit Varnish and Vinyl Cache, Apache Traffic Server and NGINX before you put another cache in front of your app

Most teams add an HTTP cache on a bad day. The home page is slow during a traffic spike, the database is at 100% CPU, and somebody says “let us just put Varnish in front”.

Read more

Infrastructure access in 2026: revisit Teleport, Boundary and Warpgate before you hand out another SSH key

Every engineering team has an access story it does not like to tell. A new developer joins, and someone appends her public key to authorized_keys on fourteen servers by hand.

Read more