How Besu logging and monitoring supports NIS2 point 3.2
If you operate a permissioned Besu network inside an in-scope entity, the question your auditors and national authority will ask is what monitoring and logging evidence exists for the chain, not only for the servers beneath it. Besu supplies part of that answer. Its node and JSON-RPC telemetry, its access controls and its authentication settings can feed point 3.2 of the Annex to Implementing Regulation (EU) 2024/2690, which asks for procedures and tools that monitor and log activity to detect events that could become incidents. The SIEM, the alarm workflow, the retention policy and the independent monitoring of the monitoring itself sit outside Besu and must be designed by your organization or its partner.
The starting point is what Besu can emit. Metrics are enabled with the --metrics-enabled option and expose a Prometheus endpoint, by default on port 9545, which you can scrape or push to a gateway. For access records, map each JSON-RPC interface you expose to an authentication method (a credentials file or JWTs validated against a public key) and log authentication outcomes at the reverse proxy or gateway in front of Besu, because Besu does not terminate HTTPS itself. Node and account permissioning files define who may connect and transact, so changes to them are changes you must capture as permission-change events. Confirm with the Besu documentation and your own tests exactly which log fields and levels your version emits before you write the detection rules against them.
Note that NIS2 creates no certificate of compliance. National competent authorities assess compliance through inspections, audits, scans and information requests, so the realistic deliverable is a control map: each point 3.2.3 log category, the source that produces it, where it is stored, who reviews it and the alarm that fires. ENISA's June 2025 guidance cites SIEM output, log samples, configured alarm thresholds and records of past alarms as evidence, so keep those artifacts from the first day of operation. Ask your partner or internal team to confirm which retention period your national transposition law and sector regulator expect, because the regulation itself sets none.
Mapping point 3.2 requirements to Besu capabilities and configuration
This table maps each part of point 3.2 of the Annex to Implementing Regulation 2024/2690 to what Besu provides, the configuration it needs, and what remains with your own monitoring, logging and operations. Read each row as a question an assessor will ask, then check whether the Besu column answers it or the last column names the gap. The main takeaway is that Besu produces node-level signals, while the logging platform, alarms and evidence records are your responsibility.
| Requirement | Besu capability and configuration | Not covered by Besu alone |
|---|---|---|
| Point 3.2 monitoring and automation | Enable metrics with the metrics option so Prometheus can scrape the default endpoint on port 9545. Collect node, peer and chain health series from every validator and RPC node. | Automated detection rules, the SIEM or log platform, and the decision of which events count as potential incidents. |
| Point 3.2.3 network traffic and access logs | Besu logs peer connections and JSON-RPC activity at the node. Set log level and output deliberately, and keep RPC access restricted to known clients. | Network flow records, firewall and load balancer logs, and capture of access to the RPC endpoint before it reaches Besu. |
| Point 3.2.3 user creation and permission changes | Local node permissioning and account permissioning are defined in permissions configuration files. Version these files and log every change to them. | Approval records and change history. Besu does not record who edited a permissions file or why. |
| Point 3.2.3 authentication and privileged activity | JSON-RPC authentication uses a credentials file or JWTs validated against a public key. Record authentication outcomes at the gateway or identity provider. | Besu does not terminate HTTPS natively, so TLS termination logs and privileged operator session records must come from your proxy and admin tooling. |
| Point 3.2.3 access to critical configuration and backup files | Node key files are not encrypted by Besu. Restrict file permissions and monitor reads and changes to key, genesis and configuration paths with host auditing. | Host file integrity monitoring and backup job logs sit outside Besu. Hardware-backed keys through a security module plugin change what is logged. |
| Point 3.2.4 review and alarm thresholds | Define thresholds on peer count, block height lag, sync state and metric gaps in your monitoring tool. Route alarms to an on-call queue. | Alarm tuning, qualified response procedures and records of past alarms. Confirm the thresholds with your own network's normal behavior. |
| Point 3.2.5 retention and protection of logs | Besu writes log output to its configured destination. Ship logs off the node, then apply retention and access controls in the central store. | The regulation sets no fixed retention period. Choose a period with your compliance owner and confirm how backups of logs are protected. |
| Point 3.2.6 time synchronization | Besu timestamps depend on the host clock. Confirm the host uses a synchronized time source and monitor clock offset on every node. | Time source choice, drift alarms and evidence of synchronization belong to the host and platform team. |
| Point 3.2.6 redundancy and independent availability monitoring | Run the metrics endpoint and log shipping from more than one collector. Monitor Besu nodes from a system that does not depend on the same network or host. | Independent watchdog infrastructure, failover of the logging stack and proof that monitoring itself is available. Confirm with your architecture team. |
What to log from Besu nodes and RPC access
Point 3.2.3 of the Annex to Implementing Regulation 2024/2690 lists the categories a monitoring design should cover, and for a Besu network they split across four sources: the Besu node, the reverse proxy in front of JSON-RPC, the host operating system, and the SIEM that correlates them. Besu itself emits only part of this picture. Its node logs record peer connections, block import and consensus activity, and its Prometheus metrics expose resource use and node health. Authentication events for JSON-RPC are where Besu's own behavior matters most, because Besu validates either a username and password credentials file or externally issued JWTs, but it does not terminate HTTPS natively. Failed and successful authentication attempts therefore need to be captured at the TLS-terminating proxy or the identity layer that issues the tokens, with the source address, the account and the method called.
Several categories cannot come from Besu and must be produced on the host or in the SIEM. Privileged activity, user creation, and access to the credentials file, the permissions configuration file and backup files all belong to the operating system audit trail, so the host should record reads and writes to these paths and every sudo or administrative session. Changes to the node permissions and account permissions files are a permission-change category in its own right and should be detected by file integrity monitoring and compared against the change record. The local node private key file is not encrypted, which makes host access to it a logged category too: the audit rule should cover read access by any user or process, not only writes. Where an HSM plugin is used through --security-module, the HSM's own audit log is the authoritative record of signing operations, and the reader should confirm what that device exports.
Physical access and environmental events are outside Besu entirely and sit with the data center or hosting provider. Clock synchronization is a control in its own right: confirm that every node, proxy and SIEM source uses a synchronized time source, because correlated timelines depend on it. Before go-live, ask your team to run a test that produces one event from each category and shows it arriving in the SIEM with a consistent timestamp. Retention periods are not set by the regulation, so agree them with your competent authority's expectations and your own risk assessment, and confirm that logs are protected from change and backed up on a schedule your monitoring design defines.
Evidence auditors and supervisors can ask for
ENISA's June 2025 technical guidance lists examples of evidence for the monitoring and logging point. For a Besu network, the same artifacts have to be produced from the node, RPC and monitoring layers and kept in a form that shows they were not changed after the fact.
SIEM and EDR or XDR records
ENISA lists SIEM systems and EDR or XDR tools as evidence. For Besu, the SIEM should ingest node log output, RPC access logs from whatever sits in front of JSON-RPC, and host telemetry from the machines running validators and RPC nodes. Keep the ingestion configuration, parser rules and the list of log sources as records, not only the dashboards. Confirm with your SIEM vendor how it stores raw events and whether it can prove that stored events were not edited.
Log samples with the 3.2.3 elements
Auditors usually ask for sample extracts showing that logs cover the categories in point 3.2.3, such as authentication events, privileged activity and access to critical configuration. Besu itself does not write every one of these categories in one stream, so pull samples from the RPC gateway, the host audit trail and the change records, and label which source covers which element. Export samples with their original timestamps and hashes so the extract can be matched to the source.
Node permission and account change logs
Changes to Besu node permissioning and account permissioning files are user creation and permission changes in the sense of point 3.2.3. Keep each version of the permissions configuration files under version control, with the approver and deployment time recorded. Compare the file hash on each node against the approved version and retain the diff. Ask your team whether any node has been started with a locally edited permissions file that bypassed the approved change.
Configured alarm thresholds
ENISA expects the alarm thresholds themselves to be shown, not only the alerts they produced. For a Besu network, this means the Prometheus alert rules and the SIEM correlation rules that cover peer count, block import lag, missed validator proposals and RPC error rates. Export the rule files with their version history and the owner who approved each threshold. Explain why each value was chosen, because a supervisor will ask whether the threshold would catch a stalled validator.
Records of past alarms and responses
Point 3.2.4 requires a timely, qualified response to alarms, so the evidence must show the response as well as the trigger. Keep an export of fired alarms from Alertmanager and the SIEM, with acknowledgement time, the person who handled it and the ticket where the response was recorded. For a Besu incident, link the alarm to the node logs and the metric graphs covering the same window. Confirm that alarm history is retained longer than the review cycle, because supervisors may ask about events months earlier.
Time sync and tamper-evident storage
Every artifact above is only useful if its timestamps are reliable and its contents are protected from change. Record the time source used by each Besu host and the monitoring stack, and capture a periodic offset check as evidence. Store logs in write-once or access-restricted storage, and keep hash manifests for exported evidence packs. Note that point 3.2.6 asks for independent monitoring of the monitoring systems, so keep a separate heartbeat for the SIEM and Prometheus.
Configuring Besu monitoring for NIS2 in sequence
This sequence turns a Besu node into a monitored, evidenced component of the monitoring and logging point in the NIS2 Implementing Regulation. Each step produces a record an auditor or competent authority can examine, from metrics exposure and access control through log shipping, alarm thresholds, review and independent availability checks.
Confirm the node inventory and roles
Start by listing every Besu validator, RPC and bootnode in scope, along with the Besu version each runs and the host, cluster or cloud account it sits in. Record which nodes expose JSON-RPC and which only peer. Your network team or platform owners complete this, and the output is a current inventory that every later step references. The step is done when each node has a named owner and a version recorded in your asset register, so monitoring coverage can be checked against a complete list.
Enable the Prometheus metrics endpoint
Turn on the metrics endpoint with the --metrics-enabled option on each node. The default metrics port is 9545, so confirm whether that port is reachable only from your Prometheus servers and restrict it with host firewall or network policy. Keep the endpoint off public interfaces. Your platform engineers make the change and verify it by querying the endpoint from the scrape host. The step is complete when each node returns metrics to the authorized collector and no other network segment can reach the port.
Set JSON-RPC authentication and documented access
Enable JSON-RPC authentication using either a username and password credentials file or JWTs validated against a public key. Choose the method your identity process can rotate and revoke, and store credential files with restricted permissions. Besu does not terminate HTTPS natively, so place a TLS-terminating reverse proxy or gateway in front of RPC and record that TLS is handled upstream. Security engineers review the configuration. The step is complete when unauthenticated RPC calls are rejected in a test and the access design is written down for auditors.
Document the permissions configuration
Write down the node permissions and account permissions configuration files that define which peers and accounts may participate, and how changes to them are approved. Node permissioning restricts connections to known participants, while account permissioning governs onboarding, suspension and restricted actions. Store each file under version control so every change has an author, a reason and a timestamp. The step is complete when a change to a permissions file can be traced in the repository and the authoritative copy matches what each node loads.
Ship logs and metrics to a redundant pipeline
Route node logs and Prometheus metrics into your logging and monitoring stack through at least two collection paths or nodes so one failure does not blind the monitoring. Confirm that the logs carry the categories named in the NIS2 monitoring point, including network traffic, authentication, privileged activity and access to configuration and backup files, to the extent Besu emits them. Where Besu does not emit a category, record the compensating source. Your SOC or platform team owns this. The step is complete when test events from a node arrive in the central store through each path, with the gaps listed.
Synchronize clocks and set retention
Confirm every node, the logging pipeline and the monitoring servers use a synchronized time source, so events from different systems line up in investigations. Set retention and backup for the log store to a period your own policy defines, protect the store from unauthorized changes and restrict who can delete entries. The regulation sets no fixed retention period, so confirm the value with your competent authority guidance and legal team. The step is complete when a sample of logs from several nodes shows consistent timestamps and the retention setting is recorded.
Define alarm thresholds and review cadence
Set alarm thresholds for conditions such as lost peers, stalled block production, rejected transactions, unexpected authentication failures and changes to permissions files. Route alarms to a named on-call rota and decide which trigger automatic response and which need a qualified human decision. Define how often logs and dashboards are reviewed for unusual trends and who signs off. Record each alarm and its response, because past alarms are evidence. The step is complete when a test alarm reaches the responder and the thresholds and review schedule are approved in writing.
Test independent availability monitoring
Confirm that something outside the monitored systems detects when the monitoring itself fails. This can be a separate probe or service that checks whether the metrics endpoint and the logging pipeline are alive and alerts a different team. Simulate a stopped collector or a blocked scrape and confirm the independent check raises an alert. Run the test on a schedule and keep the results. The step is complete when the simulated monitoring failure produces a recorded alert within your agreed response process.
What Besu does not cover for NIS2
Besu gives you node logs, metrics and access controls, but several NIS2 monitoring obligations sit with the operator. The cards below cover the decisions and gaps that remain your responsibility, so they are designed and evidenced before an assessment rather than discovered during one.
Retention period you must set
Point 3.2.5 of the Annex to Implementing Regulation 2024/2690 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes, but it sets no fixed number of days. Your entity must choose a period, justify it against its risk assessment and document it. Check how long your log pipeline and object storage actually keep node, RPC and permissioning logs, and whether backups of those logs are protected to the same standard.
No built-in SIEM or alarm workflow
Besu exposes metrics and logs but does not decide what is suspicious, route alerts or record how they were handled. Point 3.2.4 expects regular review for unusual trends, alarm thresholds, and a timely, qualified response. You will need a SIEM or equivalent, threshold rules for peer loss, block production stalls and RPC authentication failures, and records of past alarms. ENISA lists those records as evidence.
No HTTPS termination in Besu
Besu does not terminate HTTPS natively, so JSON-RPC traffic is unencrypted unless a reverse proxy, load balancer or service mesh terminates TLS in front of it. That layer also becomes a logging point. Confirm where TLS ends, which component writes the authentication and access records, and whether those records include the fields point 3.2.3 requires, such as authentication events and system access.
Unencrypted node key file
Besu documentation states that the local node private key file is not encrypted. Unless you deploy a security module plugin such as the Besu HSM plugin through the --security-module option, the key sits on disk and anyone who can read the host can copy it. Your monitoring should record access to that file and to backup copies, since point 3.2.3 covers access to critical configuration and backup files.
Removed privacy and permissioning features
The maintainers sunset Tessera privacy, onchain permissioning, proof of work and fast sync. Besu 25.6.0 removed Tessera and onchain permissioning, Besu 25.7.0 removed the EEA and PRIV RPC API groups, and Besu 26.4.0 removed Clique. Older runbooks may still reference these features, their log lines or their dashboards, so alerts built on them can silently stop firing. Review old monitoring content against the release you run.
Log field content to confirm
The available facts do not describe every log line or field Besu writes, so you cannot assume that each element point 3.2.3 lists, such as privileged activity, user creation or permission changes, is recorded at the level you need. Test each release in a non-production environment, capture sample logs for each required element, and keep those samples as evidence. Ask the Besu maintainers or your partner to confirm any gap before you rely on it.
Keeping logs through Besu upgrades and rollbacks
Treat every Besu upgrade as a change that can remove your evidence trail, and plan the backup before anything else. The Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and that older Besu versions cannot open an upgraded database. A rollback therefore depends on a backup taken before the upgrade, not on reinstalling the previous binary. Point 3.2.5 of the Annex to Implementing Regulation 2024/2690 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes. Your upgrade runbook should confirm that log archives, not only the chain data, are included in the pre-upgrade backup, and that the retention period you have defined is applied to logs copied off the node before any database change.
Version your logging and monitoring configuration in the same change record as the Besu release. This includes the node startup options that enable metrics (--metrics-enabled), the log level and log file settings, the Prometheus scrape configuration, alert rules and the log shipping agent configuration. Each Besu release can change what is emitted, which metrics names exist and how options behave, so an alarm that worked on one version may silently stop firing on the next. Before upgrading, confirm against the release notes for each version between your current and target release that your log fields, metric names and alarm thresholds still match. Record the result as evidence, along with the alarm tests you ran afterwards. Confirm with your monitoring team how the release notes for each Besu version map to your own change approval steps.
Questions buyers ask before hiring help with Besu NIS2 monitoring
Can we build Besu NIS2 logging and monitoring ourselves?
Yes, if your team already runs a SIEM, operates Besu nodes and can own alarm response. Implementing Regulation 2024/2690 does not require an outside firm. The work is a set of decisions and configurations: which Besu log categories and metrics you collect, how they reach your SIEM, how time is synchronized, how alarm thresholds are set and who answers each alarm. Teams without an existing monitoring stack or without someone who knows Besu logs usually find the mapping and evidence work takes longer than the technical setup. Ask your SIEM owner whether they can name an owner for each point 3.2 element before you decide.
What drives the effort of Besu NIS2 monitoring work?
The main drivers are the number of nodes, how exposed the JSON-RPC endpoints are, what your existing SIEM already ingests, your retention decisions and the number of consortium members whose logs or alarms must be coordinated. More validators and RPC nodes mean more log sources, more metric endpoints and more time sources to check. Public or partner-facing RPC access adds authentication events and access records to review. An existing SIEM with Prometheus or Grafana pipelines shortens integration, while a new stack adds build and testing work. Each driver should appear in the written scope so the quote reflects your environment.
What does DeployOpen need from our team to start?
Expect to provide read access to the Besu nodes, their configuration and the metrics endpoints, plus access to the SIEM or log platform where events will land. You will also need a named SIEM owner who can approve alarm rules and confirm retention settings, and a change approval path for any change to node configuration, log shipping or metrics exposure. Some work touches production validators, so agree maintenance windows in advance. Your security team should also confirm where logs may be stored, since logs must be protected from unauthorized access or change under point 3.2.5.
How long does a Besu NIS2 monitoring engagement take?
Duration depends on the scope agreed in writing, not on a standard timeline. The schedule follows the node count, the number of log and metric pipelines, the state of your SIEM, the number of alarm rules to tune and how many approval cycles your change process needs. Most engagements are fixed-scope, so deliverables and dates are set before work starts. Ask for a schedule that separates design, pipeline build, alarm tuning, evidence collection and handover, because approvals and clock synchronization checks often set the critical path.
What is one-time work and what recurs after go-live?
The one-time work includes the initial log and metric mapping, pipeline configuration, alarm threshold design, time source checks and the first evidence pack. Recurring work covers regular log review for unusual trends, alarm tuning as the network changes, retention and backup checks, monitoring availability checks and refreshing evidence after Besu upgrades. Besu ships releases roughly monthly, so upgrades can change log output or metric names. Ask whether the quote includes ongoing support or a retainer, and whether upgrade testing of the monitoring pipeline is part of it.
Does DeployOpen certify that our Besu network is NIS2 compliant?
No. NIS2 creates no certificate of compliance, and DeployOpen does not issue audit reports, attestations or certifications. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. DeployOpen can help you prepare the monitoring and logging systems, controls and evidence that those reviewers examine, such as log samples, alarm configurations and records of past alarms. Your national authority or an independent auditor makes the assessment, and your legal team should confirm which transposition law applies to your entity.
How long should we keep Besu logs for NIS2?
NIS2 Implementing Regulation 2024/2690 requires logs to be kept and backed up for a predefined period and protected from unauthorized access or changes, but it sets no fixed retention period. Your entity must define the period based on its risk assessment, its national transposition law and any other rules that apply, such as sector regulation. Record the chosen period, the reason for it and how logs are backed up and protected. Confirm the period with your legal and compliance leads before configuring storage, because changing it later can affect evidence you already hold.
How DeployOpen scopes and delivers NIS2 logging and monitoring for Besu
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so Besu node, validator and RPC logs stay in systems you control. We map each log source and alarm to the point 3.2 monitoring and logging requirements, then prepare the evidence your compliance team and national authority may ask to see.
How we scope
- Inventory every Besu validator, boot, RPC and monitoring component, with the log sources each one produces.
- Map each log source against the point 3.2.3 categories and record which ones do not apply and why.
- Agree a fixed-scope written document covering deliverables, responsibilities and timelines before work starts.
How we build
- Configure Besu logging, Prometheus metrics and RPC authentication events to flow into your chosen SIEM or log platform.
- Set clock synchronization for all nodes and collectors, and monitor log pipeline availability independently of the systems being watched.
- Define alarm thresholds for unusual trends, test them with controlled events and document how alerts reach a qualified responder.
How we hand over
- Deliver a runbook covering log retention, protection, backup and access rights for node and RPC logs.
- Provide sample log extracts and alarm records in the form ENISA's June 2025 guidance lists as evidence, ready for your assessors.
- Walk your operations and security teams through dashboards, alert triage and the steps to take when a threshold fires.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering changes to Besu releases and log formats.
- Re-check monitoring coverage after each Besu upgrade, since logging and metrics output can change between releases.
- Confirm with your legal and compliance advisers how the regulation applies to your entity, since DeployOpen prepares evidence but does not issue certifications.
