Why self-hosted secrets management for financial services starts with key custody
A self-hosted OpenBao cluster in your own infrastructure can give a bank, payment processor, insurer or fintech the key custody, rotation and audit trail that examiners and assessors ask for, but only if the custody design is settled before the software is installed. The questions that matter most are who holds unseal and recovery material, where encryption keys physically live, how many people must act together to change a key, and how every secret read is logged and reviewed. Those decisions shape the architecture, the runbooks and the evidence far more than the choice of product, and they are the first thing a PCI DSS assessor or a DORA supervisor will probe when reviewing cryptographic key management over cardholder data and customer data.
On platforms, OpenBao under MPL-2.0 is the default fit for a self-hosted, open-source design. It is an OpenSSF-hosted fork of Vault, it stores secrets encrypted before they reach storage, and it supports the dynamic credentials, leasing and revocation that reduce long-lived keys and passwords. Infisical is a credible option where its MIT-licensed core covers the need, but the enterprise directories sit under a separate license, so confirm which features your design depends on. HashiCorp Vault 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license, so any firm that inherits a Vault estate or considers it should have legal and procurement review the license terms before committing to a design.
Before you choose, write down the custody model: which roles can unseal the cluster, how key shares are split and stored, whether an HSM must hold the root or wrapping keys, and which events trigger dual control. Confirm with your vendor and your own security team how the chosen storage backend, integrated storage (Raft) or PostgreSQL, handles backup, restore and high availability, because those mechanics determine whether custody holds up during an outage. A design that answers these questions in writing gives you a defensible basis for the PCI DSS and DORA evidence that follows.
Which regulatory requirements shape a financial services secrets design
This table maps the main regulatory and assurance requirements that touch secrets, keys and privileged access in financial services to what each one means for the build. Read each row as a question to put to your assessor, your regulator-facing team and your implementation partner before the design is fixed. Several rows point to evidence you must produce yourself, because no DeployOpen attestation or audit report can substitute for it.
| Requirement | Source | What it means for the build |
|---|---|---|
| Cryptographic key protection and lifecycle (Requirements 3.6 and 3.7) | PCI DSS v4.0.1, the only active version | Keys protecting stored cardholder data need documented generation, storage, rotation, retirement and restricted access. Confirm with your QSA how keys are custodied and whether HSM-backed storage is expected for your environment. |
| Multi-factor authentication for every user of an information system | FTC Safeguards Rule, 16 CFR 314.4(c) | Admin and human access to the secrets manager needs MFA unless the Qualified Individual approves an equivalent control in writing. Plan login MFA in OpenBao and the identity layer that feeds it. |
| Encryption of customer information at rest and in transit | FTC Safeguards Rule, 16 CFR 314.4(c) | Secrets must be encrypted before storage and transport must be protected. Confirm the storage backend and TLS configuration you will evidence, including backups. |
| Monitor and log activity of authorized users | FTC Safeguards Rule, 16 CFR 314.4(c) | Every secret read, policy change and unseal event should reach your log pipeline. Decide retention and who reviews the logs before go-live. |
| Register of information on ICT contractual arrangements | DORA Article 28(3) | The secrets platform and any implementation or support partner belong in the register. Record the service, the provider, the function it supports and the contract details. |
| Documented, tested exit strategy for critical or important ICT services | DORA Article 28(8) | If the secrets manager supports a critical function, you need a tested transition plan. For OpenBao, that means documented data export, backup restore tests and a fallback path for every application. |
| Contract states where services are provided and data processed | DORA Article 30(2) | Confirm in writing the hosting locations, support access locations and the process for advance notice of changes. Include data return on termination or provider insolvency. |
| Access to programs and data as an IT general control area | SEC Release 33-8810, SOX Section 404 guidance | Admin access to the secrets platform, changes to its policies and access to stored secrets fall under ITGC testing. Keep approval records and reviews of privileged roles ready for the auditor. |
| Swift Customer Security Controls Framework v2026 (where the firm is a Swift user) | Swift CSP, 32 controls (26 mandatory, 6 advisory) | Controls on credential and privileged access apply to the Swift environment. Map which controls the secrets platform supports and confirm the independent assessment scope with your assessor. |
Which open-source secrets platforms fit a financial services environment
A financial institution choosing a self-hosted secrets platform has to balance key custody, audit evidence and licence terms at the same time. The four options below differ mainly on licence, governance and the role each plays, so the choice depends as much on procurement and exit planning as on features.
OpenBao as the secrets and key engine
OpenBao is licensed under MPL-2.0 and is hosted under the OpenSSF, where it is a Sandbox project under Linux Foundation stewardship. The current release line includes v2.7.1, published October 1, 2026. It stores key/value secrets encrypted before they reach storage, and it offers encryption as a service, dynamic secrets, leasing with automatic revocation and bulk revocation. For a card payment or account data environment, confirm with the vendor and in your own tests how key material is protected in your chosen storage backend and whether your HSM requirement can be met for the root key.
Infisical with an enterprise licence check
Infisical is MIT licensed, except for content in ee directories, which carries a separate enterprise license. A bank or payment firm should map every feature it needs, such as audit log export, access approvals or key rotation workflows, against the ee directories before committing. If a required control sits in the enterprise code, the cost and the licence negotiation become part of the design. Ask the vendor to confirm which features are enterprise-only and whether your team can build and run the MIT-licensed core independently.
HashiCorp Vault and the licence question
Vault 1.15.0 and later are licensed under the Business Source License 1.1 with IBM named as licensor. This is not an OSI-approved open source license. For procurement, that means legal review of usage limits and redistribution before adoption. For the DORA exit strategy, it means the institution should document how it would migrate secrets, policies and audit history to another platform if licence terms change. Confirm current terms directly with the licensor rather than relying on this summary.
Keycloak for operator and custodian logins
Keycloak is licensed under Apache-2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with LDAP and Active Directory federation. It is a natural workforce identity provider for the people who unseal, approve and read secrets, so every custodian login is tied to a directory identity with MFA. Confirm the OIDC integration with OpenBao in your own test environment, including token lifetimes, group mapping to policies and behavior during an identity provider outage.
How to deploy OpenBao for regulated financial workloads
A self-hosted OpenBao cluster for financial workloads succeeds or fails on a few early choices: where its data lives, how each workload proves its identity, how regulated entities are kept apart, and how every secret read reaches the monitoring team. The cards below cover those four decisions and the checks to run before go-live.
Choose the storage backend
OpenBao supports integrated storage (Raft) and PostgreSQL as its officially supported high availability backends. The OpenBao docs describe PostgreSQL as easier to operate safely than Raft, which matters when the team running the cluster is small or already runs PostgreSQL under change control. Since v2.7.0, read-only standbys can serve PostgreSQL-backed clusters as well as Raft. Confirm which backend the firm's operations team can back up, restore and patch on its own schedule before choosing.
Match auth methods to workload
Servers and batch jobs should authenticate with AppRole, and CI pipelines and workforce logins should use JWT/OIDC so that no long-lived secret sits in a job definition. The OpenBao docs recommend Userpass for developer machines, but many financial firms restrict password-based logins for engineers, so check that choice against the firm's authentication policy before rollout. Map each method to a named owner and a documented policy set.
Separate regulated entities with namespaces
Banks and fintech groups often run several legal entities, business lines or payment programs whose key custody must stay apart. OpenBao namespaces are the mechanism to scope policies, auth mounts and secret engines per unit, but the isolation boundary depends on the version and configuration in use. Ask the implementation partner to demonstrate, in the target version, that one unit's administrators cannot read another unit's keys, and to record that test as evidence.
Forward audit logs to the SIEM
Auditors and supervisors will expect a record of every secret read, including who read it, from which workload and when. OpenBao writes audit logs through configured audit devices, and those logs should reach a SIEM such as Wazuh or Security Onion, which are covered in the open-source SIEM group. Confirm which audit devices the build enables, how log integrity is protected, and what happens to secret reads if the log destination is unavailable.
How dual control and split knowledge change key custody
Dual control and split knowledge are procedural controls, and the firm has to design them before the software is configured. The goal is that no single person can unseal the OpenBao cluster, generate or use a recovery key, or change the root of trust alone. In practice, the firm assigns unseal and recovery material to named custodians, usually a defined set of people from security, operations and a business or risk function, with a threshold that requires more than one of them to act. The threshold, the number of shares, the custodian list and the reasons each person holds a share belong in a written key custody standard approved by the Qualified Individual or equivalent owner. Confirm with the chosen OpenBao build and deployment how unseal shares and recovery material are generated and distributed, and whether any part of that material can be held in an HSM. Placement is a decision to test, not an assumption to document.
Each key ceremony needs a written script that lists the steps, the people present, the materials used and the expected outputs, plus a witness record signed by the custodians and at least one independent witness. Rehearse the ceremony in a non-production environment, record who performed each step, and store the signed record separately from the systems it protects. Custodian rotation must follow a documented trigger list: a custodian leaving the firm, changing role, or losing access to their share. When rotation happens, generate and distribute new material under a ceremony, confirm the old shares are retired, and log the change in the custody register. Physical storage of shares (sealed envelopes, safe deposit boxes, or HSM-protected material) should be recorded with access logs and checked on a schedule the firm sets. The software can record events such as seal and unseal operations and audit log entries, but the firm's written procedure and signed ceremony records are what an examiner or a Qualified Security Assessor will review, so those records must be complete and retrievable. Do not treat a vendor feature as enforcing dual control until the firm has tested that it does so in its own environment.
How a financial services secrets rollout runs in phases
The sequence moves from an inventory of secrets, certificates and keys to a self-hosted OpenBao cluster that holds them under documented custody, with applications migrated, audit evidence captured and recovery proven before handover. Each phase closes with a named output that the firm's security, risk and audit teams can review.
Scope the estate and inventory secrets
Map every secret, certificate and cryptographic key to the systems, applications, pipelines and regulated entities that use it, including which ones fall within PCI DSS cardholder data scope, DORA critical or important functions and Swift or other payment connectivity. Owners of each system confirm their entries, and unknown credentials found in code, configuration files and scripts are logged for migration. The output is a signed inventory with an owner, data classification and a rotation method recorded for each item.
Design custody, roles and ceremonies
Define who holds unseal and recovery material, how split knowledge and dual control are applied to each ceremony, and what happens when a custodian leaves. This phase also decides whether root keys sit in an HSM, in a cloud or on-premises key service, or in a documented alternative, and confirms with the firm's assessor how that choice maps to its key management obligations. The output is a custody design document, a written ceremony runbook and a decision record for the HSM question.
Build the HA cluster in your environment
Deploy OpenBao in the firm's own cloud accounts, data centers or private network, choosing integrated storage (Raft) or PostgreSQL as the storage backend based on the operating skills and backup tooling the firm already runs. Configure active and standby nodes, TLS, network segmentation, and the auth methods that match each workload type, such as AppRole for servers and JWT/OIDC for pipelines. The output is a running cluster with a hardening baseline, documented configuration and a tested failover of the active node.
Migrate applications and pipelines to short-lived credentials
Move each inventoried secret to OpenBao and change the consuming application or pipeline to read it at runtime instead of from files or environment variables. Where the target system supports it, replace static database or cloud passwords with dynamic credentials that expire automatically, and set policies so each workload can read only its own paths. Applications that cannot change immediately keep a documented exception with an owner and a retirement plan. The output is a migration tracker showing each secret's new location, policy and exception status.
Build the audit pipeline and evidence set
Configure OpenBao audit devices so every secret read, write, policy change and authentication event is recorded, then forward those logs to the firm's SIEM with retention that matches its record-keeping rules. Assemble the evidence set that an assessor or internal auditor will request: policy files under version control, role and access listings, change approvals, and a periodic access review signed by the owners. The output is a working log flow to the SIEM, a dashboard of secret reads by identity and a binder of controls mapped to the relevant requirements.
Test recovery and rotation, then hand over
Run a restore from backup into a separate environment, rehearse unseal with the named custodians, and simulate loss of the active node and of a custodian to confirm the procedure works as written. Execute rotation for a sample of dynamic and static credentials and record the results. Handover covers operating runbooks, training for the platform team and the choice between internal operation and a DeployOpen retainer for upgrades, patching and continuous testing. The output is a recovery test report, signed runbooks and an agreed support model.
What examiners and assessors ask for from a secrets deployment
This table lists the evidence items that payment, supervisory and audit reviewers commonly request from a self-hosted secrets deployment, who asks for each one and which component usually produces it. Read it as a checklist to agree with your assessor early, since the exact requirement depends on your license, jurisdiction and scope. DeployOpen prepares these artifacts for assessors but does not issue audit reports, attestations or certifications.
| Evidence item | Who asks for it | Component that produces it |
|---|---|---|
| Key and secret inventory | PCI DSS assessor, DORA supervisor | OpenBao secret engines and mount listings, plus a maintained register of key owners |
| Custody and key ceremony records | QSA, internal audit, supervisor | Unseal and recovery key ceremony logs, HSM or custody procedures, signed witness sheets |
| Access policies per application and namespace | QSA, SOX auditor, internal audit | OpenBao policies, auth role bindings and namespace configuration exported under change control |
| Audit logs of every secret read | PCI DSS assessor, FTC Safeguards reviewer, SOC team | OpenBao audit devices shipped to the SIEM, with retention set to the entity's policy |
| Rotation and revocation records | QSA, supervisor, incident response team | Lease and rotation logs, bulk revocation records and tickets for manually rotated keys |
| HA and backup or restore test records | Supervisor, operational resilience reviewer | Signed restore test reports for integrated storage or PostgreSQL backups, failover test logs |
| DORA register of information entry for the ICT provider | EU financial supervisor, DORA compliance lead | Contract register entry naming the provider, service locations and data processing locations per Article 28(3) |
| Exit strategy and transition plan for critical or important functions | DORA supervisor, board risk committee | Documented and tested exit plan covering key export, data return and migration to another manager |
What to ask an implementation partner about financial services key custody
Start with custody, because every other control depends on who can unseal the cluster and who can recover it. Ask the partner to show, in writing, how custodian roles are split, how the unseal keys and recovery keys are generated, distributed and stored, and which combination of people is needed for each action. Then ask when the partner last ran a dual control and split knowledge drill on your environment, what the drill covered, and what was changed afterward. A partner that can only describe the design, and cannot show the runbook, the custodian acknowledgments and the test record, has not yet answered the question. Ask for the same evidence for PCI DSS Requirements 3.6 and 3.7, since those requirements expect documented key management procedures and key custodian responsibilities that you can show an assessor.
Ask which HSM options the partner has validated against the exact OpenBao version you intend to run, not against OpenBao in general. Confirm whether keys will sit in hardware for the root or for the auto-unseal function, which HSM models and firmware the partner tested, and how a failed HSM is handled during an outage. Ask how audit logs of every secret read reach your SIEM, which fields are captured, and how the partner proves completeness, for example by generating known test reads and confirming each one appears downstream. On DORA, ask how the partner fills the register of information entries for this service and what the exit strategy and transition plan contain, including how OpenBao data and keys can be exported and re-imported elsewhere. Ask the partner to show anonymized examples of its evidence pack. Those examples should show what is produced, not claim that any certificate or attestation exists.
Ask how an existing HashiCorp Vault deployment moves to OpenBao, given that Vault 1.15.0 and later are under the Business Source License 1.1 with IBM named as licensor. Request the migration plan, the rollback plan and the list of features in use that need checking. Ask how HA failover and restores are tested, how often, and against which storage backend, since OpenBao supports integrated storage (Raft) and PostgreSQL for HA. Finally, ask whether the offer is fixed scope, with deliverables and dates agreed in writing, and whether upgrades, security patches and continuous testing are covered by a retainer. Ask who signs off on each OpenBao release you adopt and how long the partner takes to apply a security fix. Those answers decide whether your key custody stays defensible after go-live.
What financial firms ask before hiring help for self-hosted secrets management
What drives the cost of self-hosted secrets management for a financial firm?
Scope drives cost more than any single product choice. The main inputs are the number of applications and CI/CD pipelines to integrate, whether keys must sit in hardware security modules, how many regulated entities and namespaces the platform must separate, how large the key custody ceremony is, and how many staff will operate the cluster afterward. Some costs are one-time, such as design, integration, migration and the custody ceremony. Others recur, such as infrastructure, HSM support, upgrades, backup testing and operations time. Ask for a quote that lists each cost line, who performs it, and which items are optional, so you can compare the scope against your own staffing.
How long does a self-hosted secrets management rollout take?
Duration depends on the written scope, so there is no standard figure to quote. A rollout covering a few applications on a single cluster is planned very differently from one that moves secrets out of many scripts, pipelines and configuration files across several regulated entities. Before work starts, DeployOpen agrees the scope, deliverables and timeline in writing. Ask for a milestone plan that separates design, custody ceremony, pilot integrations, migration waves, testing of backup and recovery, and handover, and confirm which milestones depend on your change windows or your own reviews.
What does our firm need to provide for a secrets management engagement?
The engagement needs people and access more than hardware. Expect to name key custodians who will hold unseal or recovery material under dual control and split knowledge, and to confirm who approves custody decisions. You will also need a secret inventory that lists where credentials, certificates and keys live today, including those hard-coded in code, pipelines and configuration. Each application needs a named owner who can confirm behavior and test cutover. Finally, the implementation team needs access to the target environment, such as cloud accounts, data centers or isolated networks, with the change approvals your policy requires.
Can our own team operate a self-hosted secrets manager after the rollout?
Yes, if the rollout is designed for handover. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, so the documentation, runbooks and tested recovery procedures produced during the engagement are meant to be used by your staff. Ask for the operating procedures to cover unseal, key rotation, policy changes, upgrades, backup restoration and audit log review, and ask for evidence that the restore tests were actually run. Ongoing support, upgrades and continuous testing are also available as retainers if you prefer shared operations.
Is an HSM always required for secrets and key management in financial services?
No. Whether a hardware security module is required depends on your firm's cryptographic key management policy, the regulations and contracts that apply to each system, and the build you choose. Some firms keep root or master keys in an HSM and let the secrets manager hold operational material. Others use a different custody model. This point must be confirmed with your compliance function, your assessor and your own risk documentation before design starts. Ask the implementation partner to document which key classes use hardware protection, why, and how that choice affects cost, availability and recovery.
Can DeployOpen issue a PCI DSS or DORA attestation for our environment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For PCI DSS, the assessment is documented as a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the payment brands decide who must validate. For DORA, the regulation sets no certification scheme, so your supervisors and your internal and external assurance providers judge the evidence. Ask the implementation partner to map each control to the evidence it produces, and to share that map with your assessor early.
How DeployOpen scopes and supports financial services secrets work
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For financial services secrets management, that means OpenBao or another agreed platform deployed in the institution's environment, with key custody, access policies and audit evidence designed around the controls the institution must show.
How we scope
- Written scope covers which payment, core banking and integration systems hold secrets and keys
- Scope records where key custody, unseal and recovery material will sit and who holds each part
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ask us to confirm whether HSM-backed storage is in or out of scope before quoting
How we build
- Deployment of the secrets platform in your environment with high availability and separate environments
- Configuration of auth methods, least-privilege policies and dual control steps for key ceremonies
- Migration plan for secrets currently stored in code, configuration files and scripts
- Audit logging configured so every secret read is recorded and forwarded to your monitoring stack
How we hand over
- Documentation of key lifecycle, rotation, backup and restore procedures written for your operators
- Evidence packs mapping configured controls to the requirements your assessor or supervisor will ask about
- Tested backup and recovery runbooks, with restore results recorded in the handover record
- Knowledge transfer sessions so your team can run the platform without relying on DeployOpen
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Security testing of the deployed platform and its integrations can be scoped separately
- Support covers patching and upgrade planning against the releases your team chooses to adopt
- Compliance readiness work prepares evidence; independent auditors and certification bodies issue assessments
