How Hyperledger Besu operations map to DORA ICT risk requirements
A financial entity that runs Besu validators or RPC nodes must show its competent authority how those nodes are governed under DORA's ICT risk management chapter. In short, Besu's documented capabilities help with the technical controls (key protection, access control on the RPC interface, metrics and logs), while the entity's own governance carries the duties that no client software can meet: documented policies, approvals, tested recovery and retained evidence. DeployOpen prepares systems, configurations and evidence for this review, but it does not certify compliance, and DORA sets no certification scheme. Competent authorities supervise compliance directly, and the only authority-linked attestation DORA provides for is the one on threat-led penetration testing under Article 26(7).
On the technical side, the Besu documentation supports several of the controls DORA Article 9 asks for. Node permissioning and account permissioning are configured through local permissions files, and JSON-RPC access can be restricted with a credentials file or JWTs validated against a public key. Besu does not terminate HTTPS natively, so TLS for RPC has to come from a proxy or gateway the entity operates. The local node private key file is not encrypted, so the entity must decide whether to use the HSM plugin through --security-module or document why a key file is acceptable. Metrics are exposed for Prometheus with --metrics-enabled, which gives the monitoring input that Article 12 logging and clock synchronization work will depend on.
Several requirements stay with the entity. Change management under Article 9(4)(e) needs a documented process for client upgrades, protocol milestones and validator changes, including testing and approval before each step. Besu's upgrade notes matter here: the Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older versions cannot open it, so a backup taken before the upgrade is the only rollback path. Backup scope, restore testing on segregated systems and yearly continuity tests with switchover are also the entity's responsibility. Before scoping work, confirm with your compliance team which DORA articles apply to your entity type and which controls your competent authority expects to see evidence for.
Which DORA Article 9, 11 and 12 duties Besu configuration supports
This table maps each DORA duty in scope to the Besu capability that supports it, the configuration you need and the team that should own the evidence. Rows marked with a cross show duties where Besu gives no native capability and your own tooling or process must close the gap. Read it as a starting point for your control matrix, not as proof of compliance.
| DORA duty | Besu capability and configuration | Owning team and gap |
|---|---|---|
| Article 9(4)(d) strong authentication | JSON-RPC authentication with a credentials file or externally issued JWTs validated against a public key. Besu does not terminate HTTPS natively, so place a TLS-terminating proxy in front of RPC. | Platform engineering and security. Confirm the JWT signing algorithm and token lifetime with your identity team. |
| Article 9(4)(e) protection of cryptographic keys | Node private key file is not encrypted by default. Use a security module plugin such as the Besu HSM plugin with the --security-module option where hardware-backed storage is required. | Security engineering. Gap if no HSM is used: file permissions, encrypted volumes and access logs must be documented instead. |
| Article 9(4)(f) recorded, tested and approved ICT changes | Besu does not manage change approvals. Track client upgrades, genesis or permissioning changes and validator set changes in your change system, and test on a non-production network first. | Change management and network operators. Gap: Besu provides release notes but no approval workflow. |
| Article 9(4)(f) documented patch and update policy | Calendar releases ship roughly monthly. Note that Besu 26.10.0 auto-upgrades the Bonsai database on first start and older versions cannot open it, so the policy must require a backup before each upgrade. | Network operations. Gap: the policy and its review cadence are yours to define. |
| Article 12 logging of access, change, operations and network events | Metrics are exposed for Prometheus with --metrics-enabled (default port 9545). Node and RPC access logs are not a complete audit trail by themselves, so forward logs to a central store and protect them from tampering. | Security operations. Gap: logging-failure detection and log integrity controls must be built around Besu. |
| Article 12 clock synchronization to a reliable time source | Besu does not set host time. Synchronize every validator and RPC host to a documented time source and alert on drift, because QBFT round timing and log correlation depend on it. | Infrastructure team. Confirm the time source and drift threshold in your own environment. |
| Article 12(1) and (2) backups and restore testing | Back up node data and the keys held outside Besu, then test restores periodically. Besu does not define your backup frequency, scope or restore test schedule. | Platform operations. Gap: backup policy and test evidence must be produced by your team. |
| Article 12(3) restores on segregated systems | Besu has no native restore isolation. Restore into a network or account segregated from the source validators and keep restore credentials separate. | Infrastructure and security. Gap: segregation is an architecture decision you must document. |
| Article 11(6) yearly and post-change continuity tests with switchover | Besu provides redundant validator and RPC roles in the network design, but it does not run switchover tests. Plan scenarios including cyber-attack and failover to redundant capacity, and retest after substantive changes. | Business continuity and operations. Gap: test scripts, results and sign-off sit with your organization. |
What evidence Besu produces for DORA reviews and how to keep it
Assessors reviewing a Besu network under DORA ICT risk requirements sample records from access, configuration, change, monitoring, backup and recovery. Each card below names one record set, what it shows, and what to check before a review, so the evidence stays consistent across the ledger, the nodes and the people who run them.
Node and account permissions files
The local permissions configuration files show which nodes may connect and which accounts may act, including onboarding rules and any suspended accounts. Assessors compare these files with the access approvals on record. Check that every change to a permissions file has a matching approval, that the same file versions are deployed on every node, and that the files are stored under version control with restricted write access. Note that a file on disk proves configuration at one moment, not that it was enforced.
RPC authentication configuration
The JSON-RPC authentication settings record how callers prove identity, either through a credentials file or through JWTs validated against a public key. Keep the configuration, the list of permitted signing algorithms and the key rotation record together. Because Besu does not terminate HTTPS natively, also retain the evidence for the TLS layer in front of the node, such as the proxy or gateway configuration. Confirm with your own environment which endpoints are exposed and to whom.
Prometheus metrics history
Metrics scraped from the node's Prometheus endpoint, enabled with the metrics option, show peer counts, block production and resource use over time. These series support capacity and availability reviews and show when a node fell behind or lost peers. Keep retention long enough to cover the review period you have agreed with your supervisor, and record the scrape configuration and alert rules as evidence. Confirm your retention target with your compliance team, since the metrics store is not a substitute for a log archive.
Change records tied to release notes
Each Besu client upgrade should have a change record that cites the release notes, the test results on a non-production network, the approver and the rollback plan. Calendar releases arrive roughly monthly, so the record should show which version was assessed and why it was or was not adopted. Include removed features in the assessment, for example the removal of Clique consensus in 26.4.0, and record how each affected network was checked afterwards.
Backup logs and restore test results
Backup job logs show what was copied, when, and whether the job completed, while restore test results show that the copy can be used. For Besu, the restore record should state the software version and whether the database format was upgraded, because the Bonsai database auto-upgrades on first start and older versions cannot open it. Keep restore tests on segregated systems, and record the time taken and the validation steps performed, so reviewers can compare results across tests.
Retention, tamper protection and sign-off
Evidence is only useful if it cannot be quietly altered. Define a retention period for each record set, store logs and configuration history in write-once or access-controlled storage, and make sure clock sources are synchronized so timestamps line up across nodes and tools. Name who signs off each record set, such as the network operator for permissions, the security owner for key and RPC access, and the service owner for backup tests. Confirm the retention periods and approval roles with your legal and compliance teams, since DORA sets the duty to keep records but the periods come from your own policy and supervisor expectations.
Protecting validator and node keys for DORA Article 9
Under DORA Article 9(4)(d), a financial entity must protect cryptographic keys, and for a Besu network that starts with the node private key. Besu's documentation states that the local node private key file is not encrypted. Treat that file as a secret on the host: restrict filesystem permissions to the service account, keep it off shared volumes and out of container images, and include it in your key inventory with an owner and a rotation procedure. Where your risk assessment requires hardware-backed storage, the Besu HSM plugin can be loaded through the --security-module option, which moves signing operations out of the node process. Confirm with the plugin maintainers which key types and curves it supports and how it behaves when the HSM is unreachable, because a validator that cannot sign stops contributing to block production.
JSON-RPC access is the second control point. Besu supports two authentication approaches: a username and password credentials file, or JWTs issued by an external identity provider and validated against a public key using RS256, RS384, RS512, ES256, ES384 or ES512. The JWT option fits DORA's strong authentication expectation better because it lets your existing identity platform manage sessions, rotation and revocation. Choose one approach per RPC endpoint, record the decision, and test that unauthenticated calls to administrative methods are refused. Keep in mind that the credentials file is itself a secret that needs the same protection as the node key.
Besu does not terminate HTTPS natively, so transport encryption for RPC is your responsibility. Place a TLS-terminating reverse proxy or load balancer in front of the RPC port, manage certificates through your own PKI, and restrict which networks can reach the node interfaces at all. Confirm the protocol versions and cipher suites your proxy enforces against your security standard, and verify the configuration with an external scan before go-live and after each change. Document these controls alongside the key inventory so that the evidence for Article 9 can be produced in one place.
Configuring Besu for DORA ICT risk controls, in sequence
This sequence turns DORA's ICT risk expectations into an ordered Besu build, so each control is in place before the next one depends on it. The end state is a network whose access, keys, logs, backups and recovery steps can each be shown to an assessor.
Scope nodes and data by criticality
Start by listing every validator, RPC node, bootnode and supporting service, and the data each one holds: chain data, node keys, account keys, configuration and logs. Rank them by the function they support, since DORA Article 12 ties backup scope and frequency to data criticality. Your ICT risk and business continuity owners should approve the list, and the output is a written inventory that every later step references.
Lock down node and account permissioning
Configure Besu local permissioning on every node, using a node permissions file that allows connections only to known participants and an account permissions file that sets onboarding rules and the ability to suspend accounts. Confirm the approach against the current Besu permissioning documentation, since the onchain option was removed in an earlier release. Test with a deliberately unlisted peer and a suspended account, and keep the approved files under change control so the evidence shows who authorized each entry.
Enable JSON-RPC authentication and TLS termination
Turn on JSON-RPC authentication using either a credentials file or JWTs validated against a public key with an approved algorithm. Besu does not terminate HTTPS natively, so place a TLS-terminating proxy or gateway in front of each RPC endpoint and confirm which team owns its certificates. Verify by sending an unauthenticated request and a request with an expired or invalid token, and record that both are refused.
Set key storage for validator and node keys
Decide where each key lives before the node first starts. The Besu node private key file is not encrypted, so for keys that need hardware-backed protection, use a security module plugin such as the Besu HSM plugin through the --security-module option, and confirm its support for your HSM model. Where no HSM is available, document file permissions, access restrictions and the key custodians. The output is a key register that names each key, its location, its custodian and its rotation approach.
Enable metrics and log pipelines with clock synchronization
Enable metrics with the metrics option so Prometheus can scrape the default endpoint, and route Besu and proxy logs to your central log platform. Configure every host to synchronize its clock to a documented reliable time source, because Article 12 of Delegated Regulation (EU) 2024/1774 requires it. Add alerts for logging failures and for access control, change and capacity events. Verify by confirming that a test event appears centrally with a timestamp that matches the reference source.
Schedule backups before every upgrade
Set a documented backup policy that sets the scope (chain data, keys, configuration, permissions files) and the minimum frequency by criticality. Before each Besu upgrade, take a backup, because the Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and older versions cannot open it. That pre-upgrade backup is your rollback path. Confirm the backup completed, is encrypted, and is stored outside the source system.
Plan segregated restore and switchover tests
Define restore environments that are physically and logically segregated from production and protected from unauthorized access, as Article 12(3) requires. Schedule restore tests of the backups and a recovery of a validator into the segregated system, then run a switchover to redundant validators and RPC capacity. Include a cyber-attack scenario, since Article 11(6) requires testing at least yearly and after substantive changes. Record results, defects and owners, and feed them back into the continuity plan.
Change management for Besu client upgrades under DORA Article 9(4)(e)
DORA Article 9(4)(e) requires documented, risk-based ICT change management so that every change is recorded, tested, assessed, approved, implemented and verified. For a Besu network, a client upgrade is a change like any other, and the entity has to be able to show that chain of control for each one. Besu ships on a calendar cadence, so the work is continuous rather than occasional. The supplied release dates run from 26.7.0 on July 13, 2026 through 26.10.0 on October 16, 2026, and each one needs its own assessment before it reaches a validator or RPC node.
Assessment matters because some releases remove functions your network may depend on. Besu 26.4.0 (April 22, 2026) removed Clique consensus, so a pure Clique network can no longer start or produce blocks. Besu 25.6.0 (June 4, 2025) removed the Tessera privacy feature and onchain permissioning. Your assessment should compare each release's notes against your configuration, your consensus type, your permissioning model and any plugins or RPC API groups you call. Confirm that your entity's own patch policy defines how quickly security and maintenance releases must be assessed, and who decides when a release is deferred.
Your entity must set its own patch and update policy and approval workflow, because DORA leaves the cadence and the approvers to the entity. Define who raises a change, who tests it on a non-production network that mirrors your validator set, who approves it, and what evidence proves the upgrade was verified on each node. Also plan for the one-way step: the Bonsai database auto-upgrades on first start, and older Besu versions cannot open an upgraded database, so the pre-upgrade backup is part of the change record, not an afterthought.
What Besu does not cover for DORA
Besu documentation covers the node, key and logging controls a DORA program depends on, but it does not produce the governance, reporting and continuity evidence that DORA requires of the financial entity itself. Each card below names a gap, the party that must own it, and why Besu documentation cannot stand in for it.
Governance and board accountability
DORA places ICT risk management responsibility on the management body of the financial entity, including approval of the ICT risk framework and oversight of its implementation. A Besu network has no built-in way to show that the board reviewed validator risk, approved the upgrade policy or accepted residual risk. Ask who on the management body signs off the Besu risk assessment, how often it is reviewed, and where that approval is recorded.
Incident classification and reporting
The entity must classify ICT-related incidents and report major ones to the competent authority under DORA's incident management chapter. Besu logs and metrics can show that a validator stopped or that blocks were not produced, but they do not decide whether an event is major or who is notified. Assign incident owners who map Besu alerts to the entity's classification criteria and reporting timelines before go-live.
Threat-led penetration testing
Where a financial entity falls under the TLPT requirements, the entity must run threat-led penetration tests on live production systems, with scope set by its own risk and critical functions. Besu's documentation describes node configuration, not an attack scenario for the whole network. Confirm with the testing provider and the competent authority whether the Besu nodes, RPC endpoints and key custody sit inside the test scope.
Third-party register and exit plans
Article 28 requires a register of all ICT contractual arrangements and tested exit strategies for services that support critical or important functions. If a vendor, a consortium operator or a managed service runs Besu nodes, the contract, the register entry and the exit plan belong to the entity. Besu's open-source license does not supply these records, so the entity must list each provider, the data location and the transition path for validator and key custody.
The entity's own business continuity plan
Besu redundancy, validator placement and restore procedures feed into the entity's business continuity and response and recovery plans, but they are not those plans. The entity must decide which functions the network supports, set recovery objectives, and test switchover at least yearly and after substantive change. Ask the operations owner to show how a Besu failover appears in the wider continuity exercise and who declares it.
Clock source selection
Delegated Regulation (EU) 2024/1774 requires logs to be synchronized to a documented reliable time source. Besu nodes write timestamps, but the choice of time source, its drift monitoring and its documentation are decisions for the infrastructure team. Confirm which NTP or PTP hierarchy the validator hosts use, who owns it, and how clock drift is alerted and recorded for evidence.
Questions financial entities ask before hiring help for Besu DORA compliance
How much does it cost to make a Besu network DORA ready?
No figure can be given here because cost depends on the written scope, and DeployOpen does not publish a price list. The main cost components are the engineering time to design key protection, change management, logging, backup and restore testing, and continuity tests, plus any HSM hardware or licensing your team buys. Some items are one-time, such as the initial design, build and first test cycle, while others recur, such as yearly continuity tests, restore tests and log review. Ask for a quote that separates one-time work from recurring work, lists the number of nodes and environments in scope, and states which tests are performed by DeployOpen and which are performed by your staff.
How long does a DORA operations project on Besu take?
Duration depends on how many validators and RPC nodes are in scope, whether segregated restore systems already exist, and how far your change process and logging stack are already defined. No duration is supplied for this work, so ask for a timeline in the written scope with milestones for design, build, testing and handover. Note that DORA Article 11(6) requires continuity plans to be tested at least yearly and after substantive changes, so the schedule should also include the first full continuity test and a plan for the tests that follow.
What does the work need from our organization?
Expect to provide named owners and access to the systems involved. In practice this means an accountable owner for ICT risk, people who approve changes and key custody, access to your cloud accounts, data centers or air-gapped networks, your existing logging and monitoring tools, and the documented policies you already hold. Your staff also need to take part in approvals, business impact decisions about recovery objectives, and tabletop exercises. Confirm each of these in the scope document so that responsibilities are clear before work starts.
Can our internal team implement these controls without a partner?
Yes, an internal team with Besu, Kubernetes or infrastructure, security and compliance skills can build these controls. The work is not unusual in kind, but it touches several disciplines at once: key handling, change approvals, log pipelines with clock synchronization, segregated restore environments and continuity exercises. Most teams find the gaps are in documentation and evidence rather than in configuration. Consider a partner when staff capacity is limited, when the deadline is fixed, or when an independent reviewer of your design is wanted before the assessor arrives.
What changes the effort for DORA operations work on Besu?
The effort moves most with the number of validators and RPC nodes, the number of environments, whether validator keys already sit in hardware security modules, and how many client upgrades are expected during the project. Other drivers include whether the network has multiple organizations with separate change authorities, how many logging sources must be mapped, whether backups already cover the Bonsai database and node data, and whether restore tests have been run before. Also check which Besu release line you run, because the 26.10.0 release notes state that an upgraded Bonsai database cannot be opened by older versions, so rollback depends on a backup taken before the upgrade.
Does DeployOpen certify that our Besu network is DORA compliant?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. DORA sets no certification scheme, and competent authorities supervise compliance using their own powers. The only authority-issued attestation the Regulation provides for is that a threat-led penetration test met the requirements under Article 26(7). Your national competent authority and your internal or external auditors make the judgment, so the written scope should describe the evidence DeployOpen will produce for them to examine.
Which DORA articles does the work address, and where is the source text?
The work maps to Article 9(4)(d) to (f) on key protection and change management, Article 12 of Delegated Regulation (EU) 2024/1774 on logging and clock synchronization, Article 12(1) to (3) on backup and segregated restores, and Article 11(6) on continuity testing. You can read the regulation text on EUR-Lex. Ask your legal or compliance lead to confirm how your entity category and any national rules apply, since DORA applies to 20 types of financial entity and supervisors may expect different evidence depending on the entity.
How DeployOpen scopes and delivers DORA-ready Besu operations
DeployOpen plans, builds, documents and hands over Hyperledger Besu validator and RPC node operations inside the infrastructure you control, with the DORA ICT risk controls mapped to named systems and runbooks. Each engagement starts from a written scope, so your team knows which controls, evidence and tests are delivered before work begins.
How we scope
- Inventory every Besu validator, RPC and bootnode, its hosting location and the systems that depend on it
- Map key custody, change, logging, backup and continuity requirements to named owners and evidence items
- Agree in writing which restore targets, switchover tests and upgrade rehearsals are in and out of scope
How we build
- Configure node key storage with an HSM plugin where your policy requires it, and document the fallback for key files
- Set up change records for Besu client upgrades, including pre-upgrade backups because newer Besu releases upgrade the Bonsai database on first start
- Ship logs and metrics with time sources synchronized and tamper-protected, and test that logging failures trigger alerts
How we hand over
- Deliver runbooks for key rotation, upgrades, backup and restore on segregated systems, and switchover to redundant capacity
- Record test results, restore timings and gaps so your assessors can trace each DORA control to working evidence
- Train your operators on the runbooks and walk through a recovery exercise before the handover is signed off
How we support
- Run scheduled upgrade reviews against the Besu release cadence and plan the testing each release needs
- Repeat restore and continuity tests at the intervals your written policy sets, including after substantive changes
- Provide ongoing support, upgrades and continuous testing under a retainer agreed separately from the fixed-scope build
