Secrets management RFP questions to ask before you choose a partner
If you are running secrets in scripts, config files and possibly an existing Vault deployment, the questions to ask a partner are less about which product to pick and more about how they will design key custody, authentication, recovery and migration in your own infrastructure. Send the questions below in writing, ask for the named architects who will do the work, and score each answer against a written scope. Ask for a reference architecture before pricing. DeployOpen does not publish prices and quotes follow from the written scope, so a clear scope is what lets you compare proposals fairly.
The questions differ by candidate platform. OpenBao is licensed under MPL-2.0 and is a community fork of Vault, while Infisical is MIT licensed except for content in ee directories, which carries a separate enterprise license. A Vault migration raises different questions than a greenfield build, and the answers should be checked against your own environment: your storage backend, your HSM or unseal policy, your Vault edition and license terms, and the systems that will read secrets. Ask the partner which migration guide version they tested against and what they did when your setup differs from it. Treat any answer that depends on a feature you cannot confirm in writing as an open item in the scope, not as a commitment.
Ask how unseal and recovery keys are split, stored and rotated, who holds each share, and which runbook is used when two holders are unavailable. Ask how applications and pipelines authenticate, which auth methods they would use for servers and developer machines, and how long-lived credentials are removed from existing code. Ask how high availability and backups are tested, how often restores are rehearsed, and what evidence is delivered. Finally, ask which secrets will be rotated automatically, how audit logs leave the cluster and reach your SIEM, and who owns the log pipeline after handover.
Which questions reveal how a partner will design unseal, access and recovery
How should a partner design unseal and recovery keys for OpenBao?
A strong partner states how the cluster unseals after a restart, how many key shares exist, the threshold to unseal, and where recovery material is held. Ask who the custodians are, how no single person can unseal alone, and whether auto-unseal depends on an external key service that your team or the partner operates. A good answer contains a written custody matrix naming each custodian role, a ceremony runbook, and the seal stanza settings used in the server configuration. Evidence should include a test record showing a node restart, an unseal with the documented shares, and a recovery drill performed with the same procedure. Confirm that the design meets your sector's dual control or split knowledge rules before work starts.
Which auth method should each application and server use in OpenBao?
OpenBao documents AppRole for servers, JWT/OIDC, Kubernetes, TLS certificates, LDAP and other methods, and recommends Userpass only for developer machines. A good partner maps each workload to one method and explains why, with a matrix listing the policy attached to each role. Ask how AppRole secret_id values are issued, how long they live, how many uses they allow, and how they are delivered without being stored in code. Evidence should include the policy files, the role configuration for each application, and a test showing that a revoked secret_id is refused. Ask whether login MFA is required for any human path. The OpenBao auth methods docs list the full set of options.
How do CI pipelines log in to OpenBao without long-lived tokens?
Pipelines usually authenticate through JWT/OIDC, where the CI platform issues a short-lived identity token that OpenBao validates against bound claims such as project, branch or runner. A good partner shows which claims bind each role, how short the resulting token lifetime is, and how each project receives its own policy. Ask what happens when a branch is not on the allow list and whether protected branches are the only ones that can read production secrets. Evidence should include the auth configuration with its bound claims, the token time-to-live settings, and an audit entry from a test job that shows the job identifier. Ask for a test where a job from an unapproved project is refused.
Can an existing HashiCorp Vault deployment move to OpenBao, and what must be checked?
A move is possible for many deployments, but the partner must verify it against your exact Vault version and feature set. The OpenBao migration guide was tested only against Vault 1.14.1 community edition, and Vault Enterprise was outside that test, so the partner needs to show how each Enterprise feature you use is handled. Ask for a feature inventory covering namespaces, replication, seal wrapping, Sentinel policies, control groups and HSM use, with an OpenBao equivalent or a documented gap for each. Evidence should include a dry-run restore into staging, a policy comparison report, a cutover plan, and a rollback procedure with a tested restore point. Read the OpenBao migration guide before the scoping call.
How should high availability and backups of OpenBao be tested?
OpenBao's HA model uses one active node that holds a lock in the data store, with standby nodes that forward or redirect requests. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and read-only standbys arrived for Raft in 2.5.0 and for PostgreSQL in 2.7.0. A good partner tests failover by stopping the active node under timing and recording how long clients take to recover. Backup evidence should include snapshot schedules, a restore into a clean cluster, and a runbook that names the people who run each step. Ask which backend they recommend for your size and why, noting that the docs describe PostgreSQL as easier to operate safely than Raft. Ask whether read scaling is configured and tested, not just enabled.
Which secrets should rotate automatically, and what breaks when they do?
Dynamic secrets are the strongest candidate for automatic rotation because OpenBao issues credentials for databases and Kubernetes with leases and revokes them automatically. Static secrets such as third-party API keys need a rotation process that the partner designs with each owning team, because OpenBao cannot rotate every vendor's key by itself. A good answer lists each secret type, its rotation method, its lease time-to-live, and how applications pick up a new value. Evidence should include a bulk revocation test, a rotation rehearsal on a non-production system, and documented behavior when a lease expires during a job. Ask who owns the rotation calendar after handover and what alerts fire when rotation fails.
How do OpenBao audit logs reach our SIEM?
Audit logs must be enabled through an audit device and then shipped to the SIEM by a forwarder, a collector or a log agent. A good partner names the audit device types in use, the path where logs are written, the forwarder, and the parser that turns each entry into searchable fields. Ask whether sensitive values are HMAC-hashed in the log and how the partner confirms that no plaintext secret appears in the SIEM. Evidence should include a sample event with its fields, a parser test, alerts for sealing, policy changes and repeated authentication failures, and a retention setting that matches your framework. Relevant rules include the audit controls in 45 CFR 164.312 and the activity logging required by the FTC Safeguards Rule for covered financial institutions. Ask the partner to confirm which SIEM they will integrate with, such as Wazuh.
Which licensing and feature gaps affect an OpenBao plan?
OpenBao is licensed under MPL-2.0 and is hosted under the OpenSSF, while Vault 1.15.0 and later are licensed under the Business Source License 1.1 with IBM named as licensor. The Vault license bars competitive hosted or embedded offerings and converts each version to MPL-2.0 four years after publication. Enterprise features such as performance replication, HSM support, FIPS compliance and Sentinel need a Vault Enterprise license applied to the cluster, and HashiCorp does not publish those prices. Ask the partner to list every feature your design depends on, mark each as available, partly available or missing in OpenBao, and state which ones need a replacement design. Evidence should include that written feature matrix and a note on who holds each license or support contract. Ask your procurement team to request a Vault Enterprise quote directly if you still evaluate it.
Answers about keys, migration and backups that should worry you
Vendors and partners often answer secrets management questions with confident generalities. The cards below mark the answers that signal weak key custody, untested migrations, unproven recovery and misplaced compliance claims. Each one gives a concrete check to run before you sign.
Unseal keys stored with the cluster
If unseal keys or recovery shares sit on the same hosts, in the same cloud account, or with one administrator, a single compromise or departure unlocks every secret. Ask where each key share is held, who holds a threshold of shares, and how the split is tested during a rehearsal. A credible answer names separate custodians and separate storage locations.
Zero-downtime migration without a plan
OpenBao's migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so a promise of a painless move from any Vault version is unsupported. Ask for a written migration plan that names your exact Vault version and edition, a rollback path, and a rehearsal in a non-production copy. Treat "zero downtime" as a claim to verify, not a starting point.
HA and restores without test evidence
Claims of high availability or working backups mean little without recorded failover and restore tests. Ask which storage backend is proposed, since integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and request the date and results of the last restore test into a clean environment. Ask how long a restore took and who signed off on it.
Enterprise features treated as included
HSM support, performance and disaster recovery replication, seal wrapping, FIPS compliance and namespaces are listed as HashiCorp Vault Enterprise features that need a license applied to the cluster. Confirm in writing which of these exist in the open source build you would deploy, and which need a commercial license, a vendor HSM, or a different design. Ask for the license cost line in the quote, not a verbal assurance.
Vague answers on automatic rotation
"We rotate everything" hides the real split between dynamic credentials that expire on their own, static secrets that need a rotation job, and certificates that need renewal logic. Ask for a list of each secret type you hold, the mechanism that rotates it, the rotation interval, and what breaks in the application when rotation fires. Dynamic database credentials and leased tokens are the strongest answer.
Promised compliance by platform
No secrets platform or implementation partner makes an organization compliant with a framework such as HIPAA, the FTC Safeguards Rule, or any ISO or PCI standard. Those rules require policies, operating procedures, access reviews and evidence that a qualified assessor examines. Ask which controls the design supports, which evidence it produces, and which obligations remain with your team and your assessor.
How to score partner answers in a side-by-side comparison
This table gives six criteria for comparing partner answers to secrets management RFP questions, with what full marks look like and what a failing answer sounds like. Set the weights from your own risk profile, data classification and regulatory obligations, then score each partner's written answer against the same wording. The main takeaway is that a fluent answer without named evidence should score lower than a shorter answer that shows a tested procedure.
| Criterion | Weight | Full marks look like | A failing answer looks like |
|---|---|---|---|
| Key custody | Set from your risk profile | Unseal and recovery key split, custodian roles, a written ceremony for rotation, and where any HSM or auto-unseal dependency sits | Keys described as managed by the platform, or no named custodians and no account of who can recover the cluster |
| Authentication design | Set from your risk profile | Per-workload auth using AppRole, Kubernetes, JWT/OIDC or TLS certificates, with short token lifetimes and policies scoped per application or team | Shared static tokens or a single root-style credential for pipelines and applications |
| Migration plan | Set from your risk profile | Inventory of existing Vault paths and policies, a stated Vault version baseline, a tested rehearsal in a non-production copy, and a rollback plan | Migration described as a configuration change, with no inventory, no version check and no rollback step |
| HA and recovery evidence | Set from your risk profile | Documented storage choice, failover test results, restore test dates and the recovery time they measured, shown to you on request | Backups described without a restore test, or HA claimed without a failover test |
| Rotation coverage | Set from your risk profile | A list of secret types with rotation method for each: dynamic database credentials, cloud keys, certificates and static secrets that cannot be rotated automatically | Rotation promised for all secrets with no list of exceptions or manual steps |
| SIEM integration | Set from your risk profile | Audit device logs shipped to your SIEM in a named format, with alerts on policy changes, root use and unusual read volume, and log retention set by you | Audit logs stored only on the secrets server, or integration deferred to a later phase |
How the answers fit together across the secrets lifecycle
The answers to these questions only make sense together, so read every vendor or partner response against the rest of the lifecycle. Key custody comes first. The unseal and recovery keys decide who can bring the cluster back after a restart, a failover or a restore, and that decision constrains everything downstream. If a proposal uses auto-unseal through a cloud key service, check which account, region and administrators control that key. A design where the unseal key sits in the same cloud account as the encrypted data gives one set of administrators the power to read the data and the means to decrypt it, which undermines the separation the rest of the design is supposed to provide. Ask where each unseal and recovery key lives, who holds each share or credential, and whether recovery still works if that account is locked, lost or unavailable.
Authentication and storage shape the blast radius. An AppRole, Kubernetes, JWT/OIDC or TLS certificate auth method is only as narrow as the policies bound to it, so ask how each workload's identity maps to a policy that grants access to a specific path and nothing more. Storage choice then determines what HA and backup claims mean. A vendor that describes Raft or PostgreSQL as the storage layer should also explain how the active node, standbys and snapshots are restored, and whether a restored snapshot brings back revoked tokens or stale leases. Rotation and audit are the checks that close the loop. Dynamic credentials and leases only reduce risk if revocation is tested, and audit logs only prove something if they are shipped to the SIEM in a form that records which identity read which secret. Ask the partner to show one request traced from the workload identity, through the policy, to the log entry in the SIEM, and to show a revocation that the SIEM also records.
How to run the RFP from questions to a signed written scope
This sequence moves a secrets management selection from a list of written questions to a fixed, written scope that both sides can hold the implementation to. Each step produces a record that the next step depends on, so nothing reaches contract on verbal assurances alone.
Send the written questions in advance
Send the full question set to each shortlisted partner before any meeting, covering unseal and recovery key design, application and pipeline authentication, Vault-to-OpenBao migration, HA and backup testing, automatic rotation coverage and SIEM log delivery. Ask each partner to answer in writing, referencing the platform version and license they propose. The step is done when every partner has returned written answers and your team has logged gaps for follow-up.
Request architecture and runbook samples
Ask for a redacted sample architecture diagram, a sample runbook for unseal and key recovery, and a sample backup restoration procedure from comparable work. Confirm that samples show how keys are split, who holds them, and how access is logged. Check whether the partner will show the same documents under a non-disclosure agreement if the samples are redacted. The step is done when your security and platform engineers have reviewed the samples and noted where answers in writing do not match the documents.
Run a scored technical review with named engineers
Hold a live technical session with the engineers who would do the work, not only the sales lead. Score each partner against a fixed rubric built from your questions, with separate scores for key custody design, authentication patterns, migration approach, HA and recovery testing, rotation coverage and audit pipeline. Record who answered each question so accountability is clear later. The step is done when the scores, named attendees and open questions are written up and agreed by your review panel.
Ask for a proof-of-concept scope in writing
Ask the shortlisted partners to scope a bounded proof of concept against one representative workload, such as one application's static secrets, one pipeline's authentication, or one restore test. The written scope should name the environment, the systems in scope, the success criteria and the artifacts you will receive. Confirm what the proof of concept excludes, including production cutover. The step is done when each proposal is in writing and comparable against the same criteria.
Agree a fixed scope and deliverables before work starts
Select one partner and agree a fixed scope with written deliverables, acceptance criteria and handover items before any work begins. Include key custody and unseal procedures, authentication design per workload, migration steps and tested restore evidence, rotation inventory, and SIEM integration with documented log fields. Confirm the support model after handover in writing as well. The step is done when the signed scope, deliverables and acceptance criteria are on file and the work starts only against that document.
What to confirm with the vendor and your own environment
Feature availability depends on the edition you will run, so confirm it before you score any vendor answer. OpenBao is MPL-2.0 licensed and its documented high availability and read scaling features are listed in its own docs, but a partner should show, in your target version, that each feature you need works on the storage backend you choose. Ask for the exact OpenBao release, the storage backend (integrated storage with Raft or PostgreSQL), and a written statement of which capabilities were tested in a proof of concept rather than only described in documentation. If you are comparing with Vault, separate Community Edition features from Enterprise features, because the Vault Enterprise documentation lists several capabilities such as performance replication, HSM support, seal wrapping, namespaces and control groups as needing a license applied to the cluster.
Migration questions cannot be answered from public material alone. The OpenBao migration guide was tested only against Vault 1.14.1 Community Edition, so ask your partner how they will handle a Vault version outside that test, and whether any Enterprise feature your current cluster uses has a supported equivalent. Confirm your current Vault version and license terms with your contract owner, and have counsel review whether your use of Vault under the Business Source License 1.1 permits the migration path and any parallel run. Ask the partner to name the migration evidence they will produce, such as secret inventories, policy translation records and a rollback plan.
Decide whether HSM-backed key custody is required before you finalize the unseal and recovery design, because it changes the architecture and the quote. Ask your compliance lead which regulation, customer contract or internal policy requires keys to sit in hardware, and whether that requirement covers the root key, the transit keys or only the cluster unseal material. Then ask the vendor and partner to confirm, in writing and for the exact release, which HSM integration methods are supported and what the partner has tested. Finally, list the Enterprise features you truly need, such as replication or FIPS-validated components, and ask for a line-item quote that separates licensed features from open-source work so you can compare options fairly.
What drives the cost of the partner's work
When no secrets manager is in place yet, most of the partner's fees go to design decisions that are hard to change later: the storage backend, the unseal and recovery key custody model, the HA topology and the auth method for each class of client. Build work is then mostly integration, because every application, pipeline and administrator needs a defined way to authenticate and a policy that limits what it can read.
- Architecture and key custody design: Who holds unseal and recovery material, how it is split, and where it is stored. Ask for this as a separate line item with a written decision record.
- Environment build: Installation, HA nodes, storage backend, TLS, and network paths for each environment such as development, test and production.
- Auth method and policy setup: AppRole, JWT/OIDC, Kubernetes or other methods, plus policies per team or application.
- Integration per application: Each client change is a separate unit of work. Ask how many integrations the quote assumes and how new ones are priced.
- Operations handover: Runbooks, backup and restore procedures, and training. These are one-time items unless a support retainer is added.
Check whether the quote separates one-time build work from recurring support, upgrades and testing.
Moving from an existing Vault deployment to OpenBao adds an inventory and compatibility step that greenfield work does not have. The partner must confirm which Vault edition and features the estate uses, because the OpenBao migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise. Any Enterprise feature in use, such as performance replication or namespaces, changes the scope.
- Edition and feature inventory: Identify which Vault version, edition and features are in use, and which secrets engines, auth methods and policies depend on them.
- Compatibility testing: Work out a test plan against a copy of the real configuration, not only the default setup.
- Cutover and parallel running: Planning and execution of the switch, including rollback steps and how clients are repointed.
- Client reconfiguration: Each application, pipeline and agent that talks to Vault needs its address, auth and policy references checked.
- Retained licensing and support: Existing Vault contracts may still have costs during the transition. Ask the partner to show which costs end and when, and which remain.
Ask whether the quote covers testing against your Vault version and edition, not only the generic migration guide.
Many organizations have credentials in source code, CI variables, configuration files, scripts and wiki pages. Removing them is often the largest hidden cost, because the work is discovery, ownership assignment and coordinated rotation, not installation. Each secret needs an owner, a target path, a policy and a rotation decision before it can be moved safely.
- Discovery and inventory: Scanning repositories, pipelines, servers and configuration to find credentials. Ask what tools and scope the discovery uses and who reviews the findings.
- Ownership and classification: Mapping each secret to a system owner and deciding whether it is static, dynamic or a certificate.
- Rotation and cutover: Changing each credential at the source, updating consumers and confirming the old value no longer works. This recurs for every system touched.
- Repository cleanup: Removing secrets from history and configuration, and setting controls to prevent new ones from being committed.
- Evidence capture: Records of which secrets moved, when and under which change request, for later audits.
Ask the partner to estimate the inventory before committing to a fixed scope, and to state which systems are excluded.
Frequently asked questions before hiring outside help
Cost depends on the written scope, not on the product. The main drivers are the number of secret types in scope (static credentials, dynamic database credentials, certificates, encryption keys), how many applications and pipelines must be integrated and how each one authenticates, whether the cluster must run in an HSM-backed or air-gapped setting, and whether a Vault estate must be migrated to OpenBao. Each of these adds one-time design, build and test work. Ongoing costs are infrastructure for the HA nodes and backups, the people who run them, and any retainer for upgrades and testing. Ask every bidder to price these components separately, so you can see which items recur and which are paid once. Ask also who owns the license terms for each component, since open-source and open-core licenses differ in what you may use for free.
Duration is set by the scope document, and you should not accept a timeline before that document exists. A fixed-scope engagement is agreed in writing with its deliverables and dates before work starts, and the number of applications, environments and unseal-key ceremonies to design are the largest variables. Ask the partner to show how each migration, integration and recovery test is scoped and what evidence each one produces. Confirm which parts of the work depend on your change windows, vendor access or procurement cycles, because those dependencies often set the calendar more than engineering effort does.
Your team has to supply decisions and access, even when a partner does the build. Expect to name owners for unseal and recovery key custody, for the approval of auth methods per workload type, and for the SIEM receiving audit logs. Your staff will also need to provide network access, identity provider details and a list of secrets already stored in code, configuration or CI variables. If you plan to run the platform yourself after handover, ask for runbooks, a tested restore procedure and training for at least two operators, so that no single person holds the knowledge. Retainers are a common option for upgrades, security patches, backup restore tests and rotation support, and they can be scoped to the same written terms as the build.
How DeployOpen scopes and delivers secrets management evaluations and implementations
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. We turn the answers to these RFP questions into a written scope, a tested design and a handover package that your team can run without us.
How we scope
- We start from your secret types, applications, pipelines and existing Vault or OpenBao estate before naming a design.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope states which unseal, recovery, auth method, HA, rotation and SIEM items are in and out of scope.
How we build
- We deploy OpenBao in your cloud accounts, data centers or isolated networks, with the storage backend chosen for your operating model.
- We configure auth methods per workload type, such as AppRole for servers and OIDC or Kubernetes login for pipelines and pods.
- We test failover, unseal procedures and restore from backup against the scope, and record the results for your review.
How we hand over
- You receive architecture, key custody, unseal and recovery runbooks, and policy documentation written for your operators.
- Audit log forwarding to your SIEM is documented with field mappings, retention settings and the evidence each control produces.
- Knowledge transfer sessions cover day-to-day operations, so your team can perform rotation, upgrades and access reviews itself.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade planning follows the release lines your team chooses, with changes tested before they reach production.
- DeployOpen prepares systems, controls and evidence for compliance assessments; independent auditors issue any audit reports or certifications.
