Business password manager requirements checklist

A checklist of functional, security, integration, operational and compliance requirements for a self-hosted team password manager, with how to verify each one and the questions that separate Passbolt, Bitwarden and Vaultwarden.

On this page

How to use this business password manager requirements checklist

Most teams that run shared credentials in spreadsheets or a consumer vault know they need a self-hosted replacement that keeps activity logs and a recovery path, but they struggle to say what "good enough" means. This checklist turns those needs into verifiable tests: each requirement is written so that someone can open a product, run a specific action and record whether it passed. Use it to compare candidates on evidence rather than on feature pages, and to decide early which gaps you can accept.

The three main candidates answer the hard questions differently. Passbolt uses OpenPGP end-to-end encryption, where each user holds a key pair and each shared resource is encrypted separately for every authorized user. Bitwarden and Vaultwarden use their own client-side encryption model built around the Bitwarden Client API. Directory sync, SSO, SCIM and account recovery are where these models diverge most, and the edition boundary often decides the answer: several of the features you may need sit in Passbolt's Pro tier, while Bitwarden's paid features require a license file tied to the installation. Confirm each boundary against the current pricing or licensing page before you score a product as meeting a requirement.

Score every requirement as must, should or not needed. A must is a condition for go-live, such as audit logging for every credential access or a tested recovery procedure. A should improves operations but can be handled with a documented workaround. Mark anything you are not sure about as unknown, not as met. Then run the must-level tests in a proof of concept on your own infrastructure before purchase, using test accounts, a sample import from your current tool and a restore from backup. Record the results, the edition used and the exact version tested, because the answer for a given feature can change between releases.

Which functional requirements a team password manager must meet

This table lists the functional requirements a team password manager must meet, why each one matters, and how to verify it in a test tenant before committing. Read each row as a test you can run with a pilot group, and note where the answer depends on the edition or client you choose. The main takeaway is that sharing, import and export policies differ more between products than the headline feature list suggests.

RequirementWhy it mattersHow to verify in a test tenant
Sharing and groupsShared service and vendor accounts need to be granted to teams without copying passwords into personal vaults. Vaultwarden implements organizations, collections, groups and member roles, and Passbolt shares each resource with per-user encrypted copies.Create two groups, share one resource read-only to one group and editable to another, then confirm that removing a member revokes access to the shared item.
Folder and collection designStructure determines who can see what and how offboarding works. Poor folder design often leads to shared items sitting in personal folders that nobody administers.Build a sample hierarchy for one team, assign collections or folders by role, and test that a user outside the team cannot list or search the items.
Import from the current toolPassbolt documents CSV imports from LastPass, 1Password, Dashlane, NordPass, Bitwarden, Chrome, Firefox, Edge, Safari and others for its Community, Pro and Cloud editions. Imports often lose folders, notes or custom fields, so the mapping must be checked.Import a representative export from your current tool into the test tenant, then compare item counts, folder mapping, attachments and custom fields against the source.
Export controlsSince Passbolt 5.10, cleartext CSV exports are disabled by default and encrypted KeePass KDBX formats are offered unless an administrator allows CSV again in the export policies. Vaultwarden and Bitwarden exports need the same review to confirm who can take data out.As a non-admin user, attempt each export format. Confirm that cleartext CSV is blocked, check the export policy setting, and record the result as evidence.
Browser extension and mobile clientsUsers work in the browser and on phones, and autofill is where most daily use happens. Passbolt encrypts and decrypts locally in its browser extension or mobile app, and Vaultwarden works with the official Bitwarden clients.Install the browser extension and mobile app on the standard browsers and device types in use, sign in, test autofill on three to five sites, and confirm the client updates through your normal software channel.
Password generation and policiesGenerated passwords must be unique and long enough for each account. Passbolt lists passphrase and password policies as a Pro feature, so generator rules may depend on the edition you buy.Generate passwords under the default policy, then under any stricter policy you set. Confirm which policies are enforced by the server and which are only suggestions in the client.
Password expirySome frameworks expect password change cycles, while current guidance often prefers rotation on compromise. Passbolt lists a password expiry policy as a Pro feature, so confirm whether it exists in the edition you plan to run.Set an expiry rule on a test resource, confirm the reminder or forced change behavior, and check whether shared resources and service accounts are excluded or handled differently.
Directory sync and SSOJoiners and leavers need automatic access changes. Passbolt lists LDAP provisioning, SSO and SCIM as Pro features, and Vaultwarden added OpenID Connect SSO in version 1.35.0 with later SSO settings.Add a test user through the directory, confirm group membership appears in the vault, then disable the user and confirm sign-in and vault access stop. Confirm which provisioning method your edition supports.

What end-to-end encryption means for your requirements

Treat client-side encryption as a testable requirement, not a marketing claim. The question to settle first is whether the server can read credentials, and the answer depends on the product and on settings you control. Ask each vendor to show, in writing, which data is encrypted on the client before it leaves the user's device. A vendor that only says the data is "encrypted" has not answered the question.

Passbolt uses an OpenPGP model. Each user holds a key pair, and when a resource is shared, the client creates a separate copy of the secret encrypted to each authorized user's public key. Passbolt's documentation states that the server only receives and stores ciphertext, and that the browser extension or mobile app performs the encryption and decryption. Note the metadata gap: names, URLs and descriptions are encrypted only with the v5 format and only when the organization enables metadata encryption. Confirm that setting in your pilot, and decide whether your auditors need it on from day one.

For Bitwarden and Vaultwarden, the requirement is the same, but the evidence is different. Ask each vendor to document which vault fields are encrypted client-side, how the server handles the organization keys used for sharing, and what an administrator or database operator can see if they have full access to the server. Ask whether metadata such as item names and URLs is protected in the same way as passwords. For Vaultwarden, which is an independent server implementation of the Bitwarden Client API, ask the maintainers to confirm the encryption behavior directly rather than assume it matches the official service. Record the answers and the version you tested, because they become part of your control evidence.

Security requirements to verify before selecting a vault

These six requirements decide whether a self-hosted vault can be operated safely in your environment. Each card names a decision and a check you can run during evaluation, so you can test the claim before you commit to Passbolt, Bitwarden or Vaultwarden.

MFA and phishing-resistant factors

Confirm which second factors the vault accepts for the web vault and for administrators, and whether the MFA policy can be enforced for admins separately from regular users. Vaultwarden lists authenticator apps, email, FIDO2 WebAuthn and YubiKey among its two-factor options, and Passbolt gates MFA policies behind its Pro edition. In a test tenant, enable the policy for an admin account, attempt a login with a password only, and confirm it is refused. Record the result as evidence.

HTTPS behind a reverse proxy

The web vault relies on the browser's Web Crypto API, which requires a secure context, so the vault must be served over HTTPS. Vaultwarden recommends running it behind a reverse proxy. Confirm the certificate chain is issued by your internal or public CA, that plain HTTP redirects to HTTPS, and that the proxy does not cache vault responses. Test the web vault and the browser extension against the same hostname before rollout.

Signed browser extensions and client code

Passbolt encrypts and decrypts in the browser extension or mobile app rather than on the server, and states that its browser extension is cryptographically signed. Bitwarden clients are published under GPL v3.0. For each candidate, ask the vendor how extension builds are signed, where they are distributed, and how you verify a build before pushing it to managed browsers. Put the verification step into your change process, because the extension is part of your trust boundary.

Administrator account protection

The admin backend controls users, organizations and server settings, so it is the highest-value target in the deployment. Vaultwarden provides its own admin page, which should be disabled or restricted to a management network after setup. Verify that admin access requires MFA, that the admin interface is not exposed to the internet, and that a second administrator can recover access. Test each step with a named admin account and document the outcome.

Event logs and syslog forwarding

Audit trails must reach your central monitoring, not only the vault's own screens. Passbolt lists syslog activity logs as a Pro feature, and Vaultwarden includes event logs for organizations. Confirm which events are recorded (sign-ins, shares, exports, policy changes, admin actions), whether they can be forwarded to your SIEM, and how long the vault keeps them. Generate a test event, then confirm it arrives in your log platform.

Database choice: SQLite or PostgreSQL

Vaultwarden uses SQLite by default and can use MySQL or PostgreSQL through the DATABASE_URL setting, and its template marks PostgreSQL as recommended. SQLite stores everything in one file, which simplifies small installs but complicates concurrent access and consistent backups. Ask which database your candidate supports and whether backups can be taken while the service runs. Restore a backup to a separate host and confirm that users, shares and attachments all come back.

How directory sync and SSO requirements differ by edition

Passbolt's free Community Edition is self-hosted with unlimited users, but the identity features that most organizations need for joiner and leaver control sit in the Pro tier. The pricing comparison lists LDAP user and group provisioning from Active Directory or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, password expiry policies and SCIM as Pro features not in Community Edition. Account recovery is also listed as Pro, which affects how you plan for lost keys.

  • Paid identity features: LDAP provisioning, SSO, MFA policies, SCIM and account recovery are all listed as Pro features, so budget for them if you need them.
  • Pro pricing basis: The pricing page lists Pro at $4.9 per user per month billed annually with a 10-user minimum, so confirm the current figure and minimum before you budget.
  • Community limits: Without LDAP or SCIM, user removal in Community Edition is a manual step that you must document and test.
  • Syslog forwarding: Activity logs forwarded by syslog are a Pro feature, which matters if your SIEM needs vault events.
  • Enterprise tier: Custom pricing applies to Enterprise, so ask the vendor what it adds for your directory design.

Confirm with Passbolt which Pro features you need, in writing, and check the current pricing page before finalizing scope.

Account recovery and paid editions: where the requirement changes the answer

Account recovery decides how a password manager behaves when a user loses a device, forgets a master password or leaves the company with the only copy of a key. In end-to-end encrypted designs, the server cannot reset a vault for the user, so recovery is a deliberate design choice. An admin-controlled recovery path lets an administrator restore access to a vault, which protects the business from lost data but means the administrator can, in principle, reach encrypted material that belongs to a person. A user-only design avoids that trade-off but makes a lost key a permanent loss. Decide which model your policy and your data owners accept before you choose a product, and write the decision down so auditors can see it was made on purpose.

The edition question often arrives with the recovery question. Passbolt lists account recovery as a Pro feature, not part of the free Community Edition, so a team that needs admin-assisted recovery in Passbolt should price Pro into the design from the start. For Bitwarden, the server code in the main repository is under AGPL 3.0, but files in the bitwarden_license directory, including the SSO integration modules, fall under the Bitwarden License, which the vendor's FAQ says requires a paid subscription for production use. Paid features on a self-hosted Bitwarden installation also need a license file downloaded from the cloud Admin Console and tied to the installation ID, and the data region must match the cloud organization's region. Vaultwarden is a separate AGPL-3.0 implementation that is not associated with Bitwarden, Inc., so its licensing position differs from the official server.

Integration requirements that connect the vault to your identity stack

A team password manager is only as current as the identity records, logs and backups around it. The cards below cover the integrations to specify before choosing an edition, because each one decides who can log in, what gets recorded and how the vault is restored. For the wider identity design, see the security and identity pillar.

Directory sync with your user source

Groups in the vault should follow groups in the directory, not hand-maintained lists. Confirm which source is authoritative (Active Directory, LDAP, Entra ID, Google Workspace or Okta), whether the vault can sync users and groups from it, and whether the sync removes deprovisioned accounts or only adds new ones. In Passbolt, LDAP user and group provisioning from AD or OpenLDAP is a Pro feature, so confirm it against the edition you plan to run. Bitwarden's Directory Connector covers AD, LDAP, Azure, Google Workspace and Okta, and is a separate GPL-3.0 component to deploy and monitor.

SSO through your existing identity provider

Decide whether the vault delegates login to the identity provider your organization already runs, such as Keycloak, authentik or ZITADEL covered on the sibling SSO pages. Confirm the protocol the vault supports (OpenID Connect, SAML 2.0 or both), whether SSO replaces or sits beside the master password, and what happens to the encrypted vault if the identity provider is down. For Passbolt, SSO with Microsoft, Google, OpenID and AD FS is listed as a Pro feature. Vaultwarden added SSO with OpenID Connect in version 1.35.0, so test that path against your provider before relying on it.

Log forwarding into your SIEM

Audit events from the vault only matter if they reach the place where someone reviews them. Confirm which events the vault records (logins, sharing changes, exports, policy edits), how they leave the server (syslog, API or database export), and whether the format fits your collector. Passbolt lists syslog activity logs as a Pro feature. A Wazuh or other SIEM pipeline should parse these events, alert on exports and admin changes, and keep retention aligned with your policy. Test with a real export event before go-live.

Backup and restore of the vault

The vault has two parts to protect: the database and the attachments or file storage. Confirm the backup method, its frequency, where copies go and whether they are encrypted at rest. The Vaultwarden project states that it cannot be held liable for data loss and strongly recommends regular backups of files and the database, so the backup design is your responsibility. Restore a copy to a test host and confirm that users can log in and decrypt a sample item, because a backup that has never been restored is not evidence of recoverability.

Helm or Docker deployment into existing infrastructure

Check that the vault fits your platform standards before the installer decides the design. Passbolt supports Docker, a Kubernetes Helm chart, an AWS AMI, Ansible and several Linux distributions, while Bitwarden publishes official Helm charts and a Linux install that requires Docker Engine 26 or later. Confirm the minimum host sizing, the database engine, the reverse proxy and HTTPS certificate handling, and whether your container registry can mirror the images. Vaultwarden recommends its container images on ghcr.io, docker.io and quay.io, so record which registry your change process approves.

Offboarding linked to the leaver process

Removing a person from the directory should also remove their vault access, shared folder membership and any credentials that only they knew. Define who triggers the offboarding step, how fast it must happen after the HR or identity event, and how shared credentials are rotated when a leaver had access. Confirm that the vault can revoke a user without deleting the items they shared, and that an administrator can recover or reassign their items. Record each offboarding for the audit trail, since this step is often the first thing an assessor asks to see.

Operational requirements and how to verify each one

This table compares the operating requirements for Passbolt, Bitwarden and Vaultwarden and shows how to verify each one before you commit. Treat the vendor minimums as starting points, since sizing must be confirmed for your expected user count and growth. The main takeaway is that the hardest operational work is backup, restore testing and upgrade planning, which fall to your team.

RequirementWhat to confirmHow to verify itWhere it usually fails
Hosting platformSupported operating systems, container runtime and Kubernetes options for the edition you chooseCheck the vendor hosting guide against your standard build, then test an install in a non-production networkTeams assume a Docker image is supported on their distribution without checking the vendor matrix
Hardware minimumsVendor stated minimums for CPU, RAM and storage; Bitwarden lists 2 GB RAM and 12 GB storage as minimum and 4 GB and 25 GB as recommendedLoad test with your expected user count and item volume, then compare memory and disk growth over a monthMinimums are used as sizing, so the server is slow or the database fills up after onboarding
Database and runtimeSupported databases and required versions, such as Bitwarden's default MSSQL Express image with a 10 GB limit and Vaultwarden's SQLite defaultConfirm the database engine, version and size limit in writing, then document how you will monitor growthDefault embedded databases hit size limits or lack the backup tooling your standard requires
Release cadence and upgradesRelease frequency for the chosen edition and the documented upgrade path, including database migrationsRun an upgrade in staging from the prior release, record the steps and time it, and confirm rollbackUpgrades are deferred for months, then a large jump breaks clients or plugins
Backup and restoreBackup scope covering the database and file attachments, plus encryption and retention of backup copiesRestore to a separate host on a schedule, log success, and confirm users can log in and decrypt itemsBackups exist but restores were never tested, or only the database is captured without attachments
High availabilityWhether the edition supports clustering or only active-passive recovery, and the expected recovery approachSimulate loss of the primary node and measure time to restore service, documenting the resultSingle container on one host is assumed to be highly available
Monitoring and loggingHealth checks, certificate expiry, disk and database alerts, and the activity log export available in your editionConfirm alerts fire in a test, and that audit events reach your SIEM in the format you needActivity logs stay on the server and are not forwarded, or are not retained long enough for review
Vendor support scopeWhat the vendor supports for the open-source edition versus paid editions, and who answers for bugsAsk for the support policy in writing, including data loss responsibility and escalation pathCommunity edition issues are routed to a partner or internal team with no agreed response path
Vaultwarden maintainer disclaimerMaintainers state they cannot be held liable for data loss and highly recommend regular backups of files and the databaseTreat the disclaimer as a design requirement: schedule backups, keep off-host copies and test restoresTeams rely on the project as a managed service without a backup owner or contract

Importing from your current tool without losing history

Plan the import as a data migration with known losses, not a copy. Passbolt's import documentation lists CSV imports from LastPass, 1Password, Dashlane, NordPass, Bitwarden, Firefox, Chrome, Brave, Edge and Safari, plus CSV and KDBX for KeePass and KDBX for Keeper, and those lists apply to the Community, Pro and Cloud editions. Confirm the exact source formats and whether your current tool's export includes shared folders, item history, custom fields and attachments, because a plain CSV usually flattens sharing. Expect that attachments, member invitations, enterprise policies and SSO settings will not move with the items in most migrations. For a Bitwarden cloud move, the documented path exports the organization's data, downloads a license tied to the installation ID, creates the self-hosted account with the same email and imports the data, and then requires attachments, member invitations, enterprise policies and SSO to be redone. Put those rebuilds on the project plan as named tasks with owners.

Run a test import before the real one. Choose a sample that includes at least one shared folder, one item shared with a group, one item with a custom field, one service account and one item with an attachment, then import it into a non-production instance. Check where each item lands: folder or collection names, group permissions, and who can see each item after import. Passbolt's export documentation says that since version 5.10 cleartext CSV exports are disabled by default unless an administrator re-enables them in the export policies, so confirm how your source export file will be created and stored. When the test passes, delete the source export file and any copies, such as downloads or ticket attachments, and record the deletion in the migration log. A cleartext export left on a workstation is the most common way a migration leaks every credential it was meant to protect.

Questions buyers ask before choosing a business password manager

What does a proof of concept for a business password manager cost, and who runs it?

The cost of a proof of concept is mostly staff time plus a test server, and it is paid by whoever runs it. Your team pays its own administrators and security staff for time spent on the test, and you pay for any test infrastructure. The open-source editions have no license fee for the Community tier of Passbolt or for Vaultwarden, but a self-hosted Bitwarden installation needs a license file for paid features, so check that before you test. Ask any partner for a fixed-scope written quote that lists the test users, the systems to connect, the import sources and the success criteria. A quote should separate one-time work (design, install, import, testing) from recurring work (upgrades, backups, monitoring and support).

How long do a proof of concept and a migration take for a password manager?

No duration is supplied for this work, so confirm timing in writing with any vendor or partner. The main drivers are the number of users and shared folders, whether the company directory must sync users and groups, the volume and cleanliness of the data you import from your current tool, and how many approvals your security and compliance teams require before go-live. Each of these can add weeks or months, depending on your organization. Ask for a plan that names the approvers and the test users early, because approval queues are often the longest step.

Can an internal IT team run a business password manager without outside help?

Yes, many internal teams can run one, provided they have people who can operate Linux servers, containers, database backups and reverse proxies, and who can own the vault after go-live. Passbolt publishes installation paths for several Linux distributions, Docker, a Kubernetes Helm chart and Ansible, and Vaultwarden recommends installing from its container images behind a reverse proxy with HTTPS. The harder parts are usually not the installation. They are the directory integration, the sharing model, the recovery process when a user loses access, and the upgrade routine. Decide who will perform each task before you start, and whether you want outside help for the first rollout, ongoing support, or both.

Which password manager features need a paid edition?

The answer depends on the product, so check the current edition table before you commit. For Passbolt, the pricing comparison lists these as Pro features not in the Community Edition: LDAP user and group provisioning from AD or OpenLDAP, account recovery, SSO with Microsoft, Google, OpenID and AD FS, MFA policies, syslog activity logs, tags, passphrase and password policies, a password expiry policy and SCIM. For self-hosted Bitwarden, the main server code is AGPL 3.0, but code in the bitwarden_license directory, including the SSO integration modules, needs a paid subscription for production use, and a license file tied to your installation ID is required. Vaultwarden is free software, but confirm which features your version supports for your use case.

Is Vaultwarden suitable for a business with compliance obligations?

Vaultwarden can be evaluated for a business, but its own documentation does not position it as an enterprise product. The README states that the project is not associated with Bitwarden, Inc., that one active maintainer is employed by Bitwarden and contributes on their own time, and that the maintainers focus on individuals, families and small organizations. It also tells users to report bugs to the Vaultwarden project rather than official Bitwarden support, and says maintainers cannot be held liable for data loss. For a regulated business, you would need to confirm that its feature set, logging, SSO and support model meet your obligations, and you would need your own backup and support arrangements. Consider Passbolt or Bitwarden when those needs are central.

What does the work need from our side before it starts?

The work needs a short list of items from your organization before the first day. Typically this includes directory administrator access for read-only user and group sync, a test tenant or test directory so you can try SSO and sync without touching production users, and a backup plan that covers both the database and the file store. You also need named owners for recovery, meaning people who approve account recovery and who hold any break-glass access, plus an owner for each shared folder. Ask the partner to write these prerequisites into the scope so that delays are visible early.

What should we check first in an import from our current password manager?

Start by confirming that your current tool and the target edition both support the import path, because the supported sources differ by product. Passbolt's import documentation lists CSV imports from tools such as LastPass, 1Password, Dashlane, Bitwarden and browsers, plus KDBX for KeePass, for its Community, Pro and Cloud editions. Then check how your export is handled: since Passbolt 5.10, cleartext CSV exports are disabled by default, so plan for encrypted exports or an administrator policy change. Import a sample of records first, and confirm that shared items, folders, attachments and notes arrive correctly before importing the full set.

How DeployOpen scopes and delivers a password manager selection and implementation

DeployOpen works on business password manager requirements as a written, fixed-scope engagement inside your own infrastructure. We turn your requirements into a platform choice among Passbolt, Bitwarden and Vaultwarden, then plan, implement, document and hand over the vault you select.

How we scope

  • We document your encryption, sharing, recovery, directory sync and audit requirements before comparing platforms.
  • We confirm which features need a paid edition or license file for your team size and sector.
  • The written scope fixes deliverables, timelines and responsibilities before any build work starts.

How we build

  • We deploy the chosen server on your cloud account, data center or air-gapped network with HTTPS and backups.
  • We configure groups, collections, SSO, directory sync and import from your current tool.
  • We test import results, sharing permissions, recovery paths and audit log output against the agreed requirements.

How we hand over

  • You receive installation, configuration and runbook documentation for administrators and help desk staff.
  • We document the offboarding, recovery and backup procedures your team will run after go-live.
  • We provide evidence records that map configured controls to your policy and assessment requirements.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • We can plan version upgrades and backup restore tests for the server you run.
  • Support scope, response expectations and responsibilities are agreed in writing with your team.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.