What HIPAA asks of password management and where a self-hosted vault fits
For a covered entity or business associate, the password rule in the HIPAA Security Rule is the procedure requirement at 45 CFR 164.308(a)(5)(ii)(D), which calls for procedures for creating, changing and safeguarding passwords. That standard is addressable, not required, and it sets no minimum password length, no complexity rule and no change interval. The rule therefore leaves the substance to you, but it expects you to write down what your procedures are and to be able to show that they are followed. A self-hosted vault does not satisfy this standard on its own. It is the system in which your documented password procedures are enforced, such as unique credentials for shared accounts, controlled sharing, and recorded changes.
Under 45 CFR 164.306(d), addressable means a three-step decision. You assess whether the specification is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why and implement an equivalent alternative measure, provided that measure is reasonable and appropriate. Record this decision in your risk analysis, with the vault's configuration, sharing model and recovery design as the evidence behind it. Some entities will judge that a vault with enforced policies is the reasonable choice. Others will decide that policies and training alone are the equivalent measure. Either decision needs a written rationale that a reviewer can follow.
There is no HIPAA certification for a password manager or for the program around it. HHS states that no Security Rule standard requires an entity to certify compliance and that it does not endorse or recognize private certifications. Ask any vendor or implementation partner for evidence of configuration and controls, not for a HIPAA badge. Also confirm that the Security Rule text you rely on is current, because HHS proposed a major revision on January 6, 2025 (90 FR 898) that was not final as of October 2026, and its proposed rule would make multi-factor authentication a requirement.
Which HIPAA Security Rule requirements a self-hosted vault touches
This table maps each HIPAA Security Rule provision that touches password and login handling to what the vault must do and what to confirm in the chosen edition. Read the configuration column as a checklist to verify with the vendor and in your own environment, because a vault supports these provisions but does not satisfy them alone.
| Requirement ID | What the function must do | How to configure it |
|---|---|---|
| 164.308(a)(5)(ii)(D) password procedures | Support documented procedures for creating, changing and safeguarding passwords, which the rule does not otherwise prescribe in length or interval | Confirm passphrase and password policies, password expiry policy and whether they are in the Pro or Business tier; write the rule set into your written procedure |
| 164.308(a)(5)(ii)(C) log-in monitoring and discrepancy reporting | Record vault log-in and credential activity so discrepancies can be monitored and reported | Confirm activity logs and syslog export are available in your edition; route them to your SIEM and define who reviews them and how often |
| 164.312(a)(2)(i) unique user identification | Give each workforce member an individual account so vault activity traces to one person | Disable shared logins for personal use; confirm each user has an individual account and that shared items use groups or sharing rights |
| 164.312(a)(2)(iii) automatic logoff | Terminate vault sessions after a period of inactivity | Confirm session timeout settings in the chosen edition and test them on browser extension and mobile clients |
| 164.312(d) person or entity authentication | Verify that a person or system seeking access is who they claim to be | Confirm SSO with your identity provider, MFA policies, and whether MFA applies to every account including administrators |
| 164.312 audit controls | Record and allow examination of activity in systems that contain ePHI | Confirm the retention period of vault logs, their export format, and whether admin and sharing events are captured |
| 164.312(e) transmission security | Protect ePHI and credentials moving across the network | Require HTTPS with a valid internal certificate, restrict plaintext protocols, and confirm the vendor's end-to-end encryption model for stored items |
| 164.304 password definition | Defines a password as confidential authentication information made of a string of characters, so the vault must treat stored passwords as confidential | Confirm the vault encrypts stored entries client-side and restrict admin access to ciphertext and metadata according to your risk assessment |
Which open-source vaults fit a HIPAA environment
HIPAA does not name a password manager, so the choice comes down to how each vault handles encryption, administration, audit records and licensing in your own environment. The cards below cover the three vault options and the SSO layer that usually sits in front of them.
Passbolt Community and Pro
Passbolt is licensed under AGPL-3.0 and encrypts each secret with OpenPGP, so the server stores only ciphertext. The Community Edition is free with unlimited users, but MFA policies, syslog activity logs, LDAP provisioning from AD or OpenLDAP and account recovery are Pro features. For HIPAA audit controls, confirm in writing that the activity logs you need are available in the edition you buy, and that they are forwarded to your log platform.
Self-hosted Bitwarden server
The Bitwarden server core is AGPL 3.0, but files in the bitwarden_license directory, including SSO integration modules, fall under the source-available Bitwarden License. Production use of that code requires a paid subscription, and the license file is tied to your installation ID and must match the region of the cloud organization. Ask the vendor which modules your SSO and enterprise policies depend on before you plan the deployment.
Vaultwarden as an unofficial server
Vaultwarden is a community reimplementation of the Bitwarden server API and is not an official Bitwarden product. It suits teams that want a lightweight server, but it lacks vendor support and the paid enterprise features that come with the official server. Under HIPAA, you would carry the full burden of documenting its patching, backup and access controls, so treat it as a decision that needs a formal risk analysis.
Bitwarden lite is not for business
Bitwarden lite is a single-container deployment that supports several databases and needs at least 200 MB of RAM. Bitwarden intends it for personal use and home labs, not business use. A covered entity should not place ePHI-adjacent credentials in a lite deployment, so deploy the full self-hosted server if you choose Bitwarden.
Keycloak or authentik as SSO
A vault does not have to hold the workforce identity store. Keycloak (Apache-2.0) and authentik (MIT, except its enterprise directory) can provide OpenID Connect or SAML login, MFA and directory federation, so staff use one identity for the vault and clinical systems. Keycloak 26.8.1 and authentik 2026.8.4 were the releases cited for this page. Check which SSO features each vault requires in its paid or Pro edition before you choose the identity layer.
How hosting choices change the HIPAA design
A single virtual machine in the covered entity's own data center is the most direct model. The hospital or practice controls the hypervisor, the network segment, the database and the backup target, so the question of where ePHI-adjacent vault data sits is answered by the organization's own asset inventory. Passbolt publishes installation guides for several Linux distributions and a Docker path, and Bitwarden publishes a Linux install guide that requires Docker Engine and an installation ID tied to a Bitwarden account. Because the operator is the covered entity, a business associate agreement may be needed only for any outside party that touches the server, such as a support provider.
- BAA scope: Confirm whether any vendor or consultant will have administrative access, support tickets or remote sessions. Those parties may need a business associate agreement even though the software is self-hosted.
- Backup location: Define an encrypted backup target inside the organization's control, with tested restore steps for the database and attachments.
- Server keys: Document who holds the host root credentials and the database credentials. Vault contents remain encrypted client-side in Passbolt, but the operator still controls availability.
- Patching: Assign a named owner for operating system and container image updates, since the vendor does not patch the host.
Check the installation prerequisites against the chosen edition and confirm the backup and restore procedure with the platform team before go-live.
Running the vault on Kubernetes adds orchestration, but the data design stays the same: the covered entity still owns the cluster and the persistent volumes. Passbolt publishes a Helm chart in its charts repository, and Bitwarden publishes official Helm charts in its helm-charts repository, both under AGPL-3.0. A chart speeds deployment, yet it does not decide where the database lives, how secrets are injected or whether the cluster meets the entity's own security baseline. Cluster administrators become part of the access control picture, so their roles need the same scrutiny as the vault itself.
- BAA scope: If a managed Kubernetes service runs the cluster, the service provider may handle the infrastructure, which can bring it into scope. Ask the provider for its own agreement terms before deployment.
- Backup location: Persistent volume snapshots and database dumps must be stored in a location the entity controls, and restore tests should cover a full cluster rebuild.
- Server keys: Kubernetes secrets that hold database passwords or encryption settings are readable by anyone with the right cluster role, so restrict those roles and consider an external secrets store.
- Logging: Route container and audit logs to the entity's own log platform to support the audit controls expected under the Security Rule.
Ask the implementation partner which chart version is pinned, how upgrades are tested and who receives cluster-level alerts.
Some covered entities deploy the vault into a cloud account that they own and administer, with the same virtual machine or container layout used on premises. This model can reduce hardware work, but it moves part of the physical and hosting layer to a cloud provider. Whether a given provider offers a business associate agreement, and what that agreement covers, is a question for the provider and the entity's counsel. This page does not assert any provider's compliance status. The entity should confirm the provider's current terms directly, then map which account, region and service roles the vault will use.
- BAA scope: Obtain the provider's current agreement terms and confirm which services are covered. Do not assume that a service listed in a marketing page is covered by the agreement.
- Backup location: Choose a region and storage class that the entity's policies allow, and confirm that snapshots and backup copies stay within the approved boundary.
- Server keys: Decide who holds the account owner role, who can read the key management service and whether the entity or the provider controls key material.
- Identity: Limit console access with SSO and multi-factor authentication, and separate break-glass access from daily administration.
Ask for written answers on data location, provider staff access to the account and the process for requesting account data during an incident.
What auditors and OCR ask to see for password controls
This table lists the artifacts an assessor or OCR investigator is likely to request for password management under the Security Rule, what each one shows, and which part of the self-hosted vault or surrounding program produces it. These are records DeployOpen can help prepare and organize; they are not attestations, and HHS does not certify compliance. Read each row as a question to answer before an assessment, not as proof that a control works.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| Written password and authentication procedures | That the entity has procedures for creating, changing and safeguarding passwords, as 45 CFR 164.308(a)(5)(ii)(D) calls for | Policy documents owned by the covered entity, with vault settings such as password and passphrase policies in Passbolt Pro or Bitwarden enterprise policies recorded as the configured values |
| Risk analysis entry and addressable decision record | How the entity assessed whether each password-related specification is reasonable and appropriate, and why any alternative was chosen | Risk analysis register and documented decision; the vault is an input, not the record itself |
| User access lists and offboarding tickets | Who holds access to each shared folder or collection, and that access was removed when a person left or changed role | Directory sync exports (LDAP or SCIM where enabled), vault group membership reports and the ticketing system |
| Vault activity logs exported to the SIEM | That login attempts and vault events are recorded and can be reviewed for discrepancies, as 45 CFR 164.308(a)(5)(ii)(C) calls for | Passbolt syslog activity logs (a Pro feature) or Bitwarden event logs, forwarded to a SIEM such as Wazuh |
| MFA and SSO configuration exports | That person or entity authentication is in place and that the settings match what the policy says | Configuration exports from the identity provider such as Keycloak or authentik, and the vault's SSO and MFA policy settings |
| Backup and restore test records | That the encrypted vault database and server can be recovered and that the test was run and its result recorded | Backup job logs, restore test reports and the runbook used during the test |
| Training completion records | That workforce members who use the vault were trained on password handling, and when | Learning management records or signed training acknowledgments kept by the covered entity |
What a password manager alone does not satisfy
A self-hosted vault covers part of the password management picture under 45 CFR 164.308(a)(5)(ii)(D), but several connected controls sit outside it. The cards below name the gaps a covered entity or business associate must close with identity, monitoring, people and contract decisions, and what to confirm for each.
MFA not enforced by the vault alone
A vault can hold a password, but it does not decide whether a user must present a second factor to reach the vault or the systems behind it. Under the current Security Rule text, person or entity authentication is required under 45 CFR 164.312, and the January 2025 proposed rule would add a multi-factor requirement that was not final as of October 2026. Confirm which identity provider enforces MFA for vault logins and whether Passbolt Pro MFA policies or Bitwarden enterprise policies are part of the design.
Shared and break-glass credentials
Shared clinical, vendor and emergency accounts are where unique user identification breaks down. A vault can record who retrieved a shared secret, but it cannot by itself stop several people from using one login without attribution. Define which accounts are shared, who may retrieve them, how each use is approved and recorded, and how credentials are rotated afterward. Confirm the procedure with a test, not only with a written policy.
Failed log-in monitoring needs a SIEM
Under 45 CFR 164.308(a)(5)(ii)(C), covered entities must have procedures for monitoring log-in attempts and reporting discrepancies. The vault's own activity log shows vault events, not failed log-ins to the systems that hold ePHI. Route authentication events from the identity provider, the vault and clinical applications to a log platform such as Wazuh, and define who reviews alerts and how discrepancies are reported. Confirm the alert thresholds and review cadence in writing.
Workforce training and sanctions policy
Password procedures under 45 CFR 164.308(a)(5)(ii)(D) belong to a security awareness program and a written sanctions process, not to software. Staff need to know how to create and store passwords in the vault, when to report a suspected compromise, and what happens when a policy is broken. Confirm that training is delivered at onboarding and on a recurring basis, that attendance is recorded, and that the sanctions policy is approved by the compliance owner.
Business associate agreements for hosting and support
A business associate that hosts, supports or administers a self-hosted vault may receive or handle ePHI, depending on what the vault stores and who can reach it. The Security Rule applies to business associates under 45 CFR 164.302, so the contract must cover the duties the vendor takes on. Ask every hosting provider, managed service partner and implementation partner whether it will sign a business associate agreement, which support staff can access the environment, and how it handles backups and incident notice.
Application secrets belong in a secrets manager
Database passwords, API keys and service credentials used by applications are not human passwords, and a vault is a poor place to inject them at runtime. Store them in a secrets manager such as OpenBao, which is licensed under MPL-2.0, and limit which services can read each secret. Confirm how each application retrieves its secret, how secrets are rotated, and which audit records the secrets platform keeps for access and change.
How a HIPAA-scoped vault rollout is sequenced
The sequence turns a set of shared credentials into a documented, access-controlled vault with a recorded addressable decision, staff trained on it, and evidence that the procedures were followed. Each step produces an artifact the security and compliance team can review before the next one starts.
Scope the ePHI systems and vault users
Start by listing every system that stores, processes or transmits electronic protected health information and every account that touches it, including shared clinical logins, vendor accounts and administrator credentials. Compliance, security and clinical operations agree on the user groups and on which credentials belong in the vault versus a secrets manager or privileged access tool. The step is done when the team has a signed inventory of systems, credential types and user groups that the rest of the rollout uses as its boundary.
Record the addressable decision for password management
Under 45 CFR 164.306(d), the covered entity or business associate assesses whether the password management procedures in 45 CFR 164.308(a)(5)(ii)(D) are reasonable and appropriate for its environment. If the answer is yes, the decision record names the vault as the implementation. If an alternative is chosen, the record documents why the specification is not implemented as written and what equivalent measure is used. The step is done when the decision is approved, dated and stored with the risk analysis, so an assessor can trace the reasoning.
Choose edition and hosting for ePHI
Select the password manager edition and the server location based on the inventory and the decision record. Confirm which features the organization needs, such as directory sync, SSO, MFA policies, activity logs and account recovery, and check whether each is in the free or paid edition from the vendor's current documentation. Confirm where the database and backups will sit and who holds administrative access to the server. The step is done when a written architecture note states the hosting location, the edition, the paid features in scope and the vendor support terms.
Configure SSO, MFA and vault policies
Connect the vault to the workforce identity provider so that each clinician has a unique account, then enforce multi-factor authentication for access to the vault itself. Set password and passphrase policies, sharing rules, folder and group structure, and the log retention settings that support the audit controls in 45 CFR 164.312(b). Test that a disabled directory account loses access and that policy changes are logged. The step is done when a test plan has been run and the results are attached to the change record.
Import and retire shared spreadsheets
Move credentials from spreadsheets, sticky notes and older tools into the vault in controlled batches, using the import formats the chosen edition supports. Rotate any credential whose value was exposed in a shared file, and remove the source files from shared drives after the import is verified. Confirm that exports of cleartext data are disabled or restricted in the export policy. The step is done when the source files are deleted or access-restricted, the rotated credentials are recorded, and the owner of each shared account is named in the vault.
Train staff and collect evidence
Train clinicians, administrators and vendor coordinators on creating unique credentials, sharing within the vault, reporting suspicious login attempts and following the offboarding procedure. Keep attendance records, the policy acknowledgments and the written procedures for creating, changing and safeguarding passwords. Schedule a review of log-in monitoring and discrepancy reports. The step is done when the evidence pack contains the procedures, training records, configuration exports and the first review of activity logs, ready for an internal audit or an OCR request. Note that HHS does not certify HIPAA compliance, so the pack supports an assessment rather than proving it.
Questions healthcare teams ask before hiring help
Does a self-hosted password manager make us HIPAA compliant?
No. HIPAA has no certification, and no software product makes an organization compliant on its own. The Security Rule at 45 CFR 164.308(a)(5)(ii)(D) asks covered entities and business associates to have procedures for creating, changing and safeguarding passwords, and the password specification is addressable, so you must assess whether it is reasonable and appropriate and document your decision. A self-hosted vault supports that work by keeping credentials on servers you control and recording sharing decisions, but you still need written policies, workforce training, access reviews and evidence that the procedures run. The HHS FAQ from 2003 states that no Security Rule standard requires certification and that HHS does not recognize private certifications.
What drives the cost of a self-hosted password manager for a clinic?
Cost has four parts: the software license, the server and backup infrastructure, the people who build and run it, and the training and policy work. Passbolt Community Edition is free to self-host with unlimited users, but features such as LDAP provisioning, account recovery, SSO, MFA policies and password expiry are in Pro, which Passbolt lists at $4.9 per user per month billed annually with a 10-user minimum, according to its pricing page. Bitwarden self-hosting is free to install, but paid features need a license file tied to your installation. Recurring costs include hosting, patching, backups and staff time. DeployOpen does not publish prices. Ask any implementation partner for a fixed-scope quote that separates one-time setup from recurring support.
How long does a healthcare password manager rollout take?
The timeline depends on scope, not on a fixed formula. The main drivers are the number of users and shared accounts to migrate, whether the vault must integrate with your directory and SSO, how many policies need to be written or approved, and how many clinical teams need training before cutover. Installation itself is usually the shortest step. Import is supported from many password managers, but attachments, member invitations and enterprise policies may need to be recreated in Bitwarden migrations, so inventory those early. Ask a partner for a written schedule with milestones for pilot, policy sign-off, training and go-live.
What do our staff need to provide before an implementation starts?
Expect to supply four things: read access to your directory (Active Directory, LDAP or a cloud identity provider) so user groups can be synchronized, named owners who can approve password and sharing policies, a list of shared and service accounts with their business owners, and protected time for clinicians and administrators to attend training. Security and privacy officers should confirm where the server may run and who may hold administrator credentials. Without owners for policy decisions, the technical work stalls, so agree on these roles in the written scope before the project starts.
Can our IT team run a HIPAA password manager without outside help?
Many IT teams can install and operate a password manager, but the work covers more than installation. Passbolt publishes Docker, Helm, Ansible and Linux installation paths, and Bitwarden publishes Linux install guidance and Helm charts. The harder parts are integration with your directory and SSO, backup and restore testing, edition-specific feature decisions, migration of existing vaults, policy writing, training, and evidence collection for assessments. Ask whether your team has capacity for ongoing patching and upgrades, and who will respond when a user loses access to a shared vault.
Which Passbolt Pro features matter for HIPAA password management?
The features most relevant to healthcare requirements are LDAP user and group provisioning, account recovery, SSO with your identity provider, MFA policies, syslog activity logs, passphrase and password policies, password expiry policy and SCIM. These support unique user access, activity monitoring and documented password procedures, which map to the access control, audit and authentication standards in 45 CFR 164.312. Passbolt lists these as Pro features not in Community Edition. Its published price basis is $4.9 per user per month billed annually with a 10-user minimum and volume discounts after 100 users. Confirm current pricing and feature availability with Passbolt before you decide, since published terms can change.
Do business associate agreements apply to self-hosted software?
It depends on who handles protected health information. A business associate agreement is generally needed when a vendor creates, receives, maintains or transmits ePHI on your behalf. If you run open-source software entirely on your own infrastructure and the software provider never accesses that data, the provider may not be a business associate for that deployment. However, implementation partners, hosting providers, and support vendors who can reach systems containing ePHI may need agreements. Ask your privacy counsel to review the actual data flows, and ask each vendor in writing whether they will access ePHI or sign an agreement.
Does the Security Rule still require a password policy after 2025?
Yes, the current rule still applies. The Security Rule at 45 CFR 164.308(a)(5)(ii)(D) remains in force, and it sets no minimum password length, complexity or change interval. HHS proposed a major revision on January 6, 2025 (90 FR 898), which would require multi-factor authentication, but no final rule had been published as of October 2026, and the latest Unified Agenda projects final action for July 2027. Design your vault policies to meet the current text and review them when the final rule is published. Pair this with NIST SP 800-66 Rev. 2, which HHS lists as an informational resource for implementing each standard.
Why OCR enforcement makes the evidence file matter
The HHS Office for Civil Rights (OCR) enforces the Security Rule through three routes: complaint investigations, compliance reviews and audits. A complaint can come from a patient, workforce member or anyone else, and a compliance review can be opened after a breach report or other trigger. OCR's HIPAA Audit Program ran a 2024 to 2025 cycle that reviewed 50 covered entities' and business associates' compliance with the Security Rule provisions most relevant to hacking and ransomware. In every route, the question OCR asks is the same: can you show what you required, who was assigned, and what happened when it was tested? For the password procedure in 45 CFR 164.308(a)(5)(ii)(D), that means a written procedure, the settings it produced, and records of who could reach which credentials.
The financial exposure is set by 45 CFR 102.3, which carries the inflation-adjusted civil money penalty table. For penalties assessed on or after January 28, 2026, the range runs from $145 per violation where the entity did not know of the violation, up to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294. Confirm the current table with counsel before using these figures in a board paper, because the amounts are adjusted periodically. The practical point for a self-hosted vault is that an addressable specification is not optional in the record: if you decide a control is not reasonable and appropriate, you must document why and show the equivalent measure you adopted.
Because HIPAA has no certification, your evidence file is what an investigator or auditor will examine. For a vault, keep the export of the admin console policy settings, the dated access review for shared folders, the offboarding tickets that show vault access removed, the log-in monitoring reports tied to 45 CFR 164.308(a)(5)(ii)(C), and the training attendance records. Ask your implementation partner which of these the product exports natively and which you must collect on a schedule, and confirm the audit log retention period in your own environment before relying on it.
How DeployOpen scopes and delivers a HIPAA-ready vault
DeployOpen plans, implements, hardens, documents and supports self-hosted password managers inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where ePHI already lives. We prepare the vault, its configuration and the evidence a covered entity needs for its own Security Rule review, while the entity keeps ownership of its risk analysis, policies and training decisions.
How we scope
- The written scope names the edition, such as Passbolt, Bitwarden or Vaultwarden, and which features it needs.
- Scope lists which systems, user groups and shared accounts that touch ePHI move into the vault.
- Scope records the authentication, logging and recovery settings the covered entity has chosen to document as its addressable password approach.
How we build
- We deploy the vault on infrastructure the client controls, with TLS, backups and access restricted to the approved networks.
- We configure directory sync, SSO, MFA and password or passphrase policies where the chosen edition supports them.
- We test import, sharing, offboarding and recovery procedures against the agreed scope before go-live.
How we hand over
- Handover includes runbooks for administrators, the configuration record and the list of edition features in use.
- Documentation maps each configuration to the HIPAA Security Rule standard it supports, without claiming certification.
- We provide training material for staff on creating, changing and safeguarding passwords under the entity's written procedures.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope engagement ends.
- Upgrades follow the vendor's release cycle and are tested in a staging copy before production changes.
- Support scope, response expectations and service levels are written into the retainer, so the client confirms them before signing.
Sources and further reading
- 45 CFR 164.308 Administrative safeguards (password management standard) ↗
- 45 CFR 164.312 Technical safeguards ↗
- 45 CFR 164.306 Security standards: General rules ↗
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule ↗
- HHS Security Rule guidance material ↗
- NIST SP 800-63B-4, Authentication and authenticator management ↗
