Self-hosted secrets management for PCI DSS key management: the short answer
OpenBao can centralize the storage, access, rotation and audit trail for the cryptographic keys and application passwords that PCI DSS Requirements 3.6, 3.7 and 8.6 address, but it cannot make the key management decisions for you. In a payment environment, cardholder data keys often sit in key files, database encryption settings and vendor consoles, while application and service account passwords are embedded in scripts, cron jobs and configuration files. A self-hosted OpenBao cluster, deployed in your own cloud account or data center, gives you one place to hold secret and key material encrypted before it reaches storage, to limit which identities can read each secret through policies, to issue short-lived dynamic credentials where a target system supports them, and to log every read and write. That covers much of the technical work behind 3.6.1 key protection, the secure storage expectations in 3.7, and the move away from hard-coded passwords in 8.6.2. Key ceremonies, the choice of custodians, split knowledge and dual control arrangements, whether keys must live in a hardware security module, and the cryptoperiods you set all remain organizational decisions that the standard expects you to document and own.
PCI DSS is enforced by the individual payment brands, not by the PCI Security Standards Council, which owns and maintains the standard. Your assessment is documented either in a Report on Compliance completed by a Qualified Security Assessor or in a Self-Assessment Questionnaire, each backed by an Attestation of Compliance. Version 4.0.1 is the only active version, following the retirement of v4.0 on 31 December 2024, so any design work should map to that version. DeployOpen plans, implements and hardens the OpenBao deployment and prepares the configuration, access reviews and evidence an assessor will ask for, but DeployOpen does not issue validation, and no certificate or report from us substitutes for an assessment. Before scoping, confirm with your acquirer or payment brand which validation route applies to your entity, and ask your assessor how they expect OpenBao audit logs and policy exports to be presented.
Which PCI DSS 3.6, 3.7 and 8.6 requirements OpenBao must cover and how to configure it
This table maps each PCI DSS requirement in scope to what the OpenBao deployment must do and the configuration that supports it. Read the applicability and dependency columns first, because some rows need an HSM or manual custodian procedures that OpenBao does not replace. The main takeaway is that most evidence comes from how the cluster, policies and audit devices are configured, while key ceremonies and custodian paperwork stay with the entity.
| Requirement | What the function must do | Configuration steps in OpenBao | Dependency or applicability |
|---|---|---|---|
| 3.6.1 Key protection procedures | Restrict key access to the fewest custodians, keep key-encrypting keys at least as strong as the keys they protect, and keep keys in the fewest locations and forms. | Transit or KV engines per key class, least-privilege policies bound to named roles, and a separate key-encrypting key for the cluster barrier. | Procedures are written by the entity. Custodian lists and key strength decisions are not enforced by OpenBao alone. |
| 3.6.1.1 Cryptographic architecture | Document algorithms, protocols, keys, key strength, expiry, usage and an inventory of HSMs or other secure cryptographic devices. | Maintain a key inventory from transit key listings and mount metadata. Record key type, version, and rotation settings in the architecture document. | Applies only to service providers. Entities that are not service providers may treat it as not applicable, subject to their assessor. |
| 3.6.1.2 Secret and private key storage | Keep secret and private keys encrypted under a separate key, inside a secure cryptographic device, or as at least two full-length components. | Use the barrier with a separate key-encrypting key, or seal with an HSM or cloud KMS where the entity permits. Exportable flags kept off for transit keys. | Needs an HSM or split-component procedure if the entity chooses those options. Confirm the seal design with the assessor. |
| 3.7 Key generation, distribution, storage and changes | Generate strong keys, distribute and store them securely, change keys at defined cryptoperiods, and retire compromised keys. | Transit key rotation with minimum decryption versions, key deletion policy, and scheduled rotation jobs tied to the cryptoperiod set in the risk analysis. | Cryptoperiods are defined by the entity. Retirement records and key ceremonies are manual evidence. |
| 3.7.6 Split knowledge and dual control | Require two or more people for each manual cleartext key operation, such as unseal or recovery key handling. | Use Shamir key shares with a threshold above one, separate share holders, and recovery key policies that require quorum. | Depends on manual custodian procedures. OpenBao enforces the threshold, but the people and their separation are the entity's responsibility. |
| 3.7.8 Custodian acknowledgment | Record that each key custodian has accepted their responsibilities in writing or electronically. | Not configured in OpenBao. Keep a signed custodian register and link each share holder to a named identity. | Manual evidence held outside the platform. Assessors will ask for signed forms. |
| 8.6.1 Interactive use of system and application accounts | Allow interactive login for these accounts only in exceptional, approved, time-limited cases with individual accountability. | Use AppRole or Kubernetes auth for non-interactive workloads. Limit Userpass or LDAP login for named operators, with login MFA and short token TTLs. | Break-glass approvals and time limits are process controls. Audit device entries must tie each session to a person. |
| 8.6.2 No hard-coded passwords | Keep application and system passwords out of scripts, configuration files and custom source code. | Store credentials in KV paths or generate dynamic database credentials. Applications receive tokens through AppRole, with secret IDs delivered at deploy time. | Requires code and config scanning and remediation of existing files. OpenBao does not find legacy secrets by itself. |
| 8.6.3 Password change frequency and complexity | Change application and system account passwords at a frequency set by a targeted risk analysis and on suspected compromise. | Set rotation schedules or dynamic credential TTLs in the database and LDAP secrets engines. Use password policies for generated values and revoke leases on compromise. | The frequency comes from the entity's targeted risk analysis under Requirement 12.3.1. Confirm it before configuring rotation. |
| Audit and access evidence (supports 3.7 and 8.6) | Show who read, generated or rotated each key or secret, and that access reviews occurred. | Enable file or socket audit devices, forward logs to the SIEM, and review policy and token changes on a defined schedule. | Log retention and review cadence must be confirmed with the entity's assessor and the SIEM design. |
How OpenBao handles key generation, storage and cryptoperiods
OpenBao encrypts secret data before it is written to its storage backend, so the question for a PCI DSS assessor is less whether data is encrypted at rest and more how the keys that do the encrypting are generated, protected and rotated. In OpenBao, the barrier key encrypts everything written to storage, and that barrier key is itself protected by a seal. The seal choice and the unseal and recovery key design are the first decisions to document, because they determine who can bring the cluster back online and how many people must cooperate to do it. Requirement 3.6.1.2 accepts three forms of protection for secret and private keys: encryption under a separate key-encrypting key, storage in a secure cryptographic device such as an HSM, or at least two full-length key components or shares. Confirm with the OpenBao documentation for your chosen version which seal types and HSM integrations it supports, and treat any HSM support as a version and environment decision to verify in a test cluster before it appears in your cryptographic architecture.
Key/value storage and encryption as a service fit the key-encrypting key pattern in different ways. Key/value secrets are encrypted by the barrier, so application credentials and configuration secrets sit under a key that is never handed to applications. Encryption as a service lets applications send data to OpenBao for encryption and receive ciphertext back, which keeps the data-encrypting key inside OpenBao and out of application memory and files. For cardholder data protection, the practical check is whether the keys used to encrypt stored data are themselves wrapped under a key held separately and accessed only by named custodians. Define which mount paths and transit keys hold data-encrypting keys, which hold key-encrypting keys, and which policies allow each to be read, rotated or exported. Requirement 3.7.6 adds split knowledge and dual control wherever personnel perform manual cleartext key operations, so any manual unseal or recovery ceremony should be designed around that requirement from the start.
Cryptoperiods are operated through rotation and versioning of the keys you define, not by hoping that a single key lasts. Requirement 3.7 expects defined cryptoperiods, timely replacement of weakened or compromised keys and retirement of keys that should no longer be used. Set the cryptoperiod for each key class in your cryptographic architecture, then schedule and test its rotation, and confirm how OpenBao keeps earlier key versions so that older ciphertext can still be decrypted during a transition and then retired once data is re-encrypted. For a compromised key, the response is to rotate, re-encrypt affected data, revoke access tokens and leases tied to that key, and record the event for custodian review. Requirement 3.7.8 requires key custodians to acknowledge their responsibilities in writing or electronically, so the custodian list and acknowledgments should be produced as evidence alongside the rotation logs. Ask your implementation partner to demonstrate a rotation and a compromise response in a non-production cluster before the assessment period begins.
Open source platforms that fit PCI DSS key and credential control
PCI DSS key management depends on where keys are stored, who can reach them, and how human and workload access is authenticated. The cards below cover the secrets store, the open-source alternative to check, the licensing trap in Vault, the Kubernetes runtime and the identity layer for operators, which together determine what evidence an assessor will see.
OpenBao as the core store
OpenBao is the core candidate for storing and distributing application and system credentials, encryption keys and certificates in your own environment. It is licensed under MPL-2.0, is a Sandbox project of the OpenSSF, and v2.7.1 was published on October 1, 2026. Check how your team will meet the key-encrypting key and split custody expectations in Requirement 3.6.1.2, including whether unseal material sits in an HSM, and confirm the storage backend and high availability design you plan to run.
Infisical as an alternative
Infisical covers secrets, certificates and access and is licensed under MIT, except for content in ee directories, which carries a separate enterprise license. Its release v0.166.8 was published on October 15, 2026. Before choosing it for cardholder data environments, map each PCI DSS 3.7 control, including split knowledge, dual control and key custodian acknowledgment, to a feature you have verified, because the enterprise features that provide them may fall under the ee license.
Vault 1.15.0 and later
HashiCorp Vault from version 1.15.0 onward is licensed under the Business Source License 1.1 with IBM named as licensor, which the Open Source Initiative does not treat as open source. If your procurement policy requires open-source components, Vault is excluded from the design. Existing Vault estates should review the license terms with counsel and plan a migration path before expanding their use for cardholder key custody.
Kubernetes secret handling
Kubernetes stores Secrets unencrypted in etcd by default, so a cluster used for payment workloads needs deliberate configuration before it can hold cardholder-adjacent credentials. Enable encryption at rest, restrict list and watch access with least-privilege RBAC, and consider pulling secrets from OpenBao at runtime instead of storing them as cluster objects. Confirm who can read etcd snapshots, because backups inherit the same exposure.
Keycloak or ZITADEL for operators
Operators who unseal, approve or read keys need individual accounts and multi-factor authentication before they reach the secrets store. Keycloak (Apache-2.0) and ZITADEL (AGPL-3.0, with passkey support) both fit this role. Requirement 8.6.1 expects interactive use of system and application accounts to be exceptional and individually attributable, so confirm that the identity provider maps each human to a named OpenBao identity and records every approval.
Evidence assessors ask for and which component produces it
This table maps the evidence a QSA or internal assessor typically samples for PCI DSS 3.6, 3.7 and 8.6 to the component that generates it and what the assessor will pick. Use it to decide which logs, exports and records must be designed in from day one rather than reconstructed before an assessment. Where a producing component is a design choice, the table names the artifact to confirm with your assessor.
| Evidence item | Producing component | What the assessor samples |
|---|---|---|
| Cryptographic architecture inventory (3.6.1.1, service providers) | Maintained engineering document, cross-checked against OpenBao mount and key listings | Algorithms, key strength, expiry and usage for each key, matched against live OpenBao configuration |
| Key inventory with cryptoperiod and usage (3.7.1, 3.7.4) | OpenBao transit and PKI key metadata, exported on a schedule | Sample of keys: creation date, rotation history, and whether the stated cryptoperiod was honored |
| Key-encrypting key separation and storage form (3.6.1.2) | OpenBao seal configuration and unseal share custody records | Evidence that keys are encrypted under a separate key, held in an HSM, or split into two or more components |
| Split knowledge and dual control logs (3.7.6) | OpenBao audit device entries for unseal and root token operations, plus custodian sign-off records | Two distinct custodians recorded for each manual cleartext operation, with timestamps |
| Custodian acknowledgment records (3.7.8) | Signed or electronic acknowledgment stored in the HR or GRC system, referenced from the key custodian list | Each named custodian has an acknowledgment dated before first key access |
| Audit device logs for key and secret access | OpenBao file or socket audit devices, shipped to a SIEM such as Wazuh | Sample of reads and writes on key paths, confirming who, when and from where, with no raw secret values in logs |
| Password rotation records for application and system accounts (8.6.3) | OpenBao dynamic or static role rotation history, plus change tickets for manual rotations | Rotation dates against the interval set in the targeted risk analysis, and rotations triggered by suspected compromise |
| Interactive use exceptions for system accounts (8.6.1) | OpenBao policies and auth method configuration, plus approval records | Approved, time-limited exceptions with named individuals and expiry dates |
| Scans showing no hard-coded credentials (8.6.2) | Secret scanning in Git history and CI, and repository scan reports | Scan scope covering scripts, configuration files and source, with findings closed or justified |
| Policy and access control exports | OpenBao policy files kept in Git, and Kubernetes RBAC exports for workloads that reach OpenBao | Least-privilege policies matched to roles, and version history showing approved changes |
| HA and backup restore test records (supports 3.6 and 3.7 continuity) | Test runbooks and restore logs for integrated storage or PostgreSQL backups | Dated restore test with the result, and proof that restored keys still unseal under the documented custody model |
How the scope differs for merchants, processors and service providers
Merchants and acquirers that store, process or transmit cardholder data must meet the key protection and password requirements that apply to their environment, including Requirements 3.6.1, 3.6.1.2, 3.7 and 8.6. Requirement 3.6.1.1, which calls for a documented cryptographic architecture, applies only to service providers, so a merchant does not produce that document for this topic. The payment brands and the acquirer decide which validation template and evidence set apply, and the PCI SSC does not enforce compliance itself.
- Key protection still applies: Requirement 3.6.1.2 applies to any key that protects stored account data, whether or not the entity provides services to others.
- Manual key operations: Requirement 3.7.6 applies wherever staff perform manual cleartext key operations, so keys loaded by hand need split knowledge and dual control records.
- Application and system accounts: Requirement 8.6.2 covers scripts, configuration files and custom code that connect to payment systems, which is often where hard-coded passwords turn up.
- Evidence set: Expect the validation template your acquirer sets, its Attestation of Compliance, and your own key inventory, access reviews and rotation records.
Confirm with your acquirer which template and evidence they accept before you design the OpenBao layout.
Service providers carry the full set of requirements, including Requirement 3.6.1.1, which asks for a documented cryptographic architecture. That document must list algorithms, protocols, keys, key strength and expiry, key usage, and an inventory of HSMs and other secure cryptographic devices. For a self-hosted OpenBao cluster, it should describe the storage backend, the seal and unseal design, the encryption keys and any HSM involved. Service providers typically validate with a Report on Compliance from a Qualified Security Assessor or with the SAQ D for service providers, each with an Attestation of Compliance.
- Architecture document: Record each key, including root material, unseal material and transit keys, with its algorithm, strength, expiry and usage.
- HSM inventory: List every HSM or secure cryptographic device, including any used for auto-unseal or key wrapping, with its location and owner.
- Cryptoperiods: Define key change intervals for each key class and keep records showing the schedule was followed.
- Customer guidance: Requirement 3.7.9 asks service providers to give customers guidance on key handling, so publish it alongside the architecture.
Ask your assessor early which evidence they expect for the architecture document, because it must describe the deployed system and not only the intended design.
The customized approach lets an entity meet the stated objective of a requirement in a different way, and PCI DSS v4.x limits it to entities whose security and risk management are mature enough to justify it. It is not a shortcut. The entity must document the objective, explain how its design meets it, and produce evidence that the control works, and the assessor must agree that the approach is valid. Requirement 8.6.3 already depends on a targeted risk analysis under Requirement 12.3.1, so that analysis is a natural starting point.
- Eligibility: Only entities meeting the standard's maturity conditions can use the customized approach, and the assessor decides whether you qualify.
- Objective statement: Write what the original requirement is meant to achieve, such as keys staying unreadable outside controlled custody, and show how the custom design achieves it.
- Evidence set: Expect design documentation, a risk analysis, test results and ongoing monitoring of the custom control in place of the standard defined-approach evidence.
- Separate route: Compensating controls cover requirements that cannot be met as written, so confirm with your assessor which route fits your case.
Confirm with your Qualified Security Assessor that the customized approach is available to you and agree the objective statement before building anything.
An OpenBao cluster falls into PCI DSS scope when it stores, processes or transmits cardholder data, or when it could affect the security of the cardholder data environment. A cluster that issues credentials for payment applications or holds their keys will usually be in scope, even if it never sees a card number. The boundary decision shapes how much of the platform the assessor reviews, so it should be made before the architecture is drawn.
- Dedicated or shared cluster: A cluster that serves only payment workloads has a smaller, clearer boundary than one shared with unrelated systems.
- Network segmentation: Document the controls that separate the OpenBao cluster from non-payment networks, and test them as part of the assessment.
- Administrator access: Staff who can unseal the cluster or change policies belong in the scope of access reviews and dual control records.
- Logs and backups: Audit logs and backup copies of the storage backend carry the same protection needs as the secrets they describe.
Ask your assessor to confirm the scope boundary in writing, including backups and any disaster recovery site, before you finalize the design.
What OpenBao alone does not satisfy in PCI DSS
OpenBao can hold and protect keys and secrets, but several PCI DSS obligations sit with people, procedures, hardware and application code. The cards below cover the gaps a secrets manager cannot close by itself, and what to confirm before assessment.
Custodian acknowledgment and split knowledge
Requirement 3.7.6 requires split knowledge and dual control wherever personnel perform manual cleartext key-management operations, and Requirement 3.7.8 requires key custodians to formally acknowledge their responsibilities in writing or electronically. OpenBao can enforce unseal shares and policies, but it cannot decide who the custodians are or record their signed acceptance. Confirm the named custodian roster, the procedure for each manual operation, and where acknowledgments are kept for the assessor.
HSM procurement for hardware-bound keys
Requirement 3.6.1.2 allows secret and private keys to be stored encrypted under a separate key-encrypting key, inside a secure cryptographic device such as an HSM, or as at least two full-length key components. OpenBao's encryption does not by itself satisfy the hardware option. If your design relies on an HSM, the hardware is a separate purchase and integration project. Confirm which of the three storage options each key class will use before choosing a design.
Targeted risk analysis for password changes
Requirement 8.6.3 requires passwords for application and system accounts to change at a frequency set by a targeted risk analysis under Requirement 12.3.1, and immediately on suspected compromise. OpenBao can rotate many credentials on a schedule, but the interval itself is a documented decision the business must make and defend. Ask your QSA which analysis they will expect to see and who signs it off.
Application code changes to remove hard-coded passwords
Requirement 8.6.2 prohibits hard-coded passwords in scripts, configuration files and custom source code. Moving a secret into OpenBao does not remove the old copy from repositories, build images, job definitions or home directories. Each application needs a code or configuration change to fetch credentials at runtime, and older copies must be found and removed. Scan repositories and configuration stores before the assessment and track each change to closure.
Exception process for interactive use of accounts
Requirement 8.6.1 limits interactive use of system and application accounts to exceptional, approved, time-limited cases with individual accountability. OpenBao can issue short-lived tokens and log each read, but it cannot approve the exception or tie a human to it on its own. Build a request, approval and expiry workflow, and confirm that the audit trail links each interactive session to a named person.
Assessment documents come from the assessor
A Report on Compliance is completed by a Qualified Security Assessor, and a Self-Assessment Questionnaire comes with an Attestation of Compliance. No software product issues either document, and a certificate from a vendor is not accepted as validation. Your deliverables from DeployOpen are evidence and configuration records that support the assessment. Confirm with your assessor or acquirer which evidence format and scope they require.
Questions buyers ask about PCI DSS key management with OpenBao
What drives the cost of running OpenBao for PCI DSS key management?
The main cost drivers are the number of applications and systems that need secrets, the high availability design, whether keys must sit in an HSM, how many existing secrets must be migrated out of scripts and configuration files, and how much custodian process design the assessment requires. Costs fall into one-time work (architecture, build, migration, documentation, ceremonies) and recurring work (patching, upgrades, backups, restore testing, access reviews and evidence collection). Software licensing is not the main variable, because OpenBao is licensed under MPL-2.0. Ask any implementation partner for a quote that separates these items, states which applications are in scope, and lists the HSM and high availability assumptions behind each line.
Can an experienced platform team run OpenBao for PCI DSS on its own?
An experienced platform team can deploy and operate OpenBao internally, provided it has people who understand cryptographic key lifecycle, high availability and secure unseal design. The harder part is the surrounding work: documented key procedures, split knowledge and dual control ceremonies, custodian acknowledgments, rotation records and evidence that a Qualified Security Assessor can test. That work takes time from security, compliance and application teams, and it is easy to underestimate. A common middle path is to have a partner design and build the environment and procedures while the internal team takes over operations and evidence collection after handover. Confirm the division of responsibilities in writing before work starts.
What does the client need to provide for a PCI DSS key management project?
The client needs to name the key custodians, who must formally acknowledge their responsibilities under Requirement 3.7.8, and assign an owner for the targeted risk analysis that sets password change frequency under Requirement 8.6.3 and the 12.3.1 process. Application owners must confirm which systems use hard-coded or file-based passwords, which service accounts they run, and how each application can be changed to read secrets from the platform. The client also needs an accountable owner for key custody, access to the cardholder data environment inventory, and time from the teams that will run the ceremonies and the evidence collection. Without these named roles, the design usually stalls at the custodian and ownership stage.
Is OpenBao enough for Requirement 3.6.1.2 without an HSM?
OpenBao can meet the storage condition in Requirement 3.6.1.2 without a hardware security module if secret and private keys are stored encrypted under a separate key-encrypting key, or split into at least two full-length key components or shares. Using an HSM is one of three permitted options, not a universal requirement. The deciding factors are the entity's risk analysis, how the unseal and recovery material is protected, where the key-encrypting key lives, and whether the assessor accepts the design. Note that OpenBao's own auth and encryption features do not replace the procedural requirements in 3.7. Confirm the chosen storage approach with your QSA before design is frozen, and ask the partner to document how each option maps to the requirement.
How does a QSA's view of key management differ from the platform documentation?
Platform documentation explains how a feature works, such as encryption before storage, leasing, auth methods or high availability. A Qualified Security Assessor tests whether the entity's whole process meets the requirement, including who holds keys, how ceremonies are recorded, how cryptoperiods are enforced and how weakened or compromised keys are retired. A QSA will want documented procedures, evidence from the running system, and proof that the procedures are followed in practice. The PCI SSC allows the customized approach for entities with robust risk management, but that path requires the entity to show how its design meets the stated objective. Expect the assessor to ask for evidence samples from both the platform and the human processes around it.
Which PCI DSS evidence should a secrets management project produce?
Evidence typically includes the key inventory and cryptographic architecture (for service providers under 3.6.1.1), key custodian lists and signed acknowledgments, dual control and split knowledge ceremony records, access policies and their reviews, audit logs of secret and key access, rotation records for application and system passwords, and tested backup and restore results. For Requirement 8.6.2, evidence also includes scans or reviews showing that scripts, configuration files and custom source code no longer contain hard-coded passwords. The exact evidence list depends on the entity's role and its SAQ or ROC, so ask the assessor to confirm it early. Partners prepare controls and evidence for assessment, but only the assessor can issue the attestation.
How do teams move hard-coded passwords out of scripts and files?
Teams start by inventorying where passwords live, including scripts, configuration files, custom source code, container images and CI variables, then rank them by systems in the cardholder data environment. Each application is then changed to request credentials from OpenBao at runtime, using an auth method that fits the workload, such as AppRole for servers or Kubernetes and JWT/OIDC for pipelines and clusters. Interactive use of system and application accounts under Requirement 8.6.1 should be limited to approved, time-limited cases with individual accountability. Old credentials must be rotated once the application no longer depends on them, which is often where the work takes longest. Ask partners how they handle applications that cannot be changed quickly.
Which PCI DSS version should a key management design target?
PCI DSS v4.0.1 is the only active version, since v4.0 was retired on 31 December 2024 and v3.2.1 was retired on 31 March 2024. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to start the next iteration, but as of October 2026 it had announced no release date for a new version. Design documents should cite v4.0.1 requirement numbers, and the team should monitor PCI SSC announcements so that a future revision does not invalidate the design late in the project. Ask your QSA or partner to confirm which requirements are future-dated for your assessment and when they became effective.
How DeployOpen scopes, deploys and evidences PCI DSS key management
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including OpenBao for PCI DSS key management. We start from a written scope that maps each control to a configured feature, an owner and an evidence artifact, so the cardholder data environment team and the assessor can trace every key and password decision.
How we scope
- Inventory every key, secret and application or system account that touches cardholder data or the cardholder data environment.
- Record the defined or customized approach for Requirements 3.6, 3.7 and 8.6 with the assessor's expectations agreed early.
- Agree in writing which custodians, roles and dual control steps the fixed scope covers, and what stays with your team.
How we build
- Deploy OpenBao in your cloud account, data center or isolated network, with the storage backend and HA design confirmed against your recovery targets.
- Configure auth methods, policies and key custody so custodians hold split knowledge and no single person can unseal or export keys.
- Remove hard-coded passwords from scripts, configuration files and source code, then test rotation and audit logging in a non-production environment first.
How we hand over
- Deliver a cryptographic key inventory, key lifecycle procedures and cryptoperiod settings that map to the controls in scope.
- Document custodian acknowledgments, unseal and recovery procedures, and tested backup and restore runbooks for your team.
- Provide evidence packs of configuration, policies and audit logs for your QSA or internal assessor, noting that DeployOpen does not issue reports or attestations.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, aligned to OpenBao release changes.
- Re-run key rotation, restore and password change tests when the cardholder data environment or the risk analysis under 12.3.1 changes.
- Confirm with your assessor and payment brand which validation path applies before the next assessment cycle begins.
