Hyperledger Besu security hardening guide

Why Hyperledger Besu security hardening is more than a config file

Hardening a permissioned Besu network covers five areas: which nodes may connect (node permissioning), which accounts may transact and what they may do (account permissioning), how node and signing keys are stored (key custody), which JSON-RPC and WebSocket interfaces are reachable and by whom (API exposure), and the network controls around all of them. Each area needs a documented decision, not only a setting. Every decision has to hold inside your own cloud accounts, data centers or air-gapped network, where your team, not a vendor, operates the controls. The question for your organization is whether those controls can be shown to work to a board, a regulator or an external auditor.

A default Besu node is built to start, sync and join a network quickly, not to meet a regulated security posture. Starting and syncing are the easy part. Besu's documentation states that the local node private key file is not encrypted, so anyone who can read the data directory can read the node identity. Deployments that need hardware-backed key storage can use a security module plugin, such as the Besu HSM plugin enabled with the --security-module option. Choosing and operating that plugin is a separate workstream with its own hardware, access procedures and recovery plan. Ask your security team now which key custody model applies to node keys and validator keys, because it shapes the network design.

Hardening spans three layers. Configuration covers the permissions file, JSON-RPC authentication settings, which APIs are enabled and the interfaces they listen on. Infrastructure covers network segmentation, host access, logging and the TLS layer. Besu does not terminate HTTPS natively, so a reverse proxy or gateway in front of nodes belongs in the design from the start. Evidence covers the records that show the controls operate: change history for permissions files, access logs, metrics and alerts (Besu can expose Prometheus metrics with the --metrics-enabled option), and tested restore procedures. Evidence is where many programs stall, because a correct file on disk proves little to an assessor without a record of how it was set, changed and checked.

Besu is open source under Apache 2.0, and the LF Decentralized Trust project page describes proof-of-authority consensus, QBFT or IBFT 2.0, for private networks. The maintainers have also removed features that many older networks depended on. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, and Besu 26.4.0 removed Clique consensus, so a pure Clique network can no longer start or produce blocks. Before you write any permissioning rules, confirm which permissioning model your network runs and check that it is supported on the exact release you deploy. DeployOpen plans, implements and documents these controls and prepares the evidence for assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that work.

Which Besu settings and files control access

Access to a Besu node is set by a small group of files, flags and interfaces. Each one decides who can join the network, who can transact, who can act as a node, or who can call or observe a node, so review them together because a permissive setting in one place can undo a restriction in another.

Node permissions configuration file

The node permissions configuration file controls which peers a Besu node will connect to, which restricts connections to known participants. Each node reads its own copy, so a membership change must reach every node that should honor it. Check that validator and RPC nodes list only the approved participants, that the file is version controlled, and that every change is reviewed. Confirm the exact option that points Besu at this file in the permissioning documentation for your release.

Account permissions configuration file

The account permissions configuration file governs onboarding, suspending accounts and restricting specific actions. Because it is applied locally on each node, confirm how updates are distributed and whether every node runs the same version before you treat a suspension as effective. The maintainers removed onchain permissioning in release 25.6.0, so confirm that a file-based approach is the one your release uses. Rehearse a suspension against each node type before go-live.

Local node private key file

The local node private key file holds the identity of a node. The Besu documentation states that this file is not encrypted, so anyone who can read it can act as that node. Restrict file system permissions, keep the file off shared volumes, and confirm that backups of the file carry equivalent protection. Plan key generation and rotation during the build, because a changed node key changes the node's identity on the network. Confirm the file location and handling steps in the node keys documentation.

Security module option and HSM plugin

The --security-module option lets Besu load a security module so that node key operations can use hardware-backed storage instead of the plain key file. The Besu HSM plugin is one example of such a module. Decide early whether your key custody requires an HSM, then confirm which plugin version matches your Besu release, how it is built and deployed, and how it behaves during restart and failover. Include the credentials the plugin uses to reach the device in your threat model.

JSON-RPC and WebSocket interfaces

The JSON-RPC and WebSocket interfaces are how applications and operators call a node. Each interface has its own enable and bind settings, and a bind address wider than necessary exposes administrative methods to more hosts than intended. Enable only the interfaces a node serves, bind them to private addresses, and require authentication, either a credentials file or JWTs validated against a public key. Besu does not terminate HTTPS natively, so plan TLS at a proxy. Confirm the exact enable and host options for your release in the API documentation.

Metrics endpoint exposure

The metrics endpoint is enabled with --metrics-enabled and listens on port 9545 by default. It reveals operational detail such as peer counts and sync status, which helps operators and also helps anyone mapping the network. Decide which hosts may scrape the endpoint, limit the port to the monitoring network, and review whether a push gateway is in use, since pushes send data outward. Confirm the default port and metrics options for your release before writing firewall rules.

Decisions to settle before changing any node

This table compares the main choices for node permissioning, node key custody and JSON-RPC and WebSocket exposure, with the operational cost each one adds. Read each row as a decision to settle before any node changes, since several options need tooling, hardware or a proxy layer that Besu does not supply on its own. The main takeaway is that the stricter option usually adds change control and an operating dependency, so choose it where your risk requires it.

Option	Operational cost	When it fits
Local permissions files on each node	Every change requires editing and reloading the file on every node, so change control and drift checks must cover each host.	Small networks with few participants, or teams that want each operator to control its own node.
Centrally managed permissions files distributed by configuration tooling	Needs a configuration pipeline, version control and a check that every node runs the same approved file.	Networks with many validators or frequent onboarding, where one reviewed source of truth reduces drift.
Onchain permissioning (legacy networks only)	Removed in Besu 25.6.0, so current releases cannot use it. Existing networks must migrate to local files.	Only as a stepping stone for legacy networks that already run it and must move to local files.
Node key as a file with strict OS permissions	Besu documents the node private key file as unencrypted, so protection depends on file ownership, restricted access and tested backups.	Lower-sensitivity networks or early stages, where host hardening and access logging are already in place.
Security module plugin backed by hardware (Besu HSM plugin via --security-module)	Requires a key ceremony, HSM procurement, plugin upgrades alongside each Besu release, and a dependency on the HSM vendor.	Regulated deployments where key custody must be hardware-backed and auditable.
JSON-RPC exposed to a single admin host	Simple to firewall, but applications needing RPC access must reach that host, creating a bottleneck and single point of failure.	Operator-only access such as validator administration or internal tooling on a restricted network segment.
JSON-RPC behind a reverse proxy with TLS termination	Besu does not terminate HTTPS natively, so you must add, configure, certify and patch the proxy and its authentication handling.	Callers outside the node host need encrypted access, centralized logging or request controls.
WebSocket enabled	Adds a persistent subscription surface that must be exposed, authenticated and monitored, widening the attack surface on each interface.	Only when a named application needs event subscriptions. Confirm the exact flags for your Besu release.

Hyperledger Besu security hardening sequence, step by step

This sequence takes a permissioned Besu network from an unreviewed set of nodes to one where each node accepts only known peers, each account is governed by explicit rules, keys are protected, APIs are restricted and the network is limited to required paths. Each step ends with a check that the team can record as evidence before moving on.

Inventory every node and its exposed interfaces
The network team lists every node and tags it as validator, RPC or bootnode, along with its host, operator, environment and the ports it listens on for peer traffic, JSON-RPC and WebSocket, and metrics. Each listed interface is traced to a business need or removed from the plan. This step closes when the inventory has been reviewed by someone outside the team who signs off that no node or open interface is missing, and when the list matches what a port scan from the network segment shows.
Restrict peer connections with node permissioning
Using the local permissioning configuration on each node, the team lists the enode identities of the nodes allowed to connect, starting with validators and bootnodes, and sets the node to reject all others. Changes are made in a test network first, then applied to production in the same order as the inventory. This step closes when a test node with an identity outside the list cannot establish a peer connection, and when the peer count on each node equals the number of expected peers.
Define account rules and suspension process
The governance owner writes the rules for which accounts may submit transactions, deploy contracts or take other actions, and sets them in local account permissioning on each node. Because onchain permissioning was removed in Besu 25.6.0, these rules must be kept consistent across every node by configuration management. The team also writes and rehearses a procedure for suspending an account, including who approves it and how the change is rolled out. This step closes when an unlisted test account is rejected, and when a rehearsed suspension blocks a test account on all nodes.
Move node keys into the chosen custody model
The node private key file is not encrypted by Besu, so the team moves each key into the custody option chosen during design. For file-based custody, the file is restricted to the service account using OS permissions and copied to an encrypted, access-controlled backup location. For hardware-backed custody, the team configures a security module plugin, such as the Besu HSM plugin with the security module option, and confirms the module starts. This step closes when the file is not the only copy and is readable only by the service account, or when the node starts and signs with the security module.
Restrict JSON-RPC and WebSocket to authorized callers
The team binds JSON-RPC and WebSocket to the specific interfaces they need, limits the enabled API groups to those used by each caller, and allows access only from named hosts or network ranges. Authentication is then enabled, with credential and token design covered in the JSON-RPC authentication topic. This step closes when a request from an unlisted host fails, when an unauthenticated call is rejected, and when a disabled API group returns an error from each node type.
Apply firewall rules and TLS for RPC
The team writes firewall rules that allow only the peer and RPC ports required between known hosts, and blocks everything else by default. Validator P2P ports are kept off public networks, and any RPC endpoint reached by a client outside the node's network is placed behind a TLS-terminating proxy, because Besu does not terminate HTTPS natively. This step closes when an external scan shows no validator P2P port, when the RPC endpoint responds only over TLS, and when the firewall rules match the approved inventory.

How to protect node keys, accounts and API surfaces

Each card pairs a threat to a Besu network with the control that addresses it, the team that should own that control, and the evidence an assessor would ask to see. The threats cover who can join the network, who holds node identity, which accounts can act, and which interfaces answer requests.

Unauthorized peers joining the network

Node permissioning restricts which nodes can connect to yours, using a permissions configuration file on each node. The network operator owns the allowlist and should update it only through the consortium's approved process. Evidence an assessor would ask for: the current permissions file on each node, the change record that approved each entry, and a test showing that a node not on the list is refused. Confirm with your consortium whether the list is maintained locally, centrally, or both.

Stolen or copied node key

Besu documentation states that the local node private key file is not encrypted, so anyone who copies the file can impersonate the node. Where hardware-backed storage is required, the Besu HSM plugin can be enabled with the --security-module option so the key stays inside the module. The key custody lead owns this control, working with platform engineering. Evidence to request: the key custody design, file ownership and permission settings, HSM configuration records, and access logs for the key store.

Compromised account allowed to act

Account permissioning controls which accounts can be onboarded, which can be suspended, and which actions they may take. A suspension rule only helps if the procedure names who may trigger it and how the change reaches every node. The consortium governance lead owns the rules, with the application owner for each account. Evidence: the account permission rules, onboarding and offboarding records, and a dated test of suspending an account on a non-production network.

JSON-RPC or WebSocket reachable beyond callers

Enable JSON-RPC authentication with a credentials file or with JWTs validated against a public key, and limit which interfaces and ports the node listens on. Besu does not terminate HTTPS natively, so TLS must come from a reverse proxy or gateway placed in front of the node. The platform networking team owns this control. Evidence: the authentication configuration, firewall and security group rules, and the results of an external scan showing which interfaces respond.

Metrics or admin interfaces leaking information

Besu exposes Prometheus metrics when --metrics-enabled is set, on a default endpoint port of 9545, and it can also push metrics to a Prometheus push gateway. Peer counts, sync state and block production data help an attacker plan an attack, so the endpoint should not be reachable from general networks. The monitoring or SRE team owns this control. Evidence: bind address and port settings, network rules that allow only the scrape source, and the scrape configuration reviewed against an allowlist.

Key, permission and secret change control

Node key files, permissions configuration files and genesis files determine how a node identifies itself and which peers and accounts it accepts, so each change should follow a documented approval and be recorded. RPC credentials and JWT signing material must not sit in shared repositories, wiki pages or chat channels; keep them in a secrets manager with access logged. The platform engineering lead owns this control with the security team. Evidence: change tickets, version-controlled configuration with review history, a secrets inventory, and a repository scan showing no committed credentials.

How hardening changes for validators, RPC nodes and air-gapped sites

Validators in a QBFT or IBFT 2.0 network sign blocks, so a compromised validator can damage consensus, and its signing key is the most sensitive asset on the node. Besu's documentation states that the local node private key file is not encrypted, which makes key custody the first decision to settle. Hardening here starts with protecting that key and then reducing what the node can reach.

Key custody first. Decide whether the node key sits on disk under restricted file permissions or behind a security module plugin, such as the Besu HSM plugin enabled with the --security-module option. Confirm that the plugin version matches your Besu release.
Minimal exposure. Keep validator JSON-RPC and WebSocket interfaces off public networks. Route application traffic through RPC nodes so that validators serve only the peers and tools they need.
P2P restricted to known validators. Use node permissioning in the local permissions configuration file so that only listed nodes can connect. Confirm whether permission changes take effect without a restart in your version.
Narrow host access. Limit who can read the data directory and the key file, and log administrative access to the signing host.

Before changing permissions on a validator, check the Besu release notes for your version and confirm in your environment which validator ports are reachable from which networks.

How to test that the hardened node refuses what it should

The most useful test of a hardened Besu node is whether it refuses the things it must refuse. A node that accepts the expected traffic proves very little if it also accepts an unlisted peer, an unpermitted account or an unauthenticated RPC call. Build the verification plan around denial cases first, and treat each successful connection as the exception that needs an explanation.

Start with node permissioning. From a host that is not listed in the node permissions configuration file, attempt a peer connection to a validator and an RPC node. The connection should fail, and the node logs should show the rejection. Repeat the test from a listed node to confirm that the allowlist works in both directions, since a one-sided check can pass while the network still accepts unknown peers. Confirm the same behavior after every change to the permissions file, because a stale or mistyped entry is one of the most common reasons an allowlist silently fails open or closed.

Next, test account permissioning with three accounts: one that is onboarded and permitted, one that is not listed at all, and one that was listed and then suspended. Submit a simple value transfer and a contract call from each. Only the first should be accepted and mined. The unpermitted and suspended accounts should be refused at submission, and the refusal should be recorded. Ask the team to confirm in writing which action restrictions apply to each role, because a permitted account can still be restricted from specific actions, and that rule needs its own case.

For the API surface, call JSON-RPC and WebSocket endpoints without credentials, with a wrong password or with an expired or wrongly signed token, and with a method outside the scope granted to that caller. Each call should be refused. Also confirm that the node is not reachable on interfaces or ports that were meant to stay private. Because Besu does not terminate HTTPS natively, check the transport path in front of the node as well, and confirm with your security team that any proxy or load balancer enforces the same authentication and does not pass through calls the node would reject.

Run an external port scan from outside the allowed network and compare the results with the approved port list. Only the intended peer-to-peer and any approved API or metrics ports should appear. Then test the key-protection failure path: make the security module unavailable, for example by stopping the HSM connector or blocking its endpoint, and restart the node. The node should refuse to start or stay down, and it must not fall back to the unencrypted node key file unless an approved, documented exception exists. Keep each of these cases in the change process, so every release, configuration change and firmware update reruns them. DeployOpen can run application, API and infrastructure security testing as a separate service, and an independent auditor, not DeployOpen, issues any assessment report.

What drives Hyperledger Besu security hardening effort and cost

This table lists the drivers that change Besu hardening effort and cost, with a way to keep each one down. Cost comes from internal staff time, any HSM or other hardware and vendor charges, and the fixed-scope services quote. No figures appear here, so confirm each driver against your own environment and the written scope.

Driver	Why it changes effort or cost	How to keep it down
Nodes and roles	Each validator, RPC node, bootnode and signer role adds configuration, keys and monitoring to build and verify.	Use standard node templates per role, generated from infrastructure as code.
Permission sets and accounts	Node allowlists and account onboarding rules must be written, tested and reviewed for every participant.	Use standard permission templates per participant type, changed through one approval process.
Key custody option	File-based node keys need OS access controls. An HSM security module plugin adds hardware, vendor integration and failover testing.	Adopt one approved key custody pattern for every node in every environment.
JSON-RPC consumers and identity	Each application or user group that calls node APIs adds credentials or JWT validation and permission mapping.	Limit consumers to a small set of gateways and reuse one identity provider integration.
Network topology across sites and operators	Each site, cloud account or operator boundary adds firewall rules, connectivity tests and joint sign-off.	Fix a reference topology and expose the fewest possible interfaces at each site.
Environments (dev, test, production)	Each environment must mirror production controls, so hardening and verification repeat in each one.	Build every environment from the same code, changing only documented parameters.
Compliance evidence expectations	Assessors may ask for configuration baselines, access reviews and change records for each control.	Agree the evidence list before the build and collect it from pipelines as work happens.
Release cadence	Besu ships roughly monthly, and each release can require re-verifying permissions, JSON-RPC exposure and key handling.	Set a fixed upgrade window and a regression checklist covering security settings.

What to monitor, back up, upgrade and document after hardening

Hardening is not finished at go-live, because the controls that protect a Besu node depend on membership and configuration staying in step with what was approved. Each time a participant joins, leaves or changes operator, review the node permissions file so that only known peers can connect, and review the account permissioning rules so that onboarding, suspension and restricted actions still match the governance record. Compare the live peer count and peer identities against the expected list, and check that block production comes from the validators you intended. Treat any unexpected peer as a change to investigate, not a routine event. The alerting design for these signals is covered in the Prometheus and Grafana monitoring topic, so this section concerns the review habit that keeps those alerts meaningful.

Authentication and key custody need their own ongoing checks. If your chosen JSON-RPC setup writes authentication failures to logs, confirm which log lines are produced in your environment, forward them to your central log store, and review repeated failures from one source address. Confirm this with your own logging configuration, because the outcome depends on how the node is started and what your log pipeline keeps. The node private key file is not encrypted by default, so every backup of node data also exposes key material. Store key backups under separate control from node data backups, with different administrators and access logs, and test a restore of each to confirm that the copies are complete and usable.

Take a verified backup of node data before every upgrade. The Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and that older Besu versions cannot open the upgraded database. A rollback therefore depends on a backup that was taken before the new version started, not on reinstalling the previous binary. Plan each upgrade so that the backup, the permissions and configuration files, and the key material are captured together, and confirm the restore procedure on a non-production node first. Sequencing validator and RPC upgrades is covered in the upgrades and support topic, and backup and recovery design for validators is covered in the high availability topic.

Re-verify the hardening after each monthly Besu release. The GitHub releases page lists 26.7.0, 26.8.0, 26.9.0 and 26.10.0 in sequence, and each one can change defaults, flags or behavior that the earlier configuration relied on. Repeat the checks for permissions, key custody, exposed interfaces and network controls, and record the results. Keep a dated record for each node that lists the permission set in force, the key custody method, every interface that is reachable and from where, and the test results with the Besu version tested. This record gives auditors and internal reviewers evidence of ongoing control operation, and it shows what changed between releases. Confirm with your security team how often testing should run and who signs off on each record.

Questions teams ask before hardening a Besu network

What does Besu hardening cost, and what drives the price?

Cost depends on the scope agreed in writing. DeployOpen does not publish a price list, and a quote follows from that scope. The main cost components are review and design of node and account permissioning, JSON-RPC and WebSocket exposure, and network controls; implementation of configuration, access controls and any key storage change; verification that the settings behave as designed; and handover of runbooks. Cost rises with the number of validators, RPC nodes and environments, the number of permissioning rules, whether an HSM security module is in scope, and how many change windows the work needs. Ask any provider for a quote that separates one-time work from recurring items such as support or retesting after upgrades, and ask which internal hours it assumes.

How long does it take to harden a Besu network?

No duration is quoted without a written scope, so treat any number you hear before scoping with caution. The time depends on how many nodes and environments are involved, how much of the current configuration is undocumented, whether permissioning rules must be designed from scratch or only reviewed, and whether key custody or an HSM decision is still open. Internal approvals and change windows often set the pace more than the technical work does. Work also pauses while teams wait for inventory data or decisions. Ask for a plan that lists each phase, the internal inputs it needs and the dependencies between them, then compare it against your own change calendar. If a monthly Besu release lands mid-project, the written scope should state which version the hardening targets.

What must our internal team provide before hardening starts?

Your team supplies the facts and decisions that the design depends on. Expect to provide a node inventory listing every validator, RPC node and bootnode with its host, network zone, operator and Besu version; the permission decisions, meaning which participants may connect to which nodes and who may onboard, suspend or restrict accounts; approval for key custody, including where node key files live and who may access them; and change windows for each environment, with a rollback plan. You also need named owners who can answer questions during the project, access to staging environments, and a list of any integrations that call node APIs. Missing decisions are a common reason hardening work slows down, so confirm these inputs in the written scope before work begins.

Can our own team harden a Besu network without a partner?

Yes, a small permissioned network with clear runbooks and experienced operators can often be hardened in house. Your team needs working knowledge of Besu configuration, the permissioning files, JSON-RPC authentication, network firewalling and key handling, plus a staging environment where changes can be tested. Specialist review helps in three places: designing account permissioning across multiple organizations, checking that exposed interfaces match the intended design, and testing the result from outside the trusted network. An outside reviewer also challenges decisions that the people who built the network may have made without a second opinion. Decide based on the number of nodes, the number of participating organizations and the skills available in your team.

Does a Besu network require an HSM for node keys?

No, it depends on your key risk decision. Besu's documentation says the local node private key file is not encrypted. Where hardware-backed key storage is needed, Besu supports a security module plugin, such as the Besu HSM plugin, enabled through the --security-module option. Decide based on who can read the node host, how keys are backed up, what your key custody policy requires and what the plugin means for operations, including how keys are recovered after a failure. Confirm that the plugin supports your Besu version before you plan around it, and record the decision in the design so that auditors can trace why it was made.

Does Besu handle TLS for its JSON-RPC and WebSocket endpoints?

No. Besu does not terminate HTTPS natively, so TLS for node APIs must be handled in front of the node. Besu's documentation covers JSON-RPC authentication through a username and password credentials file or through JWTs validated against a public key, but transport encryption is a separate layer. Common options include a reverse proxy, a load balancer or a service mesh, each with its own certificate lifecycle and access rules. Confirm with your platform team which component terminates TLS, how certificates are issued and rotated, and whether traffic between the proxy and the node stays on a trusted network. Make sure the node itself is never reachable directly from untrusted networks.

Can DeployOpen certify our Besu network as compliant?

No. DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence for compliance assessments, such as configuration records, permissioning rules, access settings and test results. Independent auditors or certification bodies assess the controls and decide what they conclude. Ask any provider which framework it has in mind, which controls the evidence maps to, and who will assess the environment. The useful test is whether your evidence is complete and traceable, because the assessor will examine the evidence directly and will not rely on a summary.

What does Besu permissioning control on each node?

Besu's local permissioning uses a permissions configuration file on each node to control two things. Node permissioning restricts connections to known participants, and account permissioning sets onboarding rules, can suspend accounts and can restrict actions. The file must stay consistent across the validators and RPC nodes that should enforce the same rules, so drift between nodes is a common source of failures. Test the file in staging by attempting connections and transactions from both allowed and disallowed identities. Record which node enforces which rule. Because permissioning changes affect connectivity, plan them inside a change window and keep a copy of the previous file for rollback.

How DeployOpen scopes, hardens and hands over Besu security work

DeployOpen approaches Hyperledger Besu security hardening as a fixed-scope piece of work inside your own infrastructure. We agree in writing which nodes, permissioning rules, key storage, JSON-RPC and WebSocket exposure and network controls are in scope, then build, test, document and hand over the result to your team.

How we scope

We inventory every Besu node, its role and its exposed JSON-RPC and WebSocket interfaces before any change is planned.
The written scope names which node permissions and account permissions files are in scope and who approves them.
The scope states how the node private key files will be protected, including whether an HSM security module plugin is used.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

We write and version the local permissioning configuration files for node and account permissioning, then test them on non-production nodes.
We configure JSON-RPC authentication with a credentials file or JWT validation against your public key, and confirm which methods each caller can reach.
We restrict WebSocket and RPC bind addresses and ports, and place network controls around nodes that your policy requires to be isolated.
We test each change against the running network and record which controls were verified and which remain open.

How we hand over

You receive a hardening baseline document covering configuration, permissions, key storage decisions and the network control map.
Runbooks explain how to add or suspend an account, rotate credentials and change a permissions file safely.
Your team gets a walkthrough and a verification checklist so it can repeat the checks after future Besu upgrades.
Confirm with DeployOpen the exact evidence format you need for internal reviews or external assessors before handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Support can cover re-checking permissioning and JSON-RPC exposure when Besu releases change those areas.
Ask for the support scope, response arrangements and upgrade handling to be written into the quote.
Your team keeps ownership of production changes, and DeployOpen documents each change it makes in your environment.

Hyperledger Besu security hardening