OpenBao for PCI DSS key management

OpenBao's encryption as a service lets an application send plaintext to OpenBao and receive ciphertext back, while the data-encrypting work happens inside the OpenBao cluster. For requirement 3.6.1, that design matters because the application team does not need to hold raw key material to encrypt or decrypt cardholder data. The key stays inside the OpenBao boundary, and the application holds only a policy-scoped token that permits specific encrypt and decrypt operations on named keys. Key/value storage is a separate feature: OpenBao encrypts those values before writing them to the storage backend, which helps with data at rest, but the transit style of encryption as a service is what keeps key use out of application code.

This arrangement helps with the requirement's core goals of restricting key access to the fewest custodians and keeping keys in the fewest locations and forms. Access to key material can be limited to a small set of OpenBao administrators and a few service identities, and each application can be granted only the keys it needs through its own policy. Because applications call a service rather than copying keys into configuration files or container images, the number of places a key exists falls. Pair this with the auth method decisions made for servers and workloads so that the identities allowed to call encryption endpoints are themselves tightly controlled and logged.

Encryption as a service does not remove the need to protect the keys that protect the data. Requirement 3.6.1.2 asks that secret and private keys be stored encrypted with a separate key-encrypting key, inside a secure cryptographic device, or as at least two full-length key components or shares. OpenBao's own root key and unseal material are the key-encrypting layer here, so you must document how that material is generated, split, distributed, stored and used. Decide who holds each unseal share, where they are kept, and how the key-encrypting keys are kept separate from the data-encrypting keys they protect. Requirement 3.7 procedures for split knowledge, dual control and custodian acknowledgment also apply to these operations and should be written as operating procedures, not left to tribal knowledge.

Before you cite any seal configuration to an assessor, confirm the exact options against the OpenBao version you deploy and its current documentation. Check which seal types are supported in that release, whether an HSM or cloud key store seal is available for it, and how the seal is configured and tested. Do not assume that a feature described in general terms, or in another version's docs, is present in your build. Record the version, the seal configuration, and the evidence of testing in your key management documentation so the assessor can trace the claim to the running system.

The practical work is to map the design to evidence. Confirm which transit keys exist, what each one protects, which policies grant encrypt and decrypt rights, and which custodians can rotate or export material. Keep audit logs of key operations and review who holds administrative access. Where the design relies on a customized approach rather than a defined approach, document the objective being met and how it is verified, since the assessor will need that rationale. A qualified assessor decides whether the controls satisfy the requirement, so treat this section as input to your own evidence set rather than a finding of compliance.

Requirement 8.6.2 prohibits hard-coded passwords in scripts, configuration files or custom source code for application and system accounts, and it has been required since 31 March 2025. OpenBao addresses the runtime side of this requirement by issuing credentials when an application asks for them, instead of leaving a password in a file. Dynamic secrets for databases and Kubernetes create credentials on request, and OpenBao tracks each one as a lease that it revokes automatically when the lease ends or when an operator revokes it in bulk. An application that retrieves its database login at startup no longer needs a static password in its configuration, and the credential can be rotated without a code change.

The auth method decides how each workload proves its identity before OpenBao issues anything. For servers, OpenBao recommends AppRole, which uses a RoleID and a SecretID that the application presents at login. Kubernetes auth lets pods authenticate with their service account identity, JWT/OIDC lets workloads that hold identity tokens from your provider sign in, and TLS certificate auth lets clients authenticate with a certificate. OpenBao recommends Userpass for developer machines, so people working locally use a different path from servers. For each application, the question is which method its workload can present without storing a secret. AppRole still requires a SecretID to reach the server, so the team must design a delivery path, such as a wrapped or orchestrator-injected value, and confirm that it works in its environment.

OpenBao cannot find hard-coded secrets in your code on its own. It manages only the credentials that are enrolled with it. Before any cutover, the team must search source repositories, CI/CD variables, container images, Helm values, deployment scripts, scheduled jobs and server configuration for passwords, API keys and tokens that applications use. Expect findings in version history as well as in current files, because a credential removed from the latest commit may still be valid. Each finding needs an owner, a classification as an application or system account, and a rotation that happens after the new retrieval path is live. The scanning tools and rule sets are the team's choice, and someone who knows each application should triage the results.

Sequence the work one application at a time. Confirm that the application's database driver or client library can fetch a dynamic credential at runtime and reconnect when a lease expires, because a connection pool that keeps an old password will fail after revocation. Keep the legacy credential valid during cutover, then disable it once the new path is verified. Ask any implementation partner for a written inventory of hard-coded secrets, a per-application cutover plan and a list of the auth method assigned to each workload. Effort depends mainly on how many applications are involved, how many places each secret appears and how much application code must change to fetch credentials at runtime. Those drivers should be visible in the quote.

Keep evidence for the assessor. Record the inventory, the removal and rotation tickets, the auth method assigned to each workload, and the configuration that prevents static passwords from returning. Confirm with your Qualified Security Assessor or internal assessor how they will test 8.6.2 in your environment, because OpenBao's configuration alone will not show that no hard-coded password remains. Repeat the search after each release, since a new hard-coded value can appear in a pipeline change or an emergency hotfix.

The storage backend and high availability design you choose determine where encrypted key material lives, who can operate it, and how hard it is to recover it. For a PCI DSS key management deployment, that choice belongs in the key custody design, not in the infrastructure backlog. OpenBao's documented storage backends include integrated storage (Raft), PostgreSQL, PebbleDB and in-memory. Integrated storage and PostgreSQL are the two officially supported high availability backends. The storage documentation describes PostgreSQL as easier to operate safely than Raft, which matters if your operations team has stronger database skills than Raft cluster skills.

Both backends follow the same high availability model. One active node holds a lock in the data store and serves writes, while standby nodes forward or redirect requests to the active node. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended that capability to PostgreSQL. Read scaling is useful, but it changes which nodes handle traffic that may touch key metadata and policies. Confirm with your architects which read paths are acceptable on standbys, document the load balancer routing rules, and test failover with the same credentials and policies used in production.

If you are replacing an existing Vault deployment, the migration guide describes an in-place replacement of the Vault server process on all nodes, with configuration, endpoints and URLs unchanged. Three cautions apply to key custody. The guide states that the in-place replacement was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so an enterprise cluster needs its own validation plan. Clusters bootstrapped before Vault 1.3 may need a rekey before the move. Because OpenBao stopped using mlock in 2.0.0, the disable_mlock setting must be removed from configuration. Treat each of these as a gate in the change plan, with evidence retained for your assessor.

Storage migration is a separate exercise from the Vault to OpenBao replacement. If you later move from Raft to PostgreSQL, or the reverse, the procedure, downtime window, and the verification of sealed and unsealed state, audit devices and policies all need to be planned. The migration documentation for storage backends should be read against your exact OpenBao version, and the upgrade notes for each minor line should be checked before any change. Ask for a written rollback procedure that covers unseal material and backup restoration, because a failed backend move without a tested rollback can leave key custody unclear during an incident.

For the compliance file, record the chosen backend, the high availability topology, the read-scaling settings, the migration evidence, and the decision rationale. PCI DSS requirement 3.6.1 expects key storage to be minimized and protected, and requirement 3.7 expects documented key management procedures. A storage design that is clear in an architecture record and tested in a change record is easier to explain to a Qualified Security Assessor than one that exists only in configuration files. Confirm with your assessor how they expect those records to be retained and which evidence they will sample.

Document OpenBao key management controls against PCI DSS v4.0.1, which is the only active version of the standard. PCI DSS v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024 before that. Any evidence that cites v3.2.1 numbering, such as older requirement IDs for key handling, will not match the assessor's current template. Map each OpenBao control you rely on to the v4.x requirement it supports, including 3.6.1, 3.6.1.2, the 3.7 sub-requirements and 8.6.2, and record the version on every control matrix you produce.

The PCI Security Standards Council ran a request for comments on PCI DSS v4.0.1 from 3 June 2026 to 20 July 2026 to begin the next iteration of the standard. As of October 2026, the Council had announced no release date for a new version. Do not plan a key management project around a successor version date that has not been published. Instead, assign an owner to watch the Council's announcements, and re-check the version and requirement numbering before each assessment cycle so that the documentation describes the standard the assessor will apply on the day of review.

Under the defined approach, you show that the requirement is met as written. For requirement 3.6.1.2, for example, the documentation must show that secret and private keys are stored encrypted under a separate key-encrypting key, inside a secure cryptographic device, or as at least two full-length key components or shares. If OpenBao transit encrypts the data-encrypting keys and the key-encrypting key is protected by an OpenBao seal, write down exactly which seal arrangement you use, where its unseal material is held and who can access it. Ask your assessor whether that arrangement satisfies the wording of the requirement before you rely on it.

Under the customized approach, you meet the stated objective of a requirement in a different way. The standard allows this for entities with mature security and risk management. The documentation therefore has to name the objective, describe the OpenBao design that meets it, record the risk analysis that supports the design, and state how the design is tested and monitored over time. Compensating controls are a different route. They are used when a requirement cannot be met as written because of a documented technical or business constraint, and they are documented as a fallback for that requirement. Keep the two in separate sections of your evidence so the assessor can see which route you chose for each control.

Confirm with your assessor which Self-Assessment Questionnaire or Report on Compliance applies to your entity, because the answer depends on your role and how you handle cardholder data. The questionnaire D for service providers is the form that contains the 3.6.1, 3.6.1.2 and 8.6.2 wording referenced here, but your assessor may direct you to a different form. Ask whether the assessor accepts a customized approach for the OpenBao design, what evidence format they expect, and which Attestation of Compliance will carry the result. A compliance certificate will not serve as validation, so plan the evidence for the attestation the assessor will sign.