Self-hosted secrets management for healthcare

Why self-hosted secrets management for healthcare starts with ePHI access

A self-hosted OpenBao or Infisical deployment in the organization's own environment can centralize encryption keys, certificates and credentials for the systems that hold ePHI, and record who read which secret and when. For most healthcare teams the starting point is the EHR, the integration engine and the laboratory interfaces, where database passwords, HL7 and FHIR endpoint credentials and API keys often sit in interface configuration files, cron scripts and vendor-managed consoles. The first job is an inventory of where those credentials live, who can read them and which ones are shared across systems. HIPAA does not issue a certification for this work. The HHS FAQ on certification states that no Security Rule standard requires an entity to certify compliance, so the evidence an organization can show an auditor or the HHS Office for Civil Rights is what decides the outcome.

For the platform decision, OpenBao, licensed under MPL-2.0, is the default choice for most self-hosted healthcare cases because its license is OSI-approved and its key/value, dynamic credential and encryption-as-a-service features cover the core needs. Infisical fits teams that want its MIT-licensed core and have confirmed that the features they need sit outside the separately licensed ee directories. Vault versions 1.15.0 and later use the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved license, so procurement and legal should review that terms before any Vault-based design is approved. Confirm the license terms with each vendor at the time of purchase, because the constraints are contractual as well as technical.

Before you commit to a design, confirm three points with your partner and your own environment: which systems hold ePHI and therefore fall under the access control and audit control standards in 45 CFR 164.312, whether each integration engine and EHR can authenticate to a secrets manager through a supported method, and who in the organization holds the unseal and recovery material. The HIPAA technical safeguards require unique user identification and an emergency access procedure, so a design that gives every interface a shared administrator login will not satisfy the rule on its own. Write these decisions down early, because they determine the evidence you will have to produce later.

Which HIPAA safeguards and related rules shape the secrets design

This table maps each HIPAA technical safeguard, business associate duty and planning risk to the secrets design it implies for ePHI systems. Read each row as a requirement, the design choice it drives, and the evidence an assessor will ask to see. The main takeaway is that per-user identity, logged secret reads and encrypted storage are the parts of a secrets platform most often tested.

Requirement	What it asks for	Design choice in a self-hosted secrets platform	Evidence to keep
Unique user identification (45 CFR 164.312(a)(2)(i), required)	Each user or system account that touches ePHI is individually identified and tracked	No shared admin tokens; per-user auth through OIDC, LDAP or Userpass for staff, and separate AppRole identities per service such as the EHR interface engine	Identity inventory mapping every OpenBao or Infisical identity to a named person or service owner
Automatic logoff and emergency access (164.312(a)(2)(iii) addressable, 164.312(a)(2)(ii) required)	A way to reach ePHI in an emergency, and sessions that end after inactivity	Break-glass procedure with sealed recovery material held by named custodians; short token TTLs for human sessions	Written break-glass runbook, custodian list and test records of emergency access
Encryption and decryption (164.312(a)(2)(iv) addressable)	Encrypt ePHI where a risk assessment supports it, with keys managed securely	Encryption as a service and keys held by the secrets platform rather than beside the data; documented key rotation schedule	Key inventory, rotation logs and the risk assessment that justified the chosen encryption approach
Audit controls (164.312(b), required)	Hardware, software and procedural mechanisms that record and examine activity in ePHI systems	Audit device enabled on every secret read and write, shipped to the SIEM, with retention set by the covered entity	Sample audit log entries showing who read which secret and when, plus periodic review records
Person or entity authentication (164.312(d), required)	Verify that a person or program seeking access is who it claims to be	MFA for human administrators; certificate-bound or cloud-identity logins for workloads rather than static passwords in config files	Auth method configuration export and MFA enrollment report for privileged users
Transmission security (164.312(e)(1), required; encryption addressable)	Guard ePHI and credentials moving across networks against unauthorized interception	TLS on every API and cluster port, mutual TLS between nodes, no secrets sent in query strings or logs	TLS configuration scan results and certificate lifecycle records
Business associate flow-down (45 CFR 164.314(a)(2)(i))	Vendors and subcontractors handling ePHI must meet the Security Rule and report incidents	If DeployOpen or any partner can reach key material, the contract must carry Security Rule terms and incident reporting; confirm whether the partner is a business associate	Signed business associate agreement and subcontractor list covering the secrets platform
Implementation specifications framing (Appendix A to Subpart C)	18 standards and 36 implementation specifications; 14 required and 22 addressable, so each addressable item needs a documented decision	Record why each addressable specification is implemented, adapted or not applicable for the secrets scope	Risk analysis and documented decision for every addressable specification touching key management
Pending Security Rule revision (proposed 6 January 2025; final action projected July 2027 per the Unified Agenda)	Proposed rule would tighten cybersecurity expectations, including authentication and encryption; no final text yet	Build to current requirements but keep MFA, key rotation and asset inventories configurable so a final rule can be met without re-architecture	Change log of planned control updates and a named owner tracking the rulemaking
Related external access enforcement (illustrative: CNIL fine on Hopital Prive de la Loire, 3 September 2026, EUR 500,000 under GDPR Articles 32 and 34)	External access to patient records needs VPN and MFA, and access must match the care team's need to know	Vendor and remote clinician access to secrets brokered through identity-based policies with MFA and role scoping per care function	Access policy per role, MFA enforcement report and periodic need-to-know access reviews

What changes for healthcare systems that hold ePHI

The first thing that changes in healthcare is the estate itself. A secrets manager for a hospital or health network has to reach an EHR database, an integration engine passing HL7 v2 messages and FHIR API traffic, lab and imaging connections, a reporting warehouse, and vendor remote access paths that a clinical application team may not even own. Each of these holds ePHI or grants access to it, so each needs a documented owner, a named set of secret types (database passwords, interface engine credentials, API client secrets, TLS certificates and encryption keys) and an audit trail. Before designing anything in OpenBao or Infisical, ask the interface and EHR teams for a complete inventory of where these credentials currently live, including engine configuration files, scheduled jobs and vendor-managed consoles.

The credentials themselves are usually the weak point. Interface engine channels often run on service accounts that were created years ago, are shared by several interface analysts, and are embedded in channel configuration or connection strings. Rotating them is hard because a password change can stop a feed that carries medication orders or lab results, and the same account may be used by a vendor for support. Healthcare teams therefore need rotation that works without interface outages: staged rollouts where the engine can read a new credential before the old one is revoked, short lease lifetimes for dynamic database credentials where the application supports them, and a rehearsal in a non-production interface environment before a change reaches the production engine. Confirm with each EHR and interface engine vendor which authentication methods and credential formats their product supports, because that determines what can be rotated automatically and what still needs a scheduled change window.

Encryption keys carry a second set of obligations. ePHI at rest and in transit must be protected in the primary database, in every replica, in backups and in disaster recovery copies, and the key hierarchy must allow restores without exposing plaintext keys to administrators. Clinical downtime also constrains how OpenBao itself is run: a sealed or failed-over cluster can block every application that fetches a secret at startup, so unseal procedures, storage backend choice and the timing of upgrades must be designed around clinical schedules. Plan unseal and recovery key custody with named custodians, test a restore from backup in a maintenance window that the clinical operations team has approved, and agree in writing how long a planned outage may last and who can authorize it.

How deployment constraints differ across hospital, clinic and payer environments

A hospital that already runs its own data center usually keeps the OpenBao nodes on hardware it controls, in separate failure domains such as different racks or rooms. The security team keeps direct control of the host, the network segment and the backup media, which simplifies evidence for the HIPAA Security Rule access control and audit controls under 45 CFR 164.312. The trade-off is that the hospital carries the operating burden for patching, certificates and recovery testing.

Node placement: Run at least three nodes across separate physical failure domains, with the hosts managed by the existing infrastructure team.
Unseal custody: Split unseal material among named custodians, and store recovery material in a separate physical location from the nodes.
Storage backend: Integrated storage (Raft) keeps the cluster self-contained. PostgreSQL is documented as easier to operate safely than Raft, so teams with a mature database service may prefer it.
Interface engines: Place the integration engine on the same clinical segment and allow only the required API port from its hosts to the cluster.
Audit path: Send audit logs from the nodes to the hospital's log platform so reviewers can examine activity on systems that hold ePHI.

Confirm with your data center team the rack and power separation, the change window for node patching, and whether the hospital's existing database service meets the PostgreSQL operating model.

Which open source platforms fit healthcare secrets management and why

Healthcare secrets work touches ePHI databases, EHR interfaces and integration engines, so the platform choice affects both key custody and the audit trail. The cards below separate the secrets engine candidates from the identity and logging components that produce the evidence a HIPAA assessor or a hospital's own privacy office will ask to see.

OpenBao for secrets and keys

OpenBao is the open source fork of Vault under MPL-2.0, hosted under the OpenSSF as a Sandbox project, and the latest release supplied is v2.7.1 from October 1, 2026. It provides encrypted key/value storage, dynamic database credentials for SQL systems behind the EHR, encryption as a service for ePHI fields, and leases with bulk revocation. For servers, AppRole is the documented recommendation, with JWT/OIDC, LDAP, Kerberos and TLS certificate methods for other callers. Confirm the storage backend and the HA design with your team before you commit, because the documented options are Raft and PostgreSQL.

Infisical with a license check

Infisical covers secrets, certificates and access, and its core is MIT licensed. Directories named ee carry a separate enterprise license, so the features your team needs must be mapped against that boundary before procurement signs off. Release v0.166.8 was published on October 15, 2026. Ask which capabilities for audit logging, access control and key handling sit in the MIT core and which sit in the enterprise code, and whether a healthcare deployment in your own environment needs the ee features.

HashiCorp Vault as a procurement review item

Vault 1.15.0 and later are licensed under the Business Source License 1.1 with IBM named as licensor, and that license is not OSI-approved. Many healthcare organizations already run Vault, so the question is often migration rather than new selection. Treat the license as a review item for legal and procurement, confirm the terms that apply to your intended use, and plan the path for existing Vault secrets and policies if you decide to move to OpenBao.

Keycloak for workforce login

Keycloak supports OpenID Connect, SAML 2.0, LDAP and Active Directory federation, and MFA through its standard flows, which lets clinicians and integration administrators sign in to OpenBao with the same identity source used for the EHR. This matters because the HIPAA person or entity authentication standard and the unique user identification specification both depend on a reliable identity source. Confirm which MFA methods your deployment requires and how Keycloak ties into your directory before you design the OpenBao login path.

midPoint for access lifecycle

midPoint is an identity governance platform under EUPL 1.2 or later that can drive joiner, mover and leaver changes into the systems that hold secret access. Clinical staff changes, contractor offboarding and EHR role moves are the cases where stale OpenBao policies create unnecessary exposure. The Curie 4.8 long-term support line is supported until October 17, 2028. Confirm which source systems you will connect, such as HR and the EHR user store, and who approves a change to access to the encryption service.

Wazuh for audit log ingestion

Audit controls under the HIPAA technical safeguards require systems holding ePHI to record and examine activity, so OpenBao audit devices need a destination that is protected and reviewed. Wazuh, under GPL v2, can collect and correlate those logs alongside EHR and integration engine events, which helps show who read which credential and when. Confirm the log formats your OpenBao version emits, how long logs are retained, and who reviews alerts, since Wazuh collects evidence but does not decide that a review occurred.

How a healthcare secrets rollout moves from inventory to audited rotation

The sequence starts with knowing every ePHI-related credential and key, then proves on one interface channel that rotation and recovery work before the EHR and integration engine estate is cut over and its audit trail reaches the SIEM.

Inventory ePHI-related secrets and interface credentials
The team lists every credential, key and certificate that touches ePHI: EHR database accounts, interface engine connection credentials, API keys for lab and imaging feeds, TLS certificates, and encryption keys for backups and storage. Each entry records the owner, the system, where the secret lives today (configuration files, scripts, vendor consoles, or spreadsheets), and how often it changes. The output is an inventory register that a security lead and the application owners sign off on. The step is done when every system in the data flow has an entry and no secret is left unassigned to an owner.
Design access policies from role and need to know
Working from the register, the team maps each secret to the roles and non-human identities that must read it, such as an interface engine service account, a clinical application, or a vendor support path. Policies follow the need-to-know principle the Hospital Privé de la Loire case in the topic facts highlights, so care staff and integration services get only the paths they use. Human access is tied to individual identities with unique user identification, and machine access uses the auth methods the platform supports, with OpenBao recommending AppRole for servers. The output is a policy set reviewed by the privacy officer and the clinical systems owner, with each policy traceable to a register entry.
Pilot on one interface engine channel
Before touching the EHR, the team moves a single, non-critical interface channel to self-hosted OpenBao. The pilot covers how the engine authenticates, how the credential is fetched at startup or on demand, and what happens when the engine restarts. It also checks that failures are logged and that clinical traffic is not interrupted during a read failure. The output is a tested runbook for that channel, plus a record of what broke and how it was fixed. The step is complete when the channel has run through a planned credential change without manual edits to the engine configuration.
Cut over EHR database and interface credentials
With the pilot runbook proven, the team migrates the remaining EHR database and interface credentials in controlled batches, starting with lower-risk systems. For each batch, the team confirms the new secret path, retires the old static credential, and rotates the credential under test conditions. Dynamic database credentials are considered where the application supports them, and any system that cannot is documented as an exception with a compensating control. The output is a cutover log that shows each credential moved, rotated, and the old value revoked. The step is done when no in-scope system still reads a credential from a file or script.
Test high availability and backup restore
The team tests the OpenBao cluster under failure: a standby node or the active node is taken down, and the team confirms that clients reconnect and that clinical interfaces keep working. They then restore from backup into an isolated environment and confirm that secrets, policies and audit configuration are recovered and that unseal material is available to the right custodians. The team should confirm the supported storage choice (integrated storage with Raft or PostgreSQL) against its own operational skills and recovery targets. The output is a dated test report with the observed failover behavior and restore results. The step closes when the restore test has been repeated against the documented runbook and any gaps are fixed.
Integrate audit logs with the SIEM
The team routes OpenBao audit logs, covering reads, writes, auth events and policy changes, to the SIEM used for ePHI monitoring so that access to clinical secrets can be reviewed. Alert rules are set for unusual read patterns, failed authentications and changes to policies that touch ePHI systems. The team confirms that log integrity and retention match the organization's own records policy and that someone is named to review alerts. The output is an evidence pack that links each register entry to its policy, rotation records, test reports and sample audit events. The step is complete when a test access produces a traceable event in the SIEM and the evidence pack is filed for the compliance lead.
Run scheduled rotation and periodic review
Once the rollout is accepted, rotation runs on the schedule set for each credential class, with the rotation results and any failed rotations recorded in the audit trail. The team reviews access policies on a recurring basis against the register, removes stale identities, and updates the runbook after each change to the EHR or interface engine. The output is an ongoing record that can be shown to auditors or the HHS Office for Civil Rights during a review. Because HIPAA has no certification, this evidence supports the organization's own demonstration of compliance with the Security Rule technical safeguards rather than a certificate.

Which evidence supports a HIPAA review and which component produces it

This table maps the evidence a HIPAA Security Rule review typically asks for against the component that produces it in a self-hosted secrets setup. Read each row as a question to answer with artifacts, and note that DeployOpen prepares the evidence while independent assessors or HHS decide conformance.

Evidence area	What it shows	Component that produces it
Unique identities and access control	Each clinician, service and integration engine has its own identity and only the policies it needs	OpenBao policies and auth methods, backed by the identity provider for human users
Audit records of secret reads and changes	Who read or changed an EHR credential or key, when, and from where, retained for review	OpenBao audit devices exported to the SIEM, with retention set by the covered entity
Encryption of stored secrets and key lifecycle	Secrets are encrypted before storage, and keys have recorded creation, rotation and retirement	OpenBao encrypted storage configuration, key rotation logs and change records kept with the runbook
Rotation runbooks and test results	Database and integration credentials rotate on a defined schedule, and recovery was rehearsed	Documented rotation procedures and dated restore and rotation test records from the deployment
Business associate terms for vendors with key access	Vendors who can touch keys or secrets are bound by terms that flow down Security Rule obligations	Contracts reviewed against 45 CFR 164.314, held by the covered entity or business associate
Unseal and recovery key custody	Named custodians hold recovery material, and access to it is logged and approved	Documented custody procedure and access records maintained by the client's security team

What healthcare teams ask before a self-hosted secrets project

What drives the total cost of a self-hosted secrets project in healthcare?

The largest drivers are integration work per interface, the infrastructure for OpenBao or Infisical, and the operations time that keeps it running. OpenBao is licensed under MPL-2.0, so the software itself carries no license fee, but you still pay for servers or cloud accounts, storage, backups, and staff time. Integration cost scales with the number of EHR modules, integration engine channels, databases and file transfers that need credentials or keys. Ask any partner to split the quote into one-time build work, per-interface work, and recurring support, and to state which items are their scope and which remain yours.

How long does rollout take when a hospital has many interfaces?

Duration depends mainly on the number of interfaces, how many can be moved in one change window, and how long clinical and security approvals take. A small set of database credentials for one system is a very different project from an integration engine that connects dozens of applications. Plan for a pilot on a non-production interface first, then staged cutovers during agreed maintenance windows. Ask the partner for a written schedule that lists the interfaces in each wave, the change windows they assumed, and the approvals each wave needs before work starts.

What must our internal staff provide during a secrets deployment?

Your team has to supply knowledge and decisions that no outside partner can make alone. In practice this means:

Interface owners who can confirm which systems connect, which credentials they use, and when they can change
Clinical change approval for any change that could affect patient care or medication workflows
Security sign-off on access policies, unseal and recovery key custody, and audit log retention
A named operations owner who will receive alerts and approve upgrades after handover

Build these people into the schedule from the start, because approval lead time often sets the pace more than technical work does.

Can our team run a self-hosted secrets manager without outside help?

A capable infrastructure team can run OpenBao without a partner, but healthcare deployments usually need experience with HA design, unseal procedures, backup restore tests, and integration with EHR and interface engines. Ask yourself whether you have staff who can operate a clustered service on call, test recovery on a schedule, and document controls for an assessor. If the answer is partly, a fixed-scope engagement can cover design, integration, hardening and handover, and a retainer can cover upgrades and support afterward. DeployOpen implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure.

Does a BAA change how a self-hosted deployment works?

A business associate agreement is required whenever a vendor creates, receives, maintains or transmits ePHI for you. Under 45 CFR 164.314(a)(2)(i), the 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. If your secrets platform runs entirely in your own environment and the implementation partner never accesses ePHI, the partner may not need a BAA, but counsel should confirm this. Any partner who can reach production systems holding ePHI should be asked to sign one and to describe its subcontractors.

Do we need HIPAA certification for a self-hosted secrets manager?

No. HIPAA has no certification, and HHS states that no Security Rule standard requires an entity to certify compliance. The Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, so you need evidence that your safeguards work. For a secrets platform, that evidence includes unique user identification for every operator and application, audit controls that record activity on ePHI systems, authentication of callers, and encryption in transit and at rest. Some organizations also pursue a HITRUST assessment, which is a separate, voluntary process run by independent assessors. Ask a partner to prepare the control evidence, and never accept a claim that a vendor or consultant certifies HIPAA compliance.

Questions to ask a healthcare secrets implementation partner

Start with unseal and recovery key custody, because it decides whether clinical systems stay up. Ask the partner who holds each unseal key share, how many shares are required to unseal, where recovery keys are stored offline, and how a clinical on-call engineer can restore service at 2 a.m. without any single person holding enough material to read ePHI alone. A credible answer names the separation of duties, the break-glass procedure and the drill schedule. Ask them to show how a seal or storage failure would be handled on your own infrastructure, and which steps depend on a person who might be unavailable.

Next, ask how interface engines and EHR connectors authenticate and how their credentials rotate. Ask which OpenBao auth method each component uses, such as AppRole for servers, and how the rotation of interface credentials is tested in a non-production copy of the integration engine before any production change. Ask for the test plan covering dual-credential overlap windows, rollback steps and how message queues behave during a rotation. Ask how audit logs from the secrets manager reach your SIEM, which fields are retained, and who reviews them. Confirm whether the partner has run healthcare change-control processes, such as clinical freeze windows and downtime procedures, and how those are reflected in the change calendar.

Finally, ask how the partner plans for the pending HIPAA Security Rule revision. The proposed rule was published on 6 January 2025 (90 FR 898), and no final rule had been published as of October 2026, so the reader should confirm the current status before scoping. Ask how requirements will be mapped to 45 CFR 164.312 today and how controls will be adjusted if the final text changes. Ask how evidence is organized for an assessor, including configuration exports, access reviews and key lifecycle records. Request the written scope, deliverables, acceptance criteria and test plan before any work begins, and confirm that independent auditors, not the implementation partner, issue any assessment outcome.

How DeployOpen scopes and supports healthcare secrets deployments

DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open source platforms inside the client's own infrastructure. The cards below cover how a healthcare secrets engagement is scoped, tested and handed over, and where DeployOpen's role stops at evidence preparation.

Fixed-scope written agreements

Most engagements start with a written scope that names the systems in view, such as an EHR connection, an integration engine or a clinical data store, along with deliverables and timelines. Ask which systems are excluded, who owns the unseal and recovery material after handover, and what changes require a new scope. DeployOpen does not publish a price list, so a quote follows from that written scope rather than a template.

Deployment inside your own infrastructure

DeployOpen installs and configures OpenBao in your cloud accounts, data centers or isolated networks, so ePHI-adjacent secrets and key material never leave your environment. Confirm the hosting boundary, the network paths from EHR and integration engine hosts to the secrets cluster, and which administrators hold cluster credentials.

Hardening and backup of the cluster

Hardening covers auth method configuration, least-privilege policies per integration, audit device setup and storage encryption. Backup and restore are tested on a schedule, not only documented, because a lost unseal or recovery arrangement can lock clinical integrations out of their credentials. Ask for the restore test evidence and the recovery procedure in writing.

Security testing of the deployment

DeployOpen runs security testing of the applications, APIs and infrastructure around the secrets deployment, including attempts to read secrets outside their policies and to reach the cluster from unapproved network segments. Agree in advance which environments are in scope, how findings are triaged and whether testing covers integration engine interfaces and admin consoles.

Evidence preparation for assessments

DeployOpen prepares systems, configurations and evidence for compliance assessments, such as access control settings, audit log samples, rotation records and key lifecycle procedures mapped to HIPAA Security Rule safeguards. DeployOpen does not issue audit reports, attestations or certifications, and HIPAA has no certification; the assessing party and your compliance team decide how the evidence is used.

Ongoing support through retainers

After handover, upgrades, rotation tuning, new integration onboarding and continuous testing can run under a retainer. Clarify response expectations, change control for production clusters, and who approves OpenBao version upgrades before they reach clinical environments. Support terms are defined in writing, and the scope of each retainer is agreed before work begins.