Business password manager RFP questions

Under Passbolt's documented design, the server only receives and stores ciphertext, and decryption happens on the user's device. Ask the vendor to confirm that statement for the exact edition and version you plan to run, and to show where the document describes it. Passbolt's documentation says the browser extension or mobile app encrypts and decrypts locally, never on the server. Ask who can read the database and backups, since ciphertext is only as safe as the key handling around it. Ask for the same answer in writing for each client you will deploy.

Passbolt uses end-to-end encryption based on the OpenPGP standard, so each user has a key pair. When a user gains access to a shared resource, they receive their own copy of the secret, encrypted with their public key. Ask who generates the key pair, where the private key is stored, and whether it is protected by a passphrase the server never sees. Ask what happens to access to shared items when a key is lost or a user leaves, because that decides how you handle recovery and offboarding.

Ask this separately from password encryption, because many products protect the secret field but leave metadata readable to the server. Passbolt's documentation says metadata such as names, URLs and descriptions is encrypted only with the v5 format and only when the organization enables metadata encryption. Confirm which format and setting apply to your deployment, and whether a server administrator can still see who shares which item with whom. Your answer will matter for regulated data, since a readable URL can reveal the system a credential belongs to.

The client is where encryption and decryption should happen, so ask the vendor to describe each step. Passbolt states that its browser extension and mobile app encrypt and decrypt locally and that the browser extension is cryptographically signed. Ask how the signature is verified, how updates reach users in an offline or restricted network, and what the client caches on disk. Also ask whether a compromised client could export decrypted data, and what logging exists for exports.

Treat "zero knowledge" as an unfinished answer until the vendor defines it. Ask which data the server can read, which it cannot, and in which edition and version. The claim should cover secret values, metadata, search indexes, attachments, audit logs and administrator actions, and each one should be named. If the answer is a marketing phrase with no list behind it, record it as a risk and ask for the technical documentation before you shortlist the product.

Ask the vendor to show the encryption model for each edition you might buy, not just the top tier. Passbolt lists a free self-hosted Community Edition and places features such as account recovery, SSO, SCIM and MFA policies in Pro, so confirm that the core OpenPGP model and metadata options match across editions. Ask which controls that affect what the server can see, such as export policies or metadata encryption, depend on a paid license or an administrator setting.

Ask for the source code, the open-source license, and the test or review evidence available for the design. Passbolt's API server repository is licensed under AGPL-3.0, which lets your team read the server side of the code. Ask the vendor for its security documentation and any third-party review it can share under NDA. Your implementation partner can then check how the server, database and backups are configured, but an independent auditor, not DeployOpen, would issue any assurance report on the design.

Start by asking for a written list of supported identity providers for the exact edition you are buying, not the product in general. Passbolt's comparison lists SSO with Microsoft, Google, OpenID and AD FS as Pro features not included in Community Edition, so confirm whether Okta and any other provider you use are covered by the same module or by a generic OpenID Connect connection. Ask the vendor to demonstrate login with your identity provider in a test tenant, including what happens when a user has no matching account. Bitwarden keeps its SSO integration modules under the Bitwarden License, which means production use needs a paid subscription, so ask which SSO connectors sit in that tier. For Vaultwarden, SSO through OpenID Connect arrived in version 1.35.0, so ask for the tested identity providers and the known gaps in the release you plan to run.

SCIM and LDAP provisioning are often the features that move a password manager from a free edition to a paid one, so ask for the edition-by-edition feature table in writing. Passbolt lists LDAP user and group provisioning from AD or OpenLDAP and SCIM as Pro features that are not in Community Edition. Bitwarden offers Directory Connector, which syncs users from AD, LDAP, Azure, Google Workspace or Okta, but the connector is a separate GPL-3.0 tool, so ask whether the sync runs on your servers, which account it uses and how often it runs. Vaultwarden documents Directory Connector support, which lets you test sync without a commercial license, but it is maintained separately from Bitwarden, so ask who fixes sync defects and on what timeline. Price the license for every year you run it, not only the first.

Map directory groups to vault structures in a written access model before the first import, because group changes later can silently widen access. Ask the vendor to show how a group becomes a team, a collection or a folder with a specific role, such as read only, manage or owner. Passbolt shares each resource by encrypting it to each user who has access, so a group change must re-encrypt or re-share entries, and you should ask how long that takes for your largest group. In Bitwarden and Vaultwarden, organizations, collections, member roles and groups are the building blocks, so confirm how nested directory groups are flattened. Ask for a test with a sample group that has an owner, a contractor and a service account, and check that the result matches your access matrix.

The answer should describe the offboarding sequence step by step: directory disablement, SSO session end, provisioning deactivation in the vault, and removal of shared access. Ask how long each step takes in your configuration, and whether deactivation revokes access to shared credentials immediately or only at the next sync. Also ask what happens to credentials the user created, who receives ownership and whether the user's copies of shared entries are removed, since in an encrypted sharing model a previously decrypted copy may remain on a device until the session or local copy is cleared. Request the audit log entry produced by a removal test, because examiners and internal auditors will ask for it. Confirm that rotating shared passwords after an offboarding event is part of your procedure, not something the tool does for you.

A good answer names a local administrator path that works without the identity provider and explains how its use is controlled. Ask the vendor to show the exact login route when SSO is unavailable, whether a local password or passkey is required, and how that account is limited to emergency use. Vaultwarden's README describes two-factor options and emergency access, but you should confirm how these behave when the SSO provider is unreachable. For Passbolt, ask how account recovery and MFA policies interact with an identity provider outage. Document who holds the break-glass credentials, where they are stored, how each use is logged and alerted, and how the account is rotated after use. Test this path on a schedule, because an untested emergency account is usually discovered broken during an actual outage.

Treat SSO as a paid feature until the vendor's written feature table shows it in the edition you will run, because marketing pages often describe it as built in. Passbolt lists SSO with Microsoft, Google, OpenID and AD FS among Pro features, so it is not part of Community Edition. Bitwarden states that the SSO integration modules are under the Bitwarden License, and production use of that code requires a paid subscription. Vaultwarden includes OpenID Connect SSO in its open-source code, but support for it comes from a community project with no contractual support, so ask for your own test results. Ask for the quoted line item that covers SSO, the number of users it covers and whether it recurs annually. Red flags include a vendor who cannot name the module or license file that contains the feature.

Ask who owns the sync job, its credentials, its monitoring and its upgrade path after the first rollout. Sync usually runs under a service account in the directory with read access to users and groups, so confirm the minimum permissions, where the account password is stored and how it is rotated. Ask how failed syncs are reported and whether an alert reaches your operations team. Bitwarden's Directory Connector is a separate application, and Vaultwarden's sync depends on Bitwarden's client API compatibility, so ask who patches each component when either changes. DeployOpen can plan, implement, integrate, harden, back up, upgrade and support self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer. Confirm which of these tasks your partner or vendor will carry in writing before work starts.

Ask for a written list of logged event types, including item views, item edits, sharing changes, member role changes, failed logins, MFA changes, policy changes and admin actions, with the user, timestamp and object recorded for each. Passbolt lists syslog activity logs as a Pro feature rather than Community Edition, and Vaultwarden implements event logs for organizations, so confirm the exact events each edition writes to its log. Ask for a sample export file so you can see the fields before you rely on it.

Ask whether the product forwards events in real time over syslog to your collector, which transport and format it uses, and whether the feed can be TLS-protected. Logs that exist only in the admin interface, with no export path, make it hard to show a reviewer continuous monitoring of activity in systems that hold ePHI or customer information. Confirm this with the vendor for the specific edition you plan to run, and test the feed end to end in a staging environment before go-live.

Ask where logs are stored, whether the retention period is configurable, and whether an administrator can edit or delete entries. In a self-hosted deployment, retention depends on your database and your backup design, so you own both the duration and the protection of the records. Ask whether logs can be made append-only or copied to a separate store that the vault administrators cannot alter. Your retention rule should follow your own compliance schedule, which the vendor cannot set for you.

Ask whether MFA can be required for every user, for administrators only, or by group, and whether the policy blocks logins that lack a second factor. Passbolt lists MFA policies as a Pro feature, and Vaultwarden supports two-factor login with an authenticator app, email, FIDO2 WebAuthn, YubiKey and Duo. The FTC Safeguards Rule at 16 CFR 314.4 expects multi-factor authentication for any individual accessing an information system, so ask how the product enforces that for every account, including the break-glass and service accounts that sit outside SSO.

Ask for a report of every account, its owner, its role and its group memberships, and confirm that no two people share a login. The HIPAA Security Rule at 45 CFR 164.312 requires unique user identification, access control and person or entity authentication for systems holding ePHI. Evidence usually includes the user roster tied to your directory, the role and collection assignments, the policy configuration and the log entries showing who accessed which shared item. Shared accounts such as vendor logins need a documented exception with an owner.

The vendor or implementation partner can prepare configuration exports, policy settings, screenshots, log samples, change records and a control-to-evidence mapping for your environment. Auditors and assessors decide whether those controls meet the requirement and issue any opinion or report. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Ask the vendor to state in writing which evidence it will provide and which parts remain your responsibility.

Confirm that syslog export works and that a sample log can be produced for each in-scope event type. Confirm that MFA policies apply to administrators and users, including break-glass accounts, and that the policy settings can be exported. Check that the account roster matches your directory, that the retention period and log storage are documented, and that a restore test has been run. Ask the partner to write the evidence list and the owner for each item, so the review does not depend on a single administrator's memory.