Which NIS2 key management requirements OpenBao helps you meet
Under Article 21(2)(h) of NIS2, your essential or important entity must have policies and procedures for the use of cryptography and, where appropriate, encryption. OpenBao covers the technical generation, storage, revocation and logging controls that those procedures depend on. The cryptography policy, the operating procedures that staff follow, and any obligation this page does not address remain your organization's work. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans and information requests, and DeployOpen prepares systems, controls and evidence for that review without certifying them.
Implementing Regulation (EU) 2024/2690, point 9.2(c), asks for key management that covers, where appropriate, generation, certificates, distribution, storage, changing, compromise, revocation, recovery, backup, destruction, logging, and activation and deactivation dates. Use that list as your checklist. OpenBao's documented features map directly to some stages: key/value secrets are encrypted before they are written to storage, encryption as a service lets applications use keys for data they hold, leases revoke access automatically, and bulk revocation handles wider incidents. Certificate issuance through PKI, backup, recovery, destruction and activation dates depend on how you configure and operate the cluster. Confirm each one against the OpenBao version you deploy before you claim it in an assessment.
Three decisions come before the build. First, decide which keys OpenBao generates and holds, and which stay with a hardware or cloud key store or with your existing custodians, since integrations are covered on a separate page. Second, decide how the storage backend is backed up and restored, because encrypted data is only recoverable when storage and the keys that protect it are both intact. Your choice between integrated storage (Raft) and PostgreSQL also affects how easily your team can operate it safely. Third, decide who may authenticate and how. Match AppRole for servers, OIDC or LDAP for people, and login MFA to the access rules already in your policy.
Plan for the controls the platform cannot decide for you. Key changing schedules, compromise response, destruction rules and recovery exercises are procedures that people carry out, and their evidence comes from audit logs, tickets, change records and test reports. Ask DeployOpen or your own team to turn these into runbooks and to rehearse a revocation drill before an assessment. Review the ENISA technical implementation guidance for Implementing Regulation 2024/2690, published in June 2025, which gives examples of evidence and mappings to ISO/IEC 27001:2022 and NIST CSF 2.0. Also note that the Commission's January 2026 proposal to amend NIS2 is still a proposal, so confirm with counsel how any change would affect your obligations.
Mapping Implementing Regulation 2024/2690 point 9.2 to OpenBao capabilities
This table maps each key management item in point 9.2(c), and the protocol and algorithm requirement in point 9.2(b), to an OpenBao capability, a configuration step, or a documented process. Read the middle column for what the platform supports and the last column for what your policy and procedures must still define. Cells marked for confirmation need a check with the vendor or your own tests before you rely on them.
| Requirement | OpenBao capability or process | Configuration or confirmation needed |
|---|---|---|
| Generation and certificates (9.2(c)) | Process, with encryption as a service for cryptographic operations. Confirm with the vendor which key generation and certificate issuance features apply. | Define approved key types, sizes and issuing roles in policy. Flag certificate workflows for vendor confirmation. |
| Distribution and storage (9.2(c)) | Secret data is encrypted before it is written to storage. Auth methods such as AppRole, JWT/OIDC and Kubernetes control who receives access. | Choose integrated storage (Raft) or PostgreSQL. Use AppRole for servers and namespaces to separate tenants. |
| Changing (9.2(c)) | Dynamic secrets and leasing support short-lived credentials that are replaced rather than edited. Confirm how encryption key rotation is performed. | Set lease durations and rotation intervals in policy. Flag encryption key rotation steps for vendor confirmation. |
| Compromise and revocation (9.2(c)) | Leasing with automatic revocation and bulk revocation can invalidate affected credentials and leases in one operation. | Write a compromise runbook naming who triggers bulk revocation and how downstream systems are notified. |
| Recovery and backup (9.2(c)) | Process. Backup and restore method depends on the storage backend; the HA model uses an active node and standbys. | Document the backup procedure for your backend and test restores. Confirm recovery steps for unseal material with the vendor. |
| Destruction (9.2(c)) | Process. Confirm with the vendor how deleted secrets and old key versions are removed from the storage backend. | Define retention periods and destruction evidence in policy. Test deletion against backend copies and snapshots. |
| Logging (9.2(c)) | Process with audit logging. Confirm available audit devices, log content and tamper protection with the vendor. | Forward audit logs to your central logging platform. Set retention in line with your reporting and inspection needs. |
| Activation and deactivation dates (9.2(c)) | Leasing with automatic revocation can enforce time-bound access. Confirm whether it can record key activation and deactivation dates. | Map each key class to a validity period in policy. Flag any date tracking beyond lease expiry for vendor confirmation. |
| Protocols, algorithms and cipher strength (9.2(b)) | The policy sets approved protocols, algorithms and strengths. OpenBao enforcement depends on listener and client TLS settings; confirm supported options. | Define approved TLS versions and cipher suites in policy. Verify them on each listener with scans. Plan for cryptographic agility. |
How OpenBao covers the key lifecycle from generation to revocation
OpenBao covers several lifecycle stages directly: protected storage, time-bound credentials, encryption performed on the server side, and bulk revocation. Certificate issuance, key rotation procedures, backup verification and destruction are not covered by product features alone, and each needs confirmation against the current OpenBao documentation and your own runbooks before you cite them in a NIS2 policy. The stages below show where the product helps and where your procedures must carry the weight.
Storage protection comes first. OpenBao encrypts secrets and keys before they are written to the storage backend, so the Raft (integrated storage) or PostgreSQL data your operators can see is ciphertext. The root key is protected by the seal, and the choice of seal mechanism determines who or what can unseal the cluster after a restart. Decide which storage backend you will operate, where unseal material is held, and who may perform unseal. Confirm the supported seal options and their operational trade-offs in the current documentation, because the answer changes how you record the generation and storage controls for key material.
Dynamic secrets and leases address how long credentials remain valid. Instead of issuing a long-lived database password, OpenBao can generate a credential for a system such as PostgreSQL when a workload asks for one, and attach a lease that expires automatically. Set maximum lifetimes per role, define who may renew leases, and test that expired credentials stop working in the target system. Applications must handle renewal or re-requesting, so include that behavior in acceptance testing rather than assuming it.
Encryption as a service keeps application keys off workloads. Applications send plaintext to OpenBao and receive ciphertext, while the key material stays inside the cluster. In OpenBao this is typically handled by the transit secrets engine, which you should confirm against the current docs for supported algorithms and key versioning. Document which key types each data class uses, who may create or delete keys, how key versions are retired, and how applications are authorized through policies. Key rotation procedures for these keys are not automatic in every design, so write the rotation and re-encryption steps into your runbook and test them.
Revocation supports response to compromise. OpenBao can revoke leases individually or in bulk, which lets an operator cut off issued dynamic credentials and tokens for a path or role quickly. Plan the containment runbook in advance: who authorizes bulk revocation, which prefixes or roles map to affected systems, how revocation is logged, and how services recover. Backup verification and key destruction remain separate tasks. Confirm the restore test steps, backup scope, and the destruction method for retired key material against the current OpenBao documentation and your own procedures before the NIS2 evidence file is finalized.
What evidence OpenBao produces for NIS2 reviewers
Assessors and national authorities will ask for records that show how keys and secrets were governed, not only how they were configured. The six items below each answer a different question, from how the cluster is built to who can use which keys and how access was withdrawn. Confirm each item against the OpenBao version you run before promising it, and treat every artifact as one part of a larger body of evidence.
Server configuration files
The configuration files that define listeners, storage, seal and telemetry settings show how the cluster was built and which TLS and audit settings are in force. Keep them in version control with change approval, and have the platform team own them. Confirm that the audit devices you rely on are enabled in the version you run, and that any setting you cite can be traced to a reviewed commit. The file alone does not show that the running server matches it.
Auth method and policy definitions
Auth method mounts and access policies show which identities can request secrets and keys and which paths each identity may use. Export them from the live cluster on a fixed schedule and compare the export against the approved baseline. The security team should own the access model, while application teams own their role mappings. Confirm which authentication events and policy changes OpenBao's audit logging records in your version, because the policy text alone cannot show who actually used a key.
Namespace layout
Namespaces separate tenants or business units within one cluster, so the layout shows where keys for each scope are held and which administrators hold rights there. Document the hierarchy in a diagram tied to the scope of the cryptography policy, and refresh it whenever namespaces are created or retired. The platform team owns the diagram, with sign-off from each tenant owner. Confirm that namespace creation and administrative actions appear in audit output for your version before promising that record to a reviewer.
Lease and revocation records
Lease records and revocation events show how long issued credentials and dynamic secrets lived and how they were withdrawn when access ended or a key was suspected to be compromised. Export lease inventories and bulk revocation actions on a set cadence, and link each revocation to an incident or change ticket. The operations team owns this process. Confirm which lease and revocation operations are recorded in audit logs, and whether lease listings can be retrieved for a past date, before offering them as proof.
Storage backend and HA configuration
The storage backend and high availability settings show where encrypted data is kept, how many nodes take part, and how failover is handled. Record the backend choice, the HA mode it supports and the reason it was selected, along with backup and restore procedures. Infrastructure owners should review this record whenever the backend or node count changes. Confirm the version-specific HA and backup behavior in the OpenBao documentation and in your own restore tests, because a node diagram does not show that a restore works.
Cryptography policy document
The cryptography policy sets approved protocols, algorithms, cipher strength and usage practices for keys managed in OpenBao, and it is the reference the other artifacts should map to. Give it a named owner, review it on a schedule and after significant platform changes, and keep approvals and version history. Confirm which key lifecycle steps OpenBao logs and which must be covered by documented procedure, such as destruction and backup handling, before stating that the platform enforces the policy.
Where NIS2 scope and national law change the key management work
Whether NIS2 applies to your organization, and in what form, is decided by national law as much as by the Directive itself. NIS2 is Directive (EU) 2022/2555, adopted on 14 December 2022. Member States had to adopt and publish transposition measures by 17 October 2024 and apply them from 18 October 2024. Because a directive binds entities through national transposition laws, the obligations in Article 21(2)(h) on cryptography and encryption policy reach you in the form your Member State adopted. Article 5 also lets Member States adopt or keep rules that ensure a higher level of cybersecurity. A national law may therefore add stricter key handling rules, shorter timelines or wider scope than the minimum. For a group operating in several Member States, one OpenBao design may need country-specific variants of the policy and evidence set. Confirm with your national competent authority or counsel which law applies to each entity and what it adds.
Article 3 places each in-scope entity in one of two categories, essential or important. Both categories face the same risk-management duties under Article 21, including the cryptography policy and the key management controls that follow from it. The category changes how supervision happens, not the content of the duty. Essential entities are supervised ex ante, meaning authorities can act before an incident occurs. Important entities are supervised ex post, meaning authorities usually act once there is evidence of non-compliance. In practice, an essential entity should be able to produce its OpenBao configuration, key lifecycle procedures and access records without warning, while an important entity should have the same evidence ready, with a shorter lead time it can count on. Record the category you have assumed, the reason for it and the date of your last review, so the assumption can be checked by counsel.
NIS2 covers 18 sectors: 11 sectors of high criticality in Annex I and 7 other critical sectors in Annex II. Scope also depends on the service you provide. Commission Implementing Regulation (EU) 2024/2690 sets the technical and methodological requirements of the Article 21(2) measures for named provider types, including cloud, data center, managed service and managed security service providers, online platforms and trust service providers. If your OpenBao service is run for other organizations, or you operate a trust service, the regulation's key management requirements in point 9.2 are measured directly against your records. Other entities follow Article 21 through national law. ENISA's non-binding technical implementation guidance, published on 26 June 2025, gives examples of evidence and mappings to ISO/IEC 27001:2022 and NIST CSF 2.0. Use it to plan evidence collection, and confirm with your authority how it will be read.
On 20 January 2026 the Commission proposed targeted amendments to NIS2 (COM(2026) 13), including a new small mid-cap category. This is a proposal. It needs approval by the European Parliament and the Council, so the current Directive and national laws still apply. Plan your key inventory so the entity category, sector and service type can be changed without rebuilding the OpenBao layout. Ask counsel three questions before you budget: whether the proposal would change your category, whether your national law already follows a different threshold, and which date your authority will use as the reference point. Document the answers, and review them when the legislative position changes.
What OpenBao does not cover for NIS2 and what you must still document
NIS2 Article 21(2)(h) and Implementing Regulation 2024/2690 point 9.2 set cryptography and key management items that OpenBao can support technically but cannot complete alone. The six areas below are organizational and technical work that DeployOpen can help prepare, while your teams must own, approve and maintain the records.
Cryptography policy and algorithms
The regulation expects a policy that sets approved protocols, algorithms, cipher strengths and usage practices, with cryptographic agility where appropriate. OpenBao can enforce some choices through its secrets engines and TLS settings, but it cannot write or approve the policy. Check that the approved list matches the transit keys, PKI roles and TLS configurations you actually run, and record the owner and review cycle.
Compromise and recovery procedures
You need documented steps for key compromise and recovery. OpenBao's lease revocation and bulk revocation help with containment, but your procedure must name who declares a compromise, which keys and credentials are rotated, how unseal and recovery material is handled, and how services resume. Rehearse rekey and seal operations in your environment and keep recovery material separate from daily operator access.
Destruction and key date records
The regulation lists destruction, activation and deactivation dates among key management items. OpenBao can revoke access, but secure erasure of backups, snapshots and any copies held outside the cluster sits in your procedures. Maintain a register that records activation, deactivation and verified destruction for each key. Confirm which key deletion operations your chosen engines support before you write the procedure.
Staff roles and training
Key management depends on named people: operators who hold unseal or recovery material, administrators who approve policy changes and reviewers who examine audit logs. The regulation expects roles and training to be documented. OpenBao enforces policies on paths and tokens, but it cannot assign responsibility or prove that staff were trained. Keep a role matrix that maps OpenBao policies to job functions, along with training records and a leaver process.
Supplier and third-party key handling
When a provider operates infrastructure, hosts backups or runs a cloud key service, the key lifecycle extends into their systems. Document who generates, holds and destroys keys in each third-party environment, how their access is granted and logged, and what evidence the contract provides. If OpenBao relies on an external key store or cloud key service, confirm that integration for your chosen deployment and record the dependency and exit path.
Test evidence and platform baseline
Procedures count only when test records exist. Keep dated results from restore, rekey, compromise and destruction exercises, along with corrective actions. The OpenBao migration guide was tested only against Vault 1.14.1 community edition, so confirm the path for any other Vault version or edition you run. Also confirm certificate lifecycle coverage and hardware key store integration for your deployment before you claim them in your documentation.
Configuring OpenBao in the order a NIS2 review will test it
This sequence builds OpenBao from the cryptography policy outward, so each control a reviewer tests can be traced back to a written decision and a file or record that proves it. Each step names the artifact it leaves behind for the evidence file.
Set the cryptography policy and approved algorithms
The security owner and the compliance lead write the cryptography policy first, because every later setting should trace back to it. The policy lists approved protocols, algorithms, key lengths and usage rules for each data class, and it states how the organization will replace algorithms later, which is the cryptographic agility approach the implementing regulation describes where appropriate. The step closes when the policy is approved and the algorithm register is version controlled. Evidence: the signed policy, the approved algorithm register, and the review date.
Design the cluster, storage and namespaces
The platform team chooses the high availability backend, either integrated Raft storage or PostgreSQL, and documents the reason, including who will operate it and how it will be backed up. The team also maps tenants, such as business units or environments, to OpenBao namespaces so that policies and secrets stay isolated inside one cluster. The step closes when a topology diagram and a storage decision record show the node count, failure behavior and namespace layout. Evidence: the architecture diagram and the storage decision record.
Configure auth methods for each identity type
The platform team enables AppRole for servers and service workloads, and adds OIDC or Kubernetes auth where the identity provider or cluster already issues trusted identities. OpenBao recommends Userpass only for developer machines, so the team limits it to that group and enables login MFA where the method supports it. Each method is tied to a named owner and a documented onboarding path. The step closes when an inventory lists every auth method, its purpose and its owner. Evidence: the auth method inventory and the login configuration export.
Write least-privilege policies per role
The security engineers write OpenBao policies that grant each role only the paths and capabilities its workload needs, and they avoid broad wildcard access to secrets. Policy files live in version control, so every change has an author, a review and a history. The team tests each policy with a token from the matching role and confirms that requests outside its scope are denied. The step closes when a test run shows the expected allows and denials for each role. Evidence: the policy files in version control and the test output.
Enable dynamic secrets and encryption as a service
The platform team enables dynamic secrets engines for systems such as databases and Kubernetes, so workloads receive short-lived credentials instead of stored ones. It also enables the transit engine for encryption as a service, and sets the key lifecycle for each transit key, including generation, rotation, activation and deactivation dates. The team records who may create, rotate and retire keys. The step closes when a key register lists every transit key with its dates and owner. Evidence: the key register and the secrets engine configuration export.
Set lease, renewal and revocation controls
The security team sets default and maximum lease durations for each secrets engine and token type, so credentials expire on a known schedule. It confirms that leases revoke automatically when they end and tests bulk revocation on a non-production cluster, including the procedure for revoking all leases under a path or role. The team documents who can trigger revocation and how the action is logged. The step closes when a revocation test is recorded with its result. Evidence: the lease settings document and the revocation test record.
Enable audit devices and monitoring
The operations team enables at least one audit device and sends its output to a log store that the security team can query and that is retained under the organization's retention rules. It sets alerts for failed authentications, policy changes, seal events and unusual revocation activity. The team checks that audit entries record the requests a reviewer will ask about, such as who read or used a key and when. The step closes when a test event appears in the log store and an alert fires in the test scenario. Evidence: the audit device configuration, the retention setting, and the alert test record.
Test restore and run the compromise drill
The operations team takes a backup, restores it into a separate environment, and checks that secrets, keys, policies and auth configuration come back intact. The security team then runs a documented compromise drill, such as a suspected key or token exposure, and follows the written steps for rotation, revocation, re-issuance and logging. Each drill finding is assigned to an owner and tracked to closure. The step closes when the restore report and the drill report are signed and filed. Evidence: the restore test report and the signed compromise drill report.
Choosing storage and high availability for key material you cannot lose
The storage backend and high availability design decide how well your OpenBao key material survives a failed node, a corrupted volume or a lost site, so make that choice before you generate production keys. OpenBao's documented storage backends are integrated storage (Raft), PostgreSQL, PebbleDB and in-memory. The in-memory option holds data only in process memory and is not a choice for key material you cannot lose. PebbleDB is a local embedded store on one node. Integrated Raft storage keeps the replicated data inside OpenBao itself, so there is no separate database to run, but your team owns the Raft peer membership, snapshots and quorum recovery. The OpenBao storage documentation states that PostgreSQL is easier to operate safely than Raft, which is a useful signal if your database team already runs PostgreSQL with tested backup and point-in-time recovery.
The HA model works through a lock. One active node holds a lock in the data store and serves requests, while standby nodes forward or redirect client requests to the active node. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and OpenBao 2.7.0 extended that read capability to PostgreSQL. Read scaling helps with read-heavy workloads, but it does not turn standbys into writers, so write throughput and failover behavior still depend on the active node and the backend. Confirm which read paths your clients use and whether they can tolerate reads that trail the active node, using the current high availability documentation before you rely on them.
Point 9.2(c) of Implementing Regulation (EU) 2024/2690 lists backup and recovery among the key management elements to cover where appropriate, so the storage design is also evidence design. For each backend, ask your team to write down how a snapshot or database backup is taken, where it is stored, who can restore it, and how the unseal material and recovery keys are kept separately from the data. Then run a restore into an isolated environment and record the result, including the time to a working cluster and whether the restored keys decrypt existing data. A design that has never been restored is difficult to present as evidence, whatever the backend.
Use this checklist before you choose. Confirm the current storage and HA pages in the OpenBao documentation for the version you will deploy. Decide whether your organization can operate Raft peer management and snapshot restores, or whether a PostgreSQL service with a tested recovery process is the stronger fit. Define the number of nodes and failure domains, including whether a second site is required. Write the restore runbook and run it at least once per design change. Keep the results with your key lifecycle records so that auditors and your competent authority can see how keys are recovered, not only how they are generated.
Treat this section as a starting point for your own design. The trade-offs above depend on your infrastructure, your database and platform skills, your recovery time objectives and the OpenBao version you run. Verify the supported backends, the read scaling behavior and the operational guidance in the current OpenBao documentation, and base your final design on recovery tests in your own environment.
Questions buyers ask before hiring help for NIS2 key management
What drives the cost of OpenBao key management work for NIS2?
The main drivers are the number of key lifecycle stages you must cover under Implementing Regulation 2024/2690, point 9.2(c), the number of systems and applications that will request keys, certificates or encryption from OpenBao, whether you already run Vault and need a migration, the storage and high availability design, the cryptography policy and procedures you must write, and the evidence you must collect. Most of the cost is people time: architecture, build, integration with each system, document drafting and testing. Ask for a quote that shows each driver as its own line, so you can see what changes if the scope changes.
Which parts of OpenBao key management work are one-time and which recur?
One-time work usually includes scoping, cluster design and build, integration of the first set of systems, drafting the cryptography policy and procedures, and assembling the first evidence set. Recurring work includes rotation reviews, OpenBao version upgrades and testing of those upgrades, restore tests for backups, access reviews, evidence refresh as systems change, and any ongoing support. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Ask the quote to separate one-time and recurring items, and to state what triggers each recurring item.
What does our organization need to provide during the engagement?
You need named owners for key management, a person who can approve the cryptography policy, and access to the cloud accounts, data centers or air-gapped networks where OpenBao will run. Your team should also provide network and DNS changes, change windows for production work, contacts for the identity provider and each application owner, and sign-off on the design before build starts. Missing owners or slow approvals are common causes of delay, so confirm these names and approval steps in the written scope before work begins.
Can our internal team implement NIS2 key management without an outside partner?
Yes, an internal team can do this, because OpenBao is open source under the MPL-2.0 license and its documentation is public. The question is capacity and skills. The work requires experience with high availability storage, PKI, authentication methods, audit logging and writing procedures that cover each lifecycle stage. Many organizations split the work, keeping policy ownership in-house and bringing in outside help for the build or the evidence set. Review your team's skills against the scope before deciding, and confirm the gaps you find.
How long does an OpenBao key management engagement take?
Timing depends on the written scope, so no duration is given here. The factors that move the schedule are the number of systems to integrate, whether a Vault migration is involved, the storage and high availability design you choose, and how quickly your approvers sign off on the policy and design. Ask for a timeline in the written scope that lists milestones, dependencies and the owner of each approval. DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Does DeployOpen certify that our organization complies with NIS2?
No. NIS2 does not create a certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. DeployOpen plans, builds and documents the key management controls and prepares the evidence for an assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. Ask your national authority and your auditor which evidence they expect.
Is OpenBao certified for NIS2 or Implementing Regulation 2024/2690?
Certification and attestation are issued by independent bodies, not by the OpenBao project itself. OpenBao is an open source secrets manager and a Sandbox project of the Open Source Security Foundation under Linux Foundation stewardship. Using it does not make an organization compliant by itself. Your evidence should show how your configuration, policies, procedures and logs meet the requirements. Confirm with your assessor which artifacts they accept before you design the evidence set.
What should engineers check before choosing a storage backend for an OpenBao HA cluster?
Start with the supported high availability backends: integrated storage (Raft) and PostgreSQL. The OpenBao documentation describes PostgreSQL as easier to operate safely than Raft. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. Check your team's experience with each backend, how you will take and restore backups, how failover will be tested, and how the seal and unseal process will be handled. Confirm each point against the current OpenBao documentation for the version you plan to run.
How DeployOpen scopes, delivers and supports NIS2 key management work
DeployOpen treats OpenBao for NIS2 cryptography and key management as a documented engineering engagement, not a product installation. We map the key lifecycle your cryptography policy must cover, build it inside infrastructure you control, and hand over the procedures and evidence your team and assessors will need. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- Written scope lists which key lifecycle stages from Implementing Regulation 2024/2690 point 9.2(c) OpenBao will cover.
- We confirm which applications, services and certificate types will consume keys and secrets from OpenBao.
- Scope states which controls remain with your policies and which we configure, so responsibilities are unambiguous before work starts.
How we build
- We design the OpenBao deployment, storage backend and high availability layout against your data center or cloud constraints.
- Key generation, rotation, revocation and recovery procedures are configured and tested in a non-production environment first.
- Audit logging is routed to your log platform, and log completeness is verified with test events before go-live.
How we hand over
- You receive runbooks for key generation, rotation, compromise response, revocation, backup and destruction.
- Documentation maps each configured control to the lifecycle stage and policy clause it supports, for your internal assessors.
- Knowledge transfer sessions cover administration, unseal and recovery steps, and the evidence your team must retain.
How we support
- Ongoing support, upgrades and periodic testing are available as a retainer after handover.
- Upgrade planning reviews OpenBao release notes and the migration guide before any change to a production cluster.
- We confirm with you which evidence needs refreshing each review cycle, and which items need an independent auditor or competent authority to assess.
