Self-hosted password manager for healthcare

Why a self-hosted password manager for healthcare starts with shared clinical accounts

Shared clinical logins are the first problem a healthcare password manager has to solve. In most health systems and clinics, the same account for an EHR workstation, a medical device console, an imaging workstation or a vendor portal is passed between nurses, technicians and contractors, and each rotation of staff makes it harder to know who used it last. A self-hosted vault such as Passbolt, Bitwarden or Vaultwarden gives each person a named login to the vault and lets the organization grant access to a shared credential without writing the password on a sticky note or in a spreadsheet. The choice of product should follow from that goal, and the rules that shape it come from the HIPAA Security Rule at 45 CFR 164.312, which requires unique user identification, audit controls that record and examine activity in systems containing ePHI, and person or entity authentication. The short answer for most healthcare teams is to compare Passbolt, Bitwarden and Vaultwarden against those three requirements first. Passbolt encrypts each shared resource with OpenPGP keys so that the server stores only ciphertext, and its audit and recovery features sit behind the Pro edition, so the licensing check belongs in the first week. Bitwarden's paid organization features need a license file tied to the installation, and its server code is not wholly open source. Vaultwarden is a community implementation with a lighter footprint. In every case, the vault database, its backups and the server hosting the vault should stay on hospital-controlled servers under the organization's own access controls, so that the people who can administer the vault are the same people accountable for the ePHI around it. HIPAA has no certification for this. HHS states that no Security Rule standard requires an entity to certify compliance, so an assessor or an OCR investigator will not accept a badge as proof. What the organization can show is evidence: a unique named account for each clinician, a sharing model with recorded membership changes, logs of who viewed or changed a shared credential, documented offboarding, and a written risk analysis that explains why each shared account exists. Confirm with your privacy and security officers which of these artifacts they already keep, because the vault should produce them rather than create a new reporting burden.

Which HIPAA password and access requirements the vault must support

This table maps the HIPAA technical safeguards and the business associate terms that touch a shared vault to concrete build decisions for a hospital or clinic. Read each row as a requirement, what it means for how the vault is configured and operated, and what an assessor will ask to see. The main takeaway is that the Security Rule does not name a product, so the vault must produce unique accounts, controlled sharing, reviewable logs and encrypted transport that you can show on request.

Requirement	What it asks for	What it means for the vault build
Unique user identification (164.312(a)(2)(i), required)	Assign a unique name or number to each user and track activity to that identity	No shared clinician logins in the vault. Each clinician gets a named account, and shared clinical or vendor accounts are held as group-shared items with individual access records.
Access control (164.312(a)(1))	Allow access only to people or software granted rights to ePHI systems	Use groups tied to care teams or roles so access follows need to know. Confirm which features (such as SSO, LDAP or SCIM provisioning) need a paid edition in Passbolt or Bitwarden before you rely on them.
Emergency access procedure (164.312(a)(2)(ii), required)	Establish how ePHI and systems are reached during an emergency	Plan a break-glass path for vault recovery and admin access that works when SSO or the primary server is down. Test it and log each use.
Automatic logoff (164.312(a)(2)(iii), addressable)	End sessions after a period of inactivity, or document an equivalent measure	Set vault and browser extension lock timeouts in policy. Record the chosen value and the reason, since addressable means you must decide and document.
Encryption and decryption (164.312(a)(2)(iv), addressable)	Encrypt ePHI where you determine it is reasonable and appropriate	Passbolt encrypts secrets client-side with OpenPGP and the server stores ciphertext. Bitwarden server stores encrypted vault data. Document what the server can see, including metadata, for each option.
Audit controls (164.312(b))	Record and examine activity in systems that contain ePHI	Enable activity logs and forward them to your central logging system. Set a review cadence and keep evidence of who reviewed access events. Passbolt activity logs to syslog are a Pro feature.
Person or entity authentication (164.312(d))	Verify that a person or entity seeking access is who they claim to be	Require strong login for the vault, such as MFA on the vault or upstream SSO. Passbolt lists MFA policies as a Pro feature, so confirm the MFA design for your edition.
Transmission security (164.312(e)(1))	Guard against unauthorized access to ePHI sent over networks	Serve the vault only over HTTPS with certificates from your internal CA. Restrict database and SMTP traffic to internal networks and document the configuration.
Business associate terms (164.314(a)(2)(i))	Require a vendor that handles ePHI to comply, flow terms to subcontractors and report incidents	If a vendor hosts, supports or can access the vault, the contract must contain these terms. Ask partners and hosting providers to confirm them in writing before any access to the vault.

Passbolt, self-hosted Bitwarden or Vaultwarden: which fits a clinical environment

Passbolt uses end-to-end encryption based on the OpenPGP standard. Each user holds a key pair, and each user who needs a shared resource receives their own copy of it encrypted with their public key. Encryption and decryption happen in the browser extension or mobile app, not on the server, so the hospital's server stores ciphertext. Passbolt's documentation says metadata such as names, URLs and descriptions is encrypted only in the v5 format and when the organization enables metadata encryption, so confirm that setting before loading clinical account names.

Community edition: free for self-hosting with unlimited users, but LDAP provisioning, account recovery, SSO, MFA policies, syslog activity logs, tags, password policies and SCIM are Pro features.
Pro edition: the listed price is per user per month billed annually with a 10-user minimum, per Passbolt's pricing page. Confirm the current figure in writing.
Licensing: the API server, the Docker repository and the Helm chart repository are licensed under AGPL-3.0.
Exports: since Passbolt 5.10, cleartext CSV exports are disabled by default and an administrator must allow them again.
Hosting: the documented options include Docker, a Kubernetes Helm chart and Ansible, with a virtual appliance for Pro only.

Before choosing, confirm with Passbolt which features your audit and sign-in model require, because most of the clinical controls sit in the Pro feature list.",

The main Bitwarden server code is licensed under AGPL-3.0. Files in the bitwarden_license directory, including Commercial.Core and the SSO integration modules, fall under the Bitwarden License, which Bitwarden describes as source-available and not open source under the OSI definition. Bitwarden's license FAQ says that production use of that code requires a paid subscription, so a hospital that needs SSO or other enterprise features must budget for a subscription even though the core server is open.

License file: paid features need a license downloaded from the cloud web app and tied to the installation ID, and the data region must match the cloud organization's region.
Installation prerequisite: a standard self-hosted install requires an installation ID and key retrieved with a valid email address.
Lite deployment: the single-container lite option is intended for personal use and home labs, not business use, so it does not fit a clinic.
Migration: moving from cloud to self-hosted requires redoing attachments, member invitations, enterprise policies and SSO, per Bitwarden's migration guide.
Clients and directory sync: the client apps are GPL v3.0, and Directory Connector is GPL-3.0, which covers syncing AD, LDAP or Okta users.

Confirm with Bitwarden which subscription tier and modules your clinical roles need, and check that the data region on the license matches your organization.",

Which platforms fit healthcare teams and why

Clinics and hospitals share far more credentials than most businesses: shared clinical workstations, vendor portals and device consoles. The options below differ mainly in how they handle sharing, recovery and audit logging, and in what the license allows you to run in production, so check those points before choosing.

Passbolt for shared clinical credentials

Passbolt uses OpenPGP end-to-end encryption, so each user holds a key pair and receives their own encrypted copy of each shared resource. The server stores only ciphertext. Account recovery, syslog activity logs, MFA policies and password expiry are listed as Pro features rather than Community Edition features, so confirm which edition covers the controls your HIPAA access and audit reviews need. The Passbolt v5.16.0 release was published on September 17, 2026.

Self-hosted Bitwarden for client-heavy teams

Bitwarden suits teams that want a broad client ecosystem across browsers, mobile devices and desktop apps, plus Directory Connector for syncing AD, LDAP or Okta users. The main server is AGPL 3.0, but files in the bitwarden_license directory fall under a source-available license that requires a paid subscription for production use. Paid features also need a license file tied to your installation ID, so confirm the license terms and data region before deployment. The self-host v2026.10.0 release was published on October 15, 2026.

Vaultwarden as a lighter option

Vaultwarden is a community-built server compatible with Bitwarden clients and is often chosen for small footprints. It is not a Bitwarden product, so its support, patch cadence and fit with a hospital's change control must be confirmed in writing before it holds clinical credentials. Ask who maintains the release and how security fixes reach your environment. Treat it as a candidate to verify, not a default.

Licensing decides what runs in production

The license determines whether a feature can be used in a live clinical environment. Source-available code may be used for testing but not for production without a paid subscription, while AGPL and GPL components carry source-sharing obligations if you modify them. Have counsel review each component's license before go-live, and record the result for procurement and audit files.

Vendor support as a deciding factor

A password vault holding access to electronic protected health information needs a named party who patches, restores and responds to incidents. Community editions may leave that responsibility with your own team. Ask any implementation partner or vendor who handles security updates, backup restores and after-hours support, and whether those services are covered by a written agreement that can serve as a business associate contract input.

Onboarding and offboarding clinicians without orphaned shared accounts

The joiner and leaver flow decides whether a self-hosted vault stays clean after the first month. For rotating clinicians, locum physicians and agency nurses, the working rule is that every person gets a named account before first access, and every shared clinical or vendor credential is tied to a group rather than handed out by copying a password. Confirm with each candidate edition what provisioning it supports. Passbolt lists LDAP user and group provisioning from AD or OpenLDAP and SCIM as Pro features, so a Community Edition deployment will need manual user creation and a documented removal step. Bitwarden's Directory Connector syncs AD, LDAP, Azure, Google Workspace or Okta users, but paid features and directory sync depend on the edition and license you hold, so check that before you design around it. Map each clinical folder to a directory group, such as the one for a specific ward or clinic, so that joining the group grants the folder and leaving the group removes it.

Offboarding is where orphaned access usually survives. Removing a user from the directory or the vault does not change the passwords that person already knew for shared logins, such as a shared nurse station account, a medical device console or a vendor portal. HIPAA's technical safeguard for unique user identification in 45 CFR 164.312 requires that each user can be identified, so any shared login that remains must be split into named access wherever the system allows it, and the shared credential that cannot be split must be rotated when someone with knowledge of it leaves. Build a leaver checklist that lists every shared credential the person could open, rotates it, and records the date and the approver. Treat this as a test you run, not a policy you assume works.

The vault cannot decide who needs access to a patient record. Group membership proves that a person was assigned to a folder, not that the assignment matches clinical need to know. The French data protection authority, the CNIL, fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34 on 3 September 2026 (a case from a European regulator), finding that external access to its patient record system lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. The lesson for a password manager is that folder design, group ownership and approval for each clinical role must be agreed with clinical leadership, the privacy office and the people who run the wards, and reviewed when rotas change. Ask your partner to document that model before the first import.

Deployment pattern on hospital-controlled servers

A self-hosted vault holding clinical and vendor credentials is only as defensible as the servers, database, identity integration and network path around it. The four components below are the decisions a healthcare team must make and document before the first clinician logs in.

Server host and packaging

Passbolt documents installation on Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux and Oracle Linux 9, openSUSE Leap 15 and SLES 16, with Docker, a Kubernetes Helm chart and Ansible as options. Bitwarden publishes Docker-based installs and official Helm charts in its helm-charts repository under AGPL-3.0. Choose the packaging your hospital already patches and monitors, and confirm the vendor's supported OS list before build. Bitwarden's install guide lists 2 GB of RAM and 12 GB of storage as a minimum and 4 GB and 25 GB as recommended, which are starting points to validate under your own load.

Database and backup design

The vault database holds encrypted items, but it also holds user, group and audit records that the hospital must keep available and restorable. Bitwarden's Linux install ships an MSSQL Express image by default with a 10 GB database size limit, so confirm whether that limit fits your vault growth or plan an external database. Define backup frequency, encrypted off-site copies, and a tested restore procedure covering both the database and the attachment store. Record who holds backup decryption material, because a backup that only one administrator can open is an availability risk.

Directory and SSO integration

Clinical staff are onboarded and offboarded through the hospital directory, so the vault must follow that source of truth. Passbolt's Pro edition lists LDAP provisioning from AD or OpenLDAP, SSO with Microsoft, Google, OpenID and AD FS, MFA policies and SCIM as paid features. Bitwarden's Directory Connector syncs AD, LDAP, Azure, Google Workspace or Okta users under GPL-3.0, and paid SSO needs a license file tied to the installation. Confirm which features each edition provides before assuming directory-driven deprovisioning works on the day a clinician leaves.

Network placement and TLS

Place the vault on an internal segment reachable from clinical workstations, with TLS terminated on hospital-issued certificates and no direct exposure to the internet. Remote access for vendors and off-site clinicians should pass through the hospital's approved VPN or access gateway with MFA, consistent with the expectation in the CNIL's 2026 decision that external access to a patient system lacked VPN and multi-factor authentication. Document which subnets and clinical systems can reach the server, and test that browser extensions and mobile clients still connect after a certificate renewal.

Rollout phases for a hospital or clinic vault

This sequence moves a clinical credential set from shared spreadsheets, sticky notes and personal browsers into a vault on hospital-controlled servers, with each phase ending in a written output the security and compliance team can review. The order matters because the account inventory decides the edition and hosting, and the pilot shows whether onboarding and offboarding work before the whole organization depends on the vault.

Inventory clinical and vendor accounts
The security lead works with clinical operations, pharmacy, IT and key vendors to list every shared clinical login, vendor portal account, break-glass credential and service login, noting the owning department, the people who need access and how each account is used today. The output is a reviewed inventory with an owner for each account and a flag for accounts that cannot be rotated without touching a medical device or interface. The step is done when every shared account has a named owner and an access list, and leaders have signed off on the scope.
Choose edition and hosting model
Using the inventory, the team confirms which features the clinic needs, such as directory sync, SSO, MFA policies, account recovery and activity logs, and checks which of those sit in a paid edition for the candidate product. It then decides where the vault will run, on hospital virtual machines, a hospital Kubernetes cluster or another hospital-controlled server, and records the decision with the reasons. The output is a short design decision record covering edition, hosting, data location and support model. Confirm each paid feature against the vendor's current edition comparison before the decision is final.
Build and harden the server
The implementation team deploys the chosen product inside the hospital network, configures HTTPS with a certificate the hospital trusts, restricts administrative access, sets up database encryption at rest and tests the restore path for the database and attachments. Logging of administrative and user activity is routed to the hospital's central log platform, and the backup schedule and retention are written down. The step is complete when a test restore has been run successfully and a hardening checklist has been signed by the security team. Teams should also confirm how the vault's own backups are protected, since they contain encrypted credentials that still need a recovery procedure.
Migrate or import credentials carefully
Credentials move from the current tool or spreadsheets into the vault, with the import format checked against the product's supported list before any data is loaded. For Passbolt, the team should confirm that cleartext CSV export is disabled by default since version 5.10 and keep it disabled unless an administrator has deliberately allowed it for a documented reason. For Bitwarden, a cloud to self-hosted migration requires an export, a license download tied to the installation ID, and a fresh self-hosted account with the same email. Attachments, member invitations, enterprise policies and SSO must be recreated by hand, so the team plans those tasks separately. The output is a migration log showing item counts per folder and a list of anything that was rebuilt rather than moved.
Pilot with one department
A single clinical department, such as an outpatient clinic or a ward with a stable roster, uses the vault for its shared accounts for a defined trial period agreed with the clinical lead. The pilot tests sharing groups, the joiner and leaver steps, shift handover practices and whether the vault works on the workstations and mobile devices clinicians actually use. Problems found in the pilot are logged with an owner and fixed before the next wave. The output is a pilot report listing what worked, what caused friction and which folder or group design changes are needed. Pilot sign-off should require that at least one offboarding test has been completed and verified.
Onboard clinicians and train staff
Each wave of clinicians receives a short, role-specific training session on how to unlock the vault, how shared credentials are checked out or used, what to do when a password is suspected to be exposed and how to request access changes. Access is granted through groups that match the roles in the inventory, not through individual exceptions. Training attendance and the signed acceptable-use acknowledgment are recorded for each person. The output is a training record per user and a group membership list that matches the access model, which auditors can compare against HR and identity records.
Hand over runbooks and capture evidence
The implementation partner or internal team hands over runbooks for installation, upgrades, backup and restore, user onboarding, offboarding, break-glass use and incident response, with named owners for each. Evidence is captured for the controls the hospital needs to show, including configuration baselines, access reviews, backup test results, logs of administrative actions and the training records. Support terms, including who applies product updates and how security advisories are tracked, are written into the handover pack. The step is complete when the operations team has run one runbook without help and the evidence index has been reviewed by the compliance lead.

Evidence auditors and OCR investigators ask for from the vault

This table maps the evidence an OCR investigator or assessor typically requests to the vault component that produces it. Read each row as a question to answer before an review: the source of the record, who owns it, and what must be exported. No HIPAA certification exists, so the table shows evidence to prepare, not a compliance result that DeployOpen or a vendor can attest to.

Evidence item	Produced by	What to confirm before an assessment
Written access and password policy	Your policy documents, enforced through vault settings such as MFA and password policies	Which policy settings your edition enforces natively and which need your own procedure (Passbolt MFA and password policies are listed as Pro features)
Unique user records	Individual vault accounts tied to each clinician and vendor user	That no shared login is used for personal access, and that shared or clinical accounts are logged per named user
Group membership exports	Vault group and folder membership reports or API exports	Whether your edition exports membership lists in a format an assessor can read and whether exports are logged
Activity logs	Vault audit or syslog output forwarded to your log platform	Log retention period, who can read logs, and whether logs are forwarded off the vault host (syslog is a Pro feature in Passbolt)
Offboarding tickets	Your HR or ticketing system, linked to vault removal and key revocation events	That removal from groups and shared resources is recorded with a timestamp and the approver
Backup and restore test results	Database and attachment backups, plus signed restore test records kept by your team	That a restore has been tested on a non-production copy and that the test date and result are documented
Business associate agreements	Contracts with any vendor that hosts, supports or can reach the vault database	That hosting, support and backup providers are covered, and that flow-down terms reach subcontractors handling ePHI
Encryption settings	Vault configuration, TLS certificates and database encryption settings	Encryption in transit and at rest, and whether the server stores only ciphertext or also plaintext metadata

Questions healthcare buyers ask before choosing a self-hosted vault

What does it cost to run a self-hosted password manager compared with per-user SaaS?

The cost is different in kind, not just in size. A SaaS vault bills a recurring per-user fee and the vendor runs the servers. A self-hosted vault shifts cost to the hospital's own infrastructure and staff: server or virtual machine capacity, database hosting, backups, patching, TLS certificates, monitoring, and the people who maintain it. Software cost depends on the edition. Passbolt Community Edition is free to self-host with unlimited users, while Passbolt Pro lists a per-user price on its pricing page. Bitwarden self-hosting is free, but paid organization features need a license file tied to the installation ID. Ask any partner for a quote that separates one-time work (installation, configuration, migration, training) from recurring work (upgrades, backups testing, support retainer, licenses). Compare the total with the SaaS quote over the same period and include the internal hours your team will spend.

How long does a clinic rollout of a self-hosted password manager take?

The timeline depends on scope more than on the software. The main drivers are the number of clinical sites and departments, how many shared and vendor accounts must be inventoried and moved, whether directory sync and SSO are required, how much of the environment must be approved by security and compliance, and how much training clinicians need on their shift schedules. Migration of an existing vault is usually the slowest part because shared credentials must be reviewed, not just copied. Confirm the exact phases, deliverables and dates with any partner in a written, fixed-scope plan before work starts, and ask which steps depend on your change board or on vendor features such as SCIM or account recovery.

What must the hospital IT team provide for a self-hosted vault?

The hospital side usually provides the hosting environment and the approvals. Expect to supply a virtual machine or container platform inside hospital-controlled data centers or an approved cloud account, a database service or permission to deploy one, DNS names and a TLS certificate from an internal or public CA, network rules for the browser and mobile clients, and access to the directory (Active Directory, LDAP or an identity provider) if you want user provisioning or SSO. You also need named owners for backups, patching, monitoring, and incident response, plus a security sign-off on the access control and audit logging design. Passbolt's supported platforms include Debian 13, Ubuntu 26.04, Red Hat, AlmaLinux, Rocky Linux and Oracle Linux 9, and Docker and Kubernetes deployment options are listed. Confirm your OS and platform support with the vendor before you commit.

Can a healthcare team run a self-hosted password manager without a partner?

Yes, a capable internal team can install and run a self-hosted vault, but the question is whether it can sustain the work. Installation is documented by the vendors, and Bitwarden publishes official Helm charts and install guides. The harder parts are ongoing: applying monthly or periodic releases, testing restores, handling certificate renewals, reviewing access logs, supporting clinicians during shifts, and responding to incidents at the server level. Ask who will own each of those tasks on an on-call basis. If the team cannot cover them, a fixed-scope implementation followed by a support retainer is one option, and DeployOpen offers implementation, hardening, backup, upgrade and documentation work for self-hosted platforms in the client's own infrastructure.

Does Passbolt Pro's published per-user price apply to a hospital?

The published price applies only to the edition and terms on the pricing page at the time you buy. Passbolt's pricing page lists Pro at a per-user monthly rate billed annually, with a minimum number of users and volume discounts at higher counts, and it lists Enterprise at custom pricing. Confirm the current figures on the vendor's page, because prices change. Also check which features you need. Passbolt's comparison lists LDAP provisioning, account recovery, SSO, MFA policies, syslog activity logs, password policies, password expiry and SCIM as Pro features that are not in Community Edition. If your hospital needs those controls, the Community Edition is not a substitute, and the Pro or Enterprise terms, plus the support contract, belong in your quote.

Is a business associate agreement needed when a partner supports the vault server?

Usually yes, if the partner's staff could create, receive, maintain or transmit electronic protected health information in the course of the work. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. The key question is access. Vault records can contain patient-related account details, so ask the partner how it would be exposed during installation, troubleshooting and restores, and whether it can operate without access to vault content. Involve your privacy officer or counsel to decide the contract terms. This is a legal determination for your organization, not a point that a vendor can settle for you.

How should a hospital handle a clinician who leaves with access to shared accounts?

Treat it as an offboarding event with three separate steps: remove the person's access, change the credentials they knew, and review what they did. In a self-hosted vault, removing the user from the shared folders stops future access, but it does not change passwords they already saw. Rotate every shared clinical, vendor and service credential the person could view, starting with those tied to systems that hold ePHI. Confirm that the vault's activity logs show the person's recent access, and keep the record for your audit. The HIPAA Security Rule at 45 CFR 164.312 requires unique user identification and audit controls for systems that contain ePHI, which is why shared logins should be avoided where possible. Write the procedure down and test it before a real departure.

What to ask an implementation partner before signing

Start with ePHI exposure during support. Ask the partner who will access the hospital's vault servers, databases, backups and logs, under what approval, and whether any support session can reveal vault contents. Ask how remote sessions are authenticated and recorded, and whether the hospital can require that work happen only through its own VPN and privileged access tooling. Because the HIPAA Security Rule treats the vault as a system holding ePHI when clinical or patient-linked credentials are stored there, ask the partner to describe its own workforce controls and incident reporting timelines in writing. Ask whether the partner will sign a business associate agreement under 45 CFR 164.314(a)(2)(i) and whether it flows the same terms to its subcontractors, including any hosting, backup or email provider that could touch vault data.

Next, test the hardening, backup and recovery path. Ask who holds the Passbolt or Bitwarden server administrator credentials, the database credentials and the encryption or recovery material, and how those are split so that no single engineer can act alone. For Passbolt, ask how the GPG-based key recovery process works when a clinician loses a key and who approves it. For Bitwarden, ask how the installation ID and installation key are issued and stored. Ask for the backup design, including encrypted off-site copies, restore testing frequency and where the restore is performed. Confirm which edition gaps the partner expects: Passbolt's Pro features include LDAP provisioning, account recovery, SSO, MFA policies, syslog activity logs and SCIM, while Bitwarden paid features need a license file tied to the installation. Get written pricing for each paid feature the hospital needs, and confirm that the quote covers the licensing component separately from the partner's work.

Finally, ask how support works after go-live. Request a named support model covering patch cadence for the server and clients, response times for security issues, and who applies Docker or Kubernetes changes in the hospital's environment. Ask how the partner will handle onboarding and offboarding for clinicians and locum staff, and whether it will produce evidence such as access logs, role reviews and offboarding records for the hospital's own HIPAA risk analysis. Confirm that the partner will not issue HIPAA certification, because none exists, and ask what documentation it provides to support the hospital's own assessment. Get the scope, deliverables and support terms in writing before work begins.

How DeployOpen scopes and runs a healthcare password manager

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the vault can run on hospital-controlled servers. Engagements start with a written, fixed scope that sets out what the password manager will hold, who can reach it and what evidence the compliance team will receive.

How we scope

Inventory shared clinical, vendor and break-glass accounts before choosing Passbolt, Bitwarden or Vaultwarden.
Map which roles, departments and sites need vault access, and how onboarding and offboarding flow from the directory.
Agree in writing which edition features, hosting location and backup design the scope covers, and what the client must confirm.

How we build

Deploy the chosen vault on servers the hospital controls, with HTTPS certificates issued from the client's internal certificate authority.
Configure SSO, MFA policies, directory sync and sharing groups, then test them against the documented access rules.
Test the deployment against the agreed scope, including logging, restore procedures and access controls, and record the results.

How we hand over

Document the architecture, configuration, sharing model, offboarding steps and the audit records the vault produces.
Train administrators and clinic leads on vault operations, shared account handling and the procedure for emergency access.
Provide the evidence package in a form that the client's compliance lead and external auditors can review independently.

How we support

Offer ongoing support, upgrades and testing as a retainer, separate from the initial fixed-scope engagement.
Apply vault upgrades and security patches on a schedule agreed in the retainer, with a rollback plan for each change.
Confirm with your team which support tier, response expectations and maintenance windows the retainer will include.