Why a self-hosted password manager for financial services needs more than a team vault
For a financial services firm, the question is not whether shared trading, payment and admin credentials can live in a self-hosted vault, but whether the vault can show examiners who used each credential, when, and who could recover it if a person left or lost access. On the strongest sharing and logging controls in the supplied comparison, Passbolt is the option to evaluate first, because it encrypts each secret per user with OpenPGP and lists syslog activity logs, account recovery, MFA policies and SCIM among its Pro features. Bitwarden or Vaultwarden can fit narrower or lower-stakes cases, but only after you confirm which features your chosen edition actually includes, since paid features in Bitwarden depend on a license tied to the installation.
Treat the vault as one control among several, not as the evidence store for your whole access model. The records examiners tend to ask for, such as the register of ICT arrangements under DORA or the access control and monitoring expectations in the FTC Safeguards Rule, come from several systems together: the directory, the single sign-on provider, the vault's own logs and the target systems. Before you select a product, confirm three things with the vendor: which activity events reach your log pipeline, whether recovery requires a second approver, and whether the export settings can be locked so that cleartext copies cannot leave the vault.
Where you need to control, record and approve live sessions into servers, databases or payment platforms, a password manager stops being enough and a privileged access management tool is the better fit. A vault can hand a person a password, but it does not usually broker the session, record keystrokes or require approval before the login happens. Decide early which accounts are simply stored and rotated in the vault and which must pass through a PAM layer, and document that boundary in your access policy so the examiner sees a deliberate design rather than a gap.
Which financial rules shape the password manager build
This table maps the financial rules most likely to reach a shared-credential vault to concrete build decisions such as MFA, activity logs, sharing scope, offboarding and support contract terms. Read each row against your entity type, since the FTC Safeguards Rule, PCI DSS, DORA, Swift CSCF and SEC expectations apply to different organizations, and confirm applicability with counsel before scoping.
| Rule or framework | Who it typically reaches | What it asks for | Build decision for the vault |
|---|---|---|---|
| FTC Safeguards Rule, 16 CFR 314.4(c) | Non-bank financial institutions under FTC jurisdiction | MFA for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing; monitoring and logging of authorized user activity | Enforce MFA on vault login for every user, document any written exception, and export per-user activity logs to your monitoring platform |
| PCI DSS v4.0.1, CDE scope | Merchants, processors, acquirers, issuers and service providers that store, process or transmit cardholder data or could affect its security | Controls over credentials that protect the cardholder data environment, including access restriction and authentication for administrative access | Keep CDE admin and service credentials in a dedicated vault folder with restricted sharing, and confirm with your QSA which vault records count as evidence |
| DORA Article 28(3) and 28(8) | EU financial entities in scope of DORA, including credit and payment institutions | A register of ICT contractual arrangements; documented, tested exit strategies for ICT services supporting critical or important functions | Record the self-hosted vault and its support contract in the register, and keep a tested export path (encrypted KDBX or documented data extraction) for exit |
| DORA Article 30(2) | EU financial entities contracting ICT services from a provider | Contracts stating where services are provided and data processed, advance notice of changes, and data return on insolvency or termination | Write hosting location, subprocessors and data return into the support agreement, and confirm the vendor will provide the vault database and attachments on termination |
| Swift Customer Security Controls Framework v2026 | Swift users, including banks and payment institutions with Swift connectivity | Independent assessment of controls and annual attestation in KYC-SA; 26 mandatory and 6 advisory controls | Restrict vault access to Swift operator and admin credentials to named individuals, and keep sharing and access logs available for the independent assessor |
| SEC ITGC, access to programs and data (Release 33-8810) | Public companies with internal control over financial reporting under SOX Section 404 | Assessed controls over access to programs and data, including authorization, provisioning and removal of access | Tie vault group membership to an approved access request, remove access at offboarding, and retain change records for vault administrator actions |
| Sharing scope and offboarding | All financial entities using shared trading, payment or admin credentials | Access limited to need, removed promptly when roles change, and traceable to a named person | Share at the folder or group level only for approved roles, and run a documented offboarding checklist that revokes vault membership and rotates shared secrets the person held |
| Vendor support and recovery terms | Any regulated entity buying support for an open-source vault | Clear service responsibilities, incident handling, evidence of backup and tested recovery | Ask the partner for written backup and restore test records, support response scope and who holds administrator recovery keys |
Passbolt, Bitwarden or Vaultwarden: which fits which financial workload
The three tools differ less on headline features than on which capabilities sit in a free edition, how keys are held, and what a paid license requires in production. Financial teams should map each shared credential class to those differences before choosing, then test logging and recovery against examiner expectations.
Passbolt Community versus Pro gaps
Passbolt Community is free and self-hosted with unlimited users, but LDAP provisioning from AD or OpenLDAP, account recovery, SSO, MFA policies, syslog activity logs, SCIM, password expiry and passphrase policies sit in Pro. For a trading or payment admin vault, the syslog and MFA items decide whether activity can reach your SIEM and whether privileged logins meet your authentication rules. Confirm which features your target workload requires before modeling the Community edition.
Per-user OpenPGP key model
Passbolt encrypts each resource separately for every user with access, using that user's own OpenPGP key pair, and the server stores only ciphertext. This means a shared admin credential is readable only by listed members, and removing a person requires re-encryption rather than a server-side switch. Examiners will ask how keys are generated, escrowed and revoked when a staff member leaves, so document that procedure before go-live.
Cleartext export controls
Since Passbolt 5.10, cleartext CSV exports are disabled by default, and the export list offers encrypted KeePass KDBX formats unless an administrator re-enables CSV in the export policies. For financial firms, this is a data loss control: a single export of payment or trading credentials can leave the vault unprotected. Ask each vendor how exports are restricted, who may perform them, and whether those events are logged.
Bitwarden license boundary
Bitwarden server code outside the bitwarden_license directory is AGPL 3.0, while Commercial.Core and SSO modules fall under the Bitwarden License, which is source-available and not open source under the OSI definition. The license FAQ says production use of that code requires a paid subscription. Finance teams should record which modules they run, because a self-hosted deployment that depends on SSO or enterprise policies is a licensed deployment, not an open-source one.
Paid license tied to installation
Paid Bitwarden features 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. A standard self-hosted install also requires an installation ID and key from bitwarden.com/host. Plan for license renewal and region checks in your change process, and confirm with Bitwarden how a fully air-gapped deployment obtains and renews its license.
Vaultwarden as a lighter option
Vaultwarden is a community-maintained, lighter server compatible with Bitwarden clients, and it is often chosen for small teams that want a low resource footprint. It is not a substitute for the vendor-supported paths in a regulated setting, and its activity logging, sharing controls, recovery options and support terms vary from the other two. Before selecting it for shared payment or trading credentials, confirm its logging and sharing behavior against your examiner evidence list and your support contract.
Deployment patterns for regulated financial networks
This pattern fits institutions that must keep credential data inside facilities they operate and that already run directory services, syslog collectors and a SIEM on their own hardware. The vault server, its database and the reverse proxy sit on hosts in the institution's own network segments, usually with access limited to administrators and the vault's own service accounts. Passbolt runs on supported Linux distributions, Docker or Kubernetes, and Bitwarden publishes Docker-based installation guidance, so the platform team chooses the packaging that matches its change control.
- Vault and database placement: Keep the application, database and backups in the same controlled zone, with the database on a host that only the vault can reach.
- SSO and LDAP sync: Connect to internal Active Directory or OpenLDAP over an approved path. Passbolt documents LDAP provisioning as a Pro feature, and Bitwarden's Directory Connector is GPL-3.0 licensed.
- Syslog to the SIEM: Forward vault activity to a Wazuh or other collector inside the same zone. Confirm which events each edition emits, since Passbolt lists syslog activity logs as a Pro feature.
- Backup placement: Store encrypted backups in a second data center that the institution controls, and test restores on a schedule.
- Provider contract: Where support is bought from a vendor or partner, DORA Article 30(2) expects the contract to state where services are provided and data processed.
Confirm with the vendor and your auditors which log events and backup formats your evidence process accepts before go-live.
This pattern uses an account the institution owns or controls in a cloud provider, placed in the region the supervisor expects for its data. The vault runs in private subnets behind a load balancer, the database uses managed or self-run PostgreSQL or MariaDB with encryption at rest, and key material stays under the institution's control. Infrastructure is usually defined as code so that the same build can be rebuilt in another account for recovery.
- Vault and database placement: Pin the vault, database and backup buckets to one approved region, and deny resource creation elsewhere through organization policy.
- SSO and LDAP sync: Reach the corporate directory through a private link or VPN. Keycloak or another workforce identity provider can sit in the same account to broker SSO.
- Syslog to the SIEM: Ship logs from the vault host to a collector in the same region, then replicate only the required fields to a central SIEM if the group operates one.
- Backup placement: Keep backups in the home region with object lock or immutability enabled, and document who holds the keys.
- Bitwarden license file: Paid Bitwarden features need a license tied to the installation ID, and the installation's data region must match the cloud organization's region. Migrating between regions means repeating the export, license download and import steps, with attachments, invitations, policies and SSO redone.
Ask the provider which sub-processors touch the control plane and where support staff can access the environment.
This pattern places the vault inside a network zone that holds cardholder data or trading systems, so only the people who administer those systems can reach it. It applies where PCI DSS scope or trading controls require that credentials for payment or order-management systems stay within a defined boundary. The enclave has its own directory connection, its own logging path and tightly limited egress, so the vault cannot become a route into the protected systems.
- Vault and database placement: Run the vault and database inside the enclave, with inbound access only from administrator jump hosts and the browser clients that need it.
- SSO and LDAP sync: Use a read-only directory replica inside the enclave, not a live link to the corporate directory, and document the sync account's rights.
- Syslog to the SIEM: Send logs through a one-way or filtered forwarder to a SIEM in the enclave, and replicate summaries to the central monitoring platform.
- Backup placement: Keep backups inside the enclave or in a sibling enclave with the same controls, and restrict who can restore.
- Scope review: PCI DSS applies to any system that could affect the security of the cardholder data environment, so the assessor will decide whether the vault belongs in scope.
Confirm with your QSA or internal audit whether the vault is in scope before you design the network paths.
Rollout from credential inventory to examiner-ready evidence
This sequence moves a financial institution from an unmanaged set of shared trading, payment and admin credentials to a self-hosted vault that can show who had access, when, and how access was removed. Each phase ends with a named output that the next phase depends on, so examiner questions can be answered from records rather than reconstructed later.
Inventory and classify shared credentials
Start by listing every shared, service and break-glass credential across trading, payment, administrative and service accounts, including where each one is stored today (spreadsheets, sticky notes, browser profiles, scripts). Tag each entry with its owning business function, the systems it unlocks, whether it falls within cardholder data or other in-scope environments, and who must be able to use it. The output is a classified register that the compliance lead and system owners have reviewed and signed off. You know this step is done when every account in scope has one owner, one classification and one documented location.
Design folders, groups and sharing rules
Translate the register into a folder structure, a set of groups that match job roles and a sharing matrix that states who can view, use or manage each credential. Separate production trading access from test environments, and keep payment and admin vaults distinct so that a compromise or offboarding event in one area does not expose the others. Document the rule that every shared secret has at least two named managers. The output is an approved access design with a written matrix that auditors can compare against directory group membership. You know this step is done when the matrix can be tested against a sample of users without exceptions.
Pilot the vault and import from the current tool
Deploy the chosen product in a non-production environment, then import a limited pilot group of credentials from the current tool. Use encrypted import formats where the product supports them, and confirm the export policies on the source side so that no cleartext export files are left on workstations. Pilot users check that they can retrieve, use and share credentials through the browser extension, and that the import does not duplicate or drop entries. The output is a pilot report listing the imported counts, defects found and the decisions taken on each one. You know this step is done when the pilot group has run through a full working cycle and the source exports have been securely deleted under the agreed procedure.
Integrate SSO, MFA and directory groups
Connect the vault to the workforce identity provider so that sign-in uses single sign-on and multi-factor authentication, and so that group membership in the directory drives vault access. Confirm which capabilities are included in the edition you chose and which need a paid license, and check how the identity provider handles account disablement. Test that a disabled directory account loses vault access without manual steps in the vault. The output is a documented integration with a test record for MFA enforcement and group-driven provisioning. You know this step is done when a leaver test in the directory removes vault access as designed.
Enable activity logging and SIEM forwarding
Turn on activity logs in the vault, forward them to the institution's central log platform, and define the events that must be retained: sign-ins, credential views, sharing changes, exports and administrative changes. Confirm log retention and the fields each event contains with the vendor, and agree who reviews alerts and how often. Run a test event for each category and confirm it arrives in the SIEM with a usable timestamp and user identity. The output is a logging specification and a test log set kept with the change record. You know this step is done when every required event type has been seen in the central platform and the review owner has accepted the alert rules.
Test break-glass and offboarding procedures
Exercise the emergency access procedure while SSO is deliberately unavailable, record who opened the break-glass credential, and confirm that the alert fired and the credential was rotated afterward. Separately, run a scripted offboarding of a test user and confirm that the user's shared credentials are reassigned or rotated according to the register. Record the time and outcome of each step in the change file. The output is a tested runbook with evidence of each test. You know this step is done when both tests pass with records that a reviewer can follow without asking the operators what happened.
Hand over with runbooks and evidence pack
Deliver operating runbooks for backup and restore, upgrades, user onboarding, offboarding, sharing changes, log review and incident response for the vault. Assemble an evidence pack that maps the configuration to the institution's own control set, including the access design, test records, log samples and change approvals. Confirm which party supports the server, applies patches and restores backups, and record the escalation path in writing. The output is an accepted handover with named owners for each runbook. You know this step is done when the internal team can perform a restore and an offboarding without the implementation team present.
Evidence examiners and auditors ask for, and what produces it
This table maps the evidence a financial examiner, PCI assessor or Swift assessor is likely to request for a shared-credential vault to the Passbolt or Bitwarden component that produces it. Read the third column to see which records the firm must still keep as its own process evidence, since no vault generates those on its own.
| Evidence item | Produced by the vault | Still a firm-owned process record |
|---|---|---|
| User-to-credential access list | Passbolt sharing and group membership views, and Bitwarden collection and group membership reports, exported for the review date | Named business owner who approves each access grant for trading, payment and admin accounts |
| Sharing change history | Activity logs in Passbolt Pro (syslog export) and Bitwarden event logs for share, unshare and permission changes; confirm retention in your edition | Retention period and who reviews the logs each month |
| MFA enforcement settings | Passbolt Pro MFA policy and SSO configuration; Bitwarden two-step login policy settings, captured as screenshots or configuration exports | Decision record that explains any exception and who approved it, as the FTC Safeguards Rule allows only a written equivalent control |
| Syslog or SIEM feed of vault activity | Passbolt Pro syslog activity logs forwarded to the firm's log platform; confirm the Bitwarden event export path for your deployment | Log forwarding test results and alert rules for bulk export or admin changes |
| Recovery procedure test records | Account recovery configuration in Passbolt Pro and Bitwarden account recovery settings, with the admin action logged | Dated test record showing a recovery was walked through, the tester and the outcome |
| Offboarding tickets | Directory sync removal (LDAP or SCIM) and the user's access removal events in the vault log | Ticket from HR or IT showing the request, the approval and the time of removal |
| Backup and restore test results | Database and attachment backup of the self-hosted server, plus a restored test instance if built | Restore test report with signed sign-off, as no vault product produces this |
| DORA register entry and exit plan for the vault provider | Not produced by the vault; the deployment record (hosting location, versions, data flows) feeds the entry | Register of information entry, contract clauses on data location and return, and a tested exit plan under DORA Articles 28 and 30 |
| PCI DSS or Swift attestation inputs | Evidence of access control, MFA and logging settings from the vault that the assessor can sample | Attestation itself comes from a Qualified Security Assessor or the Swift assessment; DeployOpen prepares inputs but does not issue attestations |
Where a password manager stops and PAM starts
A password manager stores and shares secrets, while privileged access management (PAM) brokers, approves and records live sessions to servers, databases and Kubernetes clusters. The distinction matters in financial services because examiners ask who used a privileged account, what they did during the session and whether elevation was approved and time-limited. A vault can show who checked out a shared admin password and when, but it does not see what the administrator typed once the session opened. Before you finalize the design, map each privileged account to one of two patterns: a credential the user receives and types into a system, or a session the user is routed through a gateway that authenticates them, records the activity and expires the access.
Expect the PAM pattern to be the answer where the requirement is session recording, command logging, just-in-time elevation or approval workflows on production trading, payment or database administration. Those controls belong to a PAM layer, and the open-source options in the privileged access management content group cover Teleport, JumpServer and Apache Guacamole with different protocol and session-recording coverage. Confirm each candidate's recording format, retention, replay and protocol support against your own systems, because the vault does not supply any of these by itself. Also check how the PAM tool authenticates users, since it should reuse the same identity provider and MFA policy as the vault.
Keep the vault as the place for shared secrets that cannot be brokered: vendor-supplied logins to appliances that offer no gateway, break-glass credentials that must work when the PAM service is down, and service account secrets that a support team needs to hand over during an incident. In those cases, the vault's checkout logs, sharing groups and rotation after each use provide the evidence. Record which accounts go to PAM and which stay in the vault in your access inventory, so that an examiner can see a single rule set rather than two overlapping systems with unclear ownership.
How much does a self-hosted financial password manager cost and what does it need from us?
What does a self-hosted password manager cost for a financial firm?
The cost is split across four buckets: software licensing, infrastructure, implementation services and internal staff time, and only the first is typically a line item for the vendor. The community editions of Passbolt and Vaultwarden are free to self-host, while Bitwarden paid features require a license file. Passbolt publishes Pro at $4.9 per user per month billed annually with a 10-user minimum, according to its pricing page, and that recurs for as long as you keep the subscription. Infrastructure, backup, monitoring and the implementation work are one-time or recurring costs that depend on your environment. Ask every bidder for a written quote that separates these lines.
Which costs recur after go-live and which are one-time?
Recurring costs include per-user subscriptions where a paid edition is required, support contracts, hosting and backup storage, patching windows, and the staff time to review access and rotate shared credentials. One-time costs include architecture and hardening, identity integration, importing existing credentials from spreadsheets and legacy vaults, policy design, and user training. Vendor subscriptions are usually the easiest line to compare, while the operational work tends to be what surprises finance teams. Ask for the recurring and one-time split over the contract term, not just a first-year total.
What makes the effort on a financial password manager go up?
Effort rises with the features you must enable, the number of directories you must synchronize, and the volume of shared accounts. Passbolt lists LDAP provisioning, account recovery, SSO, MFA policies, syslog activity logs, password expiry and SCIM among Pro features, so a firm that needs these must budget for that edition from the start. Bitwarden's self-hosted paid features also depend on a license file tied to the installation ID and region. Each shared trading, payment or admin account needs an owner, a group design and a rotation procedure, which multiplies quickly across desks and entities. Mapping these before procurement usually determines whether the project is a few weeks or a much longer program, so ask bidders to size it against your actual inventory.
Can our internal staff run a self-hosted password manager?
Yes, if you have people who can operate a containerized or Linux-based service, manage TLS, databases and backups, and respond to security patches on a predictable schedule. Passbolt supports Docker, Kubernetes via Helm, and several Linux distributions, and Bitwarden requires Docker Engine 26 or later with a bundled MSSQL Express image that has a 10 GB database size limit. The harder part is the ongoing governance: someone must own access reviews, offboarding, recovery procedures and the audit trail. Many firms keep governance internal and bring in an implementation partner for the build, hardening and handover, which DeployOpen offers under a written, fixed-scope agreement. Confirm your staffing model against the operational tasks before committing.
How long does it take to reach a pilot?
The time to a pilot depends on how quickly your team can agree the requirements, provision the server and identity connections, and select a representative set of shared accounts for the first wave. The inputs that most often delay a pilot are directory design, approval of the encryption and key recovery model, change windows for the production network, and the availability of a named business owner for each credential group. Requirements that touch regulated functions, such as payment or trading administration, typically need extra review from risk and compliance. Ask any partner for a written plan with milestones and dependencies rather than a single duration, and check that the pilot scope matches the production scope you intend to scale.
What evidence must our firm supply before implementation starts?
The firm must supply the material that examiners and auditors will ask to see, and the implementation can only prepare controls around what you define. Typical inputs include a credential inventory grouped by system, a list of who must access each group, your authentication policy including multi-factor requirements, your logging retention rules and the owners of each shared account. For financial entities, the FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system and monitoring of authorized user activity, so your vault configuration must be reconciled with those duties. Confirm with your examiners and legal team which records and approvals they expect, since DeployOpen prepares systems and evidence but does not issue audit opinions or certifications.
Which quote items should we ask for to compare bidders fairly?
Ask for a quote that lists each cost component separately: software or subscription, infrastructure assumptions, backup design, identity and directory integration, import work, hardening, documentation, training, and post-go-live support. Request the assumptions behind each line, including user count, number of shared accounts, environment type and required edition features. Confirm what happens at renewal, how exit and data return are handled, and whether the proposal includes the written scope and acceptance criteria. Comparing quotes is only meaningful when every bidder has been given the same inventory and requirements, so issue one written scope to all of them.
Questions to ask an implementation partner before you sign
Start by asking how the partner maps evidence to the vault. Ask which records the vault will produce for each regime in scope: the FTC Safeguards Rule requirements for multi-factor authentication and activity logging under 16 CFR 314.4, the PCI DSS requirements if cardholder data environment credentials are stored, the DORA register and exit documentation if the vault is an ICT service, and the access-control evidence that SEC guidance links to IT general controls. A credible partner will name the specific records (sharing history, user lists, export logs, policy settings) and state plainly that DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications. Any partner who promises a certification outcome is making a claim it cannot back.
Next, ask where the contract places data and how an exit works. DORA Article 30(2) expects an ICT services contract to state where services are provided and data processed, with advance notice of changes, and to cover data return on termination. Ask the partner to put the hosting region, the backup location, the administrator locations and the notice period for changes into the written scope. Then ask for the exit plan: how the vault is exported (confirm whether your edition supports KDBX or encrypted export and whether cleartext CSV is disabled by policy in your Passbolt version), who holds the server keys, and how the exit is tested.
Ask how the partner handles the Bitwarden license tied to a region. Paid features need a license file downloaded from the cloud web app and bound to the installation ID, and that installation's data region must match the cloud organization's region. Ask who holds the cloud login used to download and renew the license, who performs renewals, and what happens to paid features if the license lapses. Also ask how the partner treats the Bitwarden License for files in the bitwarden_license directory, since production use requires a paid subscription. Ask for the license inventory in writing before go-live. Finally, ask how break-glass accounts and recovery are tested: which accounts are exercised, how often, who witnesses the test, and whether SSO outage scenarios are rehearsed.
How DeployOpen scopes and supports this in a financial environment
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a financial firm, that means the vault, its directory integration, its logs and its backups stay under the institution's control, and the written scope defines what examiners will be shown.
How we scope
- Inventory which shared trading, payment and admin credentials go into the vault and which belong in privileged access tooling
- Agree the edition, hosting location, directory source and SSO design in writing before any build work starts
- Define the activity log export, retention and recovery procedures the examination file will need to reference
How we build
- Deploy the chosen platform in the client's infrastructure with hardened hosts, HTTPS and database settings agreed in scope
- Configure group-based sharing, MFA policies and directory provisioning to match the approved access model
- Test import, sharing, revocation, recovery and log forwarding against written acceptance criteria before go-live
How we hand over
- Deliver runbooks for onboarding, offboarding, shared account rotation and break-glass use, mapped to the agreed policies
- Document backup, restore and upgrade procedures, and record which evidence each control produces for review
- Train named administrators so the institution can operate the vault without depending on the implementation team
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build
- Retest the deployment after platform upgrades or changes to the directory, network or hosting environment
- Provide support boundaries in writing so compliance, security and operations teams know who answers what
