Self-hosted secrets management for NIS2 cryptography

The cryptography policy is a governance document the entity writes and approves, so OpenBao does not produce it. Implementing Regulation 2024/2690 expects the policy to set the type, strength and quality of cryptographic measures for data at rest and in transit, the approved protocols and algorithms, and a review at planned intervals that accounts for the state of the art. The entity must maintain the approved versions, approval records, review dates and the reasons for each change. OpenBao's configuration files, auth policies and engine settings should be kept under version control so the written policy can be checked against the running setup. Ask your implementation partner to map each policy clause to a configuration item and a named owner.

OpenBao can list the secret engines, transit keys and PKI mounts it holds, and its audit logs record which keys were used and by whom. It does not assign business classification to data, so the entity must maintain an inventory that links each key to an asset, its classification level and its data owner. Implementing Regulation 2024/2690 asks that key management cover generation, certificates, distribution, storage, activation and deactivation dates, so the inventory should record those dates alongside each key. Reconcile the OpenBao listing with the entity's asset register at regular intervals, because keys created outside OpenBao will not appear in its output.

Inspectors typically ask for evidence that keys and credentials were changed on schedule and revoked when compromised. OpenBao produces this evidence through its audit devices, which record requests and responses for key rotation, lease creation and revocation, and bulk revocation. Dynamic secrets are leased and revoked automatically, which gives a clear record for short-lived credentials. The entity must define rotation intervals and compromise procedures, then keep the change tickets and incident records that show those procedures were followed. Confirm with your partner how audit records are exported and retained, since the on-disk audit log alone rarely satisfies a supervisor.

Supervisors expect proof that key material can be recovered, not only that backups exist. For OpenBao, the backup target depends on the storage backend, either integrated storage (Raft) or PostgreSQL, and the unseal and recovery material must be backed up separately under controlled custody. The entity must keep dated restore test records, the scope of each test, the results and the corrective actions. Kubernetes context matters if OpenBao runs on a cluster: etcd should have a backup plan, and Kubernetes documents etcdctl snapshot save for backups and etcdutl for restores. Ask for restore tests to be performed in a separate environment and recorded as evidence.

The entity must be able to show who can read, use or administer each key, who approved that access, and when it was reviewed. OpenBao supports auth methods such as AppRole, JWT/OIDC, Kubernetes, LDAP, TLS certificates and login MFA, and access is expressed through policies attached to tokens or identities. OpenBao documents Userpass for developer machines and AppRole for servers, which helps separate human and workload access in the records. The approval workflow itself usually lives in the identity governance or ticketing system, so the entity must link each policy change to its approval. Ask your partner to export current policies and reconcile them with the access review records.

The retention period is set by the entity's national transposition law, its sector rules and its own risk policy, so confirm it with the national competent authority and legal counsel before setting it. OpenBao writes audit records to the audit devices the operator enables, and those records must be forwarded to storage that the entity controls, such as a SIEM or log archive. Protect those logs against tampering and restrict who can read them, because they show key use. Plan for storage growth, since audit volume scales with secret read frequency. Confirm with your partner how log integrity is verified and how log forwarding is tested after upgrades.

Assessors look for a documented design that keeps key services available and recoverable, with tested failover. OpenBao uses an active node that holds a lock in the data store, with standby nodes, and integrated storage (Raft) and PostgreSQL are the officially supported HA backends. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. If OpenBao runs on Kubernetes, the kubeadm guidance calls for at least three control plane nodes and a TCP load balancer on port 6443, and etcd should use an odd number of members, with five recommended in production. The entity must document recovery objectives, failover tests and the unseal process, and confirm these details with its partner against the chosen version.

DeployOpen does not publish a price list. A quote follows from a written, fixed scope, and the main cost drivers are the number of applications and pipelines that need secrets, whether the cluster must run in high availability, whether keys must sit in hardware security modules, how much existing secrets sprawl needs to be migrated, and how many policies and audit integrations must be built. Costs fall into two groups: one-time work (design, deployment, integration, documentation and evidence preparation) and recurring costs (infrastructure, operations, upgrades and any retainer). Ask each bidder to separate those groups, to state which of your applications are in scope, and to list the assumptions behind the quote, including what your team provides. The NIS2 text itself does not set a cost, so treat any figure you see from a third party as a starting point for your own scoping.

The duration depends on scope, so DeployOpen agrees a timeline in the written scope before work starts. The variables that matter most are the number of systems that hold encryption keys or credentials, the storage backend and high availability design, the number of applications that must be re-pointed to the new manager, and how quickly your teams can approve the cryptography policy and key lifecycle rules. To keep the schedule realistic, prepare an inventory of key-bearing systems, the current key custody and rotation practice, your asset classification, and named owners for approvals. Ask each partner to show the phases, the decision points where your input is needed, and which evidence will exist at the end of each phase.

Yes, many organizations can, provided they have people who understand cryptography, Kubernetes or Linux operations, identity integration, and incident response for key compromise. The NIS2 cryptography requirements in Implementing Regulation 2024/2690 cover policy, key generation, storage, rotation, compromise, revocation, recovery, backup, destruction and logging, so the work spans governance as well as engineering. Internal teams often struggle with the policy and evidence side, with testing backup and recovery under realistic conditions, and with keeping pace with upgrades. A partner can take on any part of that work under a fixed scope, and the split of responsibilities should be written down so that no key lifecycle step is left without an owner.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. NIS2 also creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, and the exact expectations depend on your Member State's transposition law and on whether your entity is classified as essential or important. Ask any partner which evidence they will produce, how that evidence maps to your national authority's expectations, and who signs off on it, and confirm with your legal or compliance advisers which assessments apply to you.

No. NIS2 is a directive, so entities are bound through national transposition laws, and the technical requirements in Implementing Regulation 2024/2690 are written as outcomes rather than product names. The regulation asks for an approved cryptography policy, key management that covers the listed lifecycle stages where appropriate, and periodic review. Products such as OpenBao, Vault or Infisical are options that can support those outcomes, and each has different licensing and operating characteristics. Choose a platform based on your asset classification, your sovereignty and licensing requirements, and your operating capacity, then document how it meets each requirement.

Hardware security modules are needed when your policy requires keys to be held in tamper-resistant hardware, and the NIS2 text does not mandate them in all cases. Your cryptography policy sets the required strength and quality of measures according to asset classification, so the HSM decision should follow from that classification and from any sector rules that apply to you. An HSM adds hardware purchase or rental, integration effort, redundancy design, and specialist operations. Confirm with your partner how the chosen storage and unseal design interacts with the HSM, and ask for the component list and the recovery procedure in the quote.

Ongoing support covers the work that keeps the platform and its evidence current after the initial rollout. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope of each retainer is set in writing. Typical items include applying OpenBao releases, reviewing the cryptography policy at planned intervals as Implementing Regulation 2024/2690 requires, rotating and revoking keys, testing backups and recovery, adding new applications, and refreshing evidence for assessments. Ask the partner which items are included, how urgent fixes are handled, what happens during a key compromise, and which items would be billed separately under a new scope.

The client provides the information and decisions that the design depends on. Prepare an inventory of systems and applications that use secrets, certificates or encryption keys, your current asset classification, the existing key custody and rotation practice, network and identity constraints, and the names of the people who will approve the policy and the recovery procedure. Access to the target infrastructure, whether cloud accounts, data centers or air-gapped networks, must be arranged in advance, as must a decision on who holds unseal and recovery material. Agree these inputs in the written scope so that delays are visible early and the timeline reflects them.