Hyperledger Fabric operations under DORA ICT risk requirements

Fabric lets peers and orderers keep their MSP signing keys in a hardware security module (HSM) through the PKCS#11 standard, but TLS keys must remain file-based. For a financial entity, this split is the core of how DORA Article 9(4)(d) on protection of cryptographic keys applies to the network. The entity has to document both key classes separately, explain why each is stored where it is, and show that the protection matches the risk. A second practical point follows from this: the prebuilt Fabric Docker images are not built with PKCS#11 support, so any HSM-backed peer or orderer runs on a custom image. That image becomes a controlled artifact with its own build, test, approval and patch record.

The first decision is HSM selection. The entity needs to confirm that the HSM model, its PKCS#11 library and the Fabric release line in use (the 2.5 LTS line or the 3.x line) work together, and it should confirm this with the HSM vendor and against the Fabric documentation rather than assume it. Availability is the second question. A signing key held in one HSM makes that HSM a dependency for every peer and orderer that uses it, so the design should state what happens during an HSM outage, whether a second HSM or a standby is required, and how signing resumes. Cost splits into HSM hardware or service fees, licenses, the effort to build and maintain the custom images, and the support contract. Ask any quote to show these lines separately, along with which items recur each year.

The key ceremony and access policy turn the HSM from a product into a control. The ceremony should be a written procedure that covers how MSP signing keys are generated inside the HSM, who witnesses the process, how the outputs are recorded and how HSM administrator credentials are split so that no single person can use them alone. Access policy should separate the people who administer Fabric nodes from the people who administer the HSM, and it should define who may authorize a key to be used for signing on each peer and orderer. The entity should also decide how HSM partitions, PINs and backups are recorded in its change management process, because DORA Article 9(4)(e) expects changes to be recorded, tested, approved and verified.

TLS keys stay in files because Fabric requires it, so the risk assessment has to justify the file-based design on its own terms. The justification should name the controls that reduce the exposure: restricted file ownership and permissions on the key directories, encrypted storage for the volumes that hold them, limited container access to those paths, certificate renewal and revocation through Fabric CA, and monitoring of the operations service, whose endpoints are secured with mutual TLS client certificates. The assessment should state the residual risk, name the person who accepts it and set a date for review. Confirm with the Fabric documentation and the entity's own security team whether any later release changes this requirement before the assessment is signed off.

Before the design is approved, the entity should run three checks. First, rehearse an HSM failover and a peer or orderer restart that depends on HSM-held keys, and record the results. Second, confirm how the MSP keys in the HSM are included in the backup and recovery plan required by DORA Article 12, since the Fabric upgrade guide's backup step covers the ledger and MSPs, and HSM-held keys follow different recovery rules. Third, collect the ceremony records, access approvals and risk acceptance into one evidence folder that an internal audit team or competent authority can review. Each of these checks produces a document that supports the key protection claim made in the DORA risk file.

The operations service gives your entity the raw signals it needs for DORA continuous monitoring, but it does not monitor anything on its own. Each Fabric peer and orderer exposes a /healthz endpoint for health checks, a /logspec endpoint for reading and changing log levels at runtime, a /version endpoint that reports the running build, and either a Prometheus /metrics endpoint or a StatsD push target. Access to these endpoints is secured with mutual TLS client certificates, so the collector or scraper that reads them needs its own certificate issued from a CA the node trusts. Plan that certificate lifecycle with the same care as the peer and orderer identities, because a monitoring outage caused by an expired collector certificate is still a monitoring gap.

Decide early which collector receives each signal. Prometheus can scrape the metrics endpoint and evaluate alert rules, StatsD collectors can receive pushed metrics, and the logs can go to a log platform your entity runs. Each path should stay inside infrastructure you control, with retention set by your own policy. Confirm the metric names, their meaning and the available log fields against the Fabric version you run, because the set changes between releases. Keep the operations endpoints on internal networks only, and make sure the health check endpoints are reachable by the orchestrator that restarts failed nodes, if you run them on Kubernetes or a similar platform.

DORA Article 9(1) and (2) require continuous monitoring and control of the security and functioning of ICT systems. That obligation sits with your entity. Alert routing, on-call ownership for each peer, orderer and Fabric CA, alert thresholds and the review cadence for alerts and log level changes are decisions only you can make. Fabric does not decide what is an anomaly, so a peer that reports healthy may still be behind on blocks or failing endorsements in a way your rules must catch. Write a runbook that maps each health check failure, metric threshold and unexpected log level change to a named owner, a response expectation and an escalation path, and record who approved it.

Test the design before an auditor or supervisor asks for it. Confirm that a request to an operations endpoint without a valid client certificate is refused. Trigger a controlled peer outage in a non-production network and check that the alert reaches the on-call owner. For ordering, alert on the remaining fault margin rather than only on a single node going down: the Fabric documentation states that a five node Raft cluster tolerates the loss of two nodes, so a second failure must be visible before quorum is at risk. Keep dated records of alert reviews and threshold changes, since they are the evidence that monitoring is operated continuously.

The map earlier on this page ties DORA obligations to Fabric components, but several of those ties depend on details that vary by release, vendor and deployment. Before you rely on it, confirm the points in this section in your own environment and record each answer in your ICT change records. Nothing here should be read as a settled fact about your build. The first item is the exact Fabric version that your peers, orderers and CAs run. Fabric has two lines in parallel: v2.5 is the long-term support release for production users, and the 3.x line receives its own patch releases alongside it. Confirm which version and patch level each node runs, because control behavior and upgrade steps differ between them.

The second item is HSM library support. Fabric uses the PKCS#11 standard to keep peer and orderer MSP keys in an HSM, but TLS keys must remain file-based, and the prebuilt Docker images are not built with PKCS#11 support, so you will run a custom image. Ask your HSM vendor which PKCS#11 library version it supports for the Fabric release you run, how it handles the signing key types your MSP configuration uses (Fabric v3.0 added Ed25519 alongside ECDSA), and whether it provides written support for that combination. Do not assume a library works with a given Fabric build because the interface is standardized. Record the vendor's statement together with the exact version pair it covers.

The third item is whether your custom image passes HSM testing. The image adds the PKCS#11 build and the vendor library, so it becomes a component you own and must test. Run it against the failure cases your continuity plan depends on: a peer or orderer restart with the HSM reachable, a restart with the HSM unreachable, a key rotation, and a restore of a backup onto a replacement host that connects to the same HSM partition. Confirm that signing fails closed and that the failure appears in the logs exposed through the operations service. Rebuild and retest the image whenever Fabric or the vendor library changes, and keep the test results linked to the image digest so that evidence matches the artifact that ran.

The fourth item is the CA database engine. Fabric CA defaults to SQLite and also supports PostgreSQL and MySQL. Several CA servers sharing one database behind a load balancer is the high availability pattern the Fabric CA user guide describes, so a single SQLite file carries a different availability and recovery profile. Decide the engine with your database team, confirm how CA data including issued certificates and revocation state is backed up and restored, and test that losing one CA node does not lose revocations. Finally, confirm whether Fabric-X applies to your use case. LF Decentralized Trust lists it as aimed at regulated digital assets, while permissioned Fabric is the implementation this page covers. If your workload differs, the operational map may not transfer, so validate it against a written scope before you depend on it.