How a Besu network answers ISO 27001 A.8.24 use of cryptography
If you own the ISMS and run or plan a Besu network, the question an auditor will ask under A.8.24 is who decides how cryptography is used and how keys are protected across the life of that network. Besu helps with the technical half: it supports a security module plugin, such as the Besu HSM plugin enabled with the --security-module option, so validator and node keys can sit in hardware-backed storage instead of the node's own key file, which Besu documentation says is not encrypted. Besu does not terminate HTTPS natively, so RPC transport TLS has to be designed in your reverse proxy or gateway. Besu does not write your cryptography policy, decide curve governance, or run key ceremonies. Those are organizational controls you must define, approve and evidence yourself.
A.8.24 Use of cryptography combines two controls from the 2013 edition, A.10.1.1 Policy on the use of cryptographic controls and A.10.1.2 Key management, into one control in the 2022 edition. The control asks for rules on the effective use of cryptography, including key management, to be defined and implemented. For cross-referencing, NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.24 to SC-12 (cryptographic key establishment and management), SC-13 (cryptographic protection) and SC-17 (public key infrastructure certificates). ENISA's mapping for its NIS2 technical implementation guidance links A.8.24 to point 9.1 of the Annex to Commission Implementing Regulation (EU) 2024/2690. NIST states that mapped controls are not always equivalent, so treat these crosswalks as starting points for your own evidence list, not as proof that one artifact satisfies two frameworks.
Before you build the evidence pack, confirm three things with your auditor and your security module vendor: which key types fall in scope (validator, node and any transaction signing keys), where the cryptography policy names them, and whether the HSM plugin version you intend to run is supported on your Besu release. DeployOpen plans, configures and documents these systems and prepares the evidence an assessor will sample. It does not issue audit reports or certifications. Certification is performed by an accredited certification body, and ISO itself does not certify organizations.
Mapping A.8.24 requirements to Besu capabilities and configuration
This table sets each A.8.24 and related requirement against what Besu provides, the configuration you must add, and what stays outside the client. Read each row as a question an assessor will ask, then check whether the answer lives in Besu, in your HSM or PKI, or in your own procedures. The main takeaway is that Besu covers less of the control than its name suggests, so the gaps sit in key custody, transport security and the written rules.
| Requirement | Besu capability from the docs | Configuration needed | Outside Besu |
|---|---|---|---|
| A.8.24 cryptography rules defined and implemented | Besu documents key and API authentication options but no cryptography policy engine | Written rules naming approved curves, key sizes and where each key type may be stored | Policy approval, ownership and review cycle managed by your security function |
| A.8.24 cryptographic key management | Local node private key file is not encrypted; --security-module can route keys to an HSM plugin such as the Besu HSM plugin | Key generation, storage location and access rights recorded per validator and node; HSM plugin installed and tested | HSM operation, key ceremonies, backup of HSM partitions and key rotation procedures |
| A.5.17 authentication information for JSON-RPC | Username and password credentials file, or externally issued JWTs validated against a public key (RS256 to ES512) | Credentials file permissions set; JWT issuer and public key configured; algorithm choice recorded | Identity provider, token issuance, secret rotation and revocation process |
| Transport encryption for RPC and API traffic | Besu does not terminate HTTPS natively | Bind RPC to internal interfaces only and confirm the TLS design with your network team | TLS termination through a reverse proxy or load balancer, certificate issuance and renewal |
| SC-12 key establishment and management (crosswalk) | Node keys and HSM-backed signing support key handling; no built-in key lifecycle records | Key inventory with owner, creation date, location and retirement steps kept alongside the node configuration | Central key inventory tooling and the evidence retention schedule |
| SC-13 cryptographic protection (crosswalk) | Protection depends on the algorithms and transport you configure; Besu does not enforce a single standard | Documented algorithm and protocol list per interface, checked against each Besu upgrade | Validation status of cryptographic modules in your HSM and TLS stack |
| SC-17 public key certificates (crosswalk) | Besu consumes keys and JWT public keys but does not issue certificates | Certificate source, expiry tracking and trust anchors recorded for every endpoint that uses TLS | Internal PKI or public certificate authority, revocation and monitoring of expiry |
| Evidence for an assessor | Logs and Prometheus metrics show node activity, which supports but does not prove key handling | Change records for key and credential changes, plus configuration files under version control | Retention of records, sampling by the auditor and certification body decisions |
Evidence auditors will ask for and how to keep it
Auditors assess A.8.24 by sampling records, not by reading architecture diagrams. The cards below cover the artifacts that tie a Besu network's key handling to a written policy, and each one needs an owner, a location and a retention rule before the first assessment.
Cryptography and key management policy
This is the written rule set that A.8.24 asks for: which algorithms and curves are approved, how keys are generated, stored, rotated and retired, and who may approve exceptions. Map each Besu key class (validator, node, JWT signing, TLS) to a named section of the policy so an auditor can trace a sample key back to a rule. Check that the policy names the HSM plugin and the unencrypted node key file as documented conditions, not defaults nobody reviewed.
Validator and node key inventory
Keep a register listing every validator and node key with its owner, storage location (HSM slot or key file path), generation date, generation method and current status. Auditors often sample this register and then check the live node against it, so the public key or node ID in the record must match what the node reports. Record every key that was generated, copied, exported or destroyed, including test keys that reached a shared environment.
HSM configuration and access logs
Retain the HSM configuration that wires the Besu security module plugin to the node through the --security-module option, along with the partition or slot assignments and the list of operators with access rights. Access logs from the HSM show who used a signing key and when, which is the evidence that supports key custody claims. Confirm with your HSM vendor which audit events the device records and how long they stay on the device before export.
Besu permissions configuration files
The node permissions and account permissions files show which peers and accounts a node accepts, which is part of how access to cryptographic operations is restricted. Version these files in change control and keep the history, because a changed allowlist is a change to network access. Compare the file on each node with the approved copy at regular intervals and keep the comparison output.
JWT signing key and rotation records
When JSON-RPC authentication uses externally issued JWTs, the signing key pair and its public key on the node are cryptographic assets in their own right. Record the algorithm in use (RS256 through ES512 are supported), the key identifier, the rotation schedule, the date each key was activated and retired, and who approved the change. Keep the old public keys long enough to explain tokens issued during any overlap window.
TLS certificate records at the proxy
Besu does not terminate HTTPS natively, so TLS for RPC lives at the reverse proxy or gateway in front of the node. Keep the certificate inventory for that layer: issuing authority, subject names, key type and size, validity dates, renewal dates and the host each certificate is bound to. Auditors check that expired or unknown certificates do not serve RPC traffic, so pair the inventory with a scan or monitoring output that shows what is actually presented.
Choosing key storage: HSM plugin or key file
Where a hardware security module is available, the Besu HSM plugin is started through the --security-module option, so the signing operation for validator and node keys runs inside the module rather than from a key file that Besu reads directly. This shifts much of the key protection question to the HSM vendor's controls for key generation, access, backup and audit logging, and it moves evidence collection toward the module's own logs and configuration.
- Module ownership: Record who administers the HSM, who holds its credentials, and how operator access is approved and reviewed.
- Key generation: Document whether keys are generated inside the module and whether any exportable copy is ever created.
- Plugin version pinning: Track the plugin version alongside the Besu release, since both are upgraded on separate schedules.
- Failure behavior: Test what happens when the module is unreachable, so validators do not fail silently during an outage.
- Audit trail: Keep HSM logs for key use and administrative actions in a location the security team controls.
Confirm with the HSM vendor which key types, signing mechanisms and curves the module supports for your validator setup, and confirm with the plugin maintainers which Besu versions the plugin is tested against.
When no HSM is available, the node private key is held in a file. Besu documentation states that this file is not encrypted, so the protection of the key rests on file system permissions, host hardening, backup handling and the surrounding operating procedures. An assessor will expect the risk treatment for this choice to be explicit, accepted by an owner, and reviewed on a defined cycle.
- Restricted access: Limit read access to the Besu service account and named administrators, and verify those permissions after every host rebuild.
- Encrypted storage: Place the key on an encrypted volume where the platform supports it, and document the key used to unlock that volume.
- Backup handling: Treat backups of the key file as sensitive copies, with their own access rules and retention.
- Compensating monitoring: Alert on changes to the key file's ownership, permissions and checksum.
- Documented acceptance: Record the residual risk, the owner who accepted it, and the conditions that would trigger a move to an HSM.
Confirm with your own risk owner whether an unencrypted key file meets your ISMS risk criteria for validator keys, since that decision is yours to make and document.
The choice between the two paths changes how the ISMS risk assessment for key compromise is written. Under the HSM path, the risk treatment relies on a third-party module and its administrative controls, so the register entry should name the module, its owner and the dependencies on it. Under the key file path, the treatment depends on host controls, and the register should show the compensating controls as implemented rather than planned.
- Risk entry wording: Describe the specific asset, the threat of key disclosure, and the treatment chosen.
- Residual risk: State the residual risk in plain terms that the accepting owner signs off on.
- Control mapping: Link each compensating control to the Annex A control it supports, such as A.8.24 for cryptographic key management and A.5.17 for authentication information.
- Review trigger: Set a review when the Besu release, the HSM plugin or the host platform changes.
- Evidence location: Store the decision record with the key inventory so an auditor can trace it.
Confirm the final wording with your certification body or internal audit before the assessment, since they decide how they will sample these records.
Before choosing a path, several facts depend on your environment and on third parties, and they should be confirmed in writing rather than assumed. The Besu documentation describes the option, but the behavior of a specific module with a specific Besu release must be verified in a test network before production use.
- HSM vendor: Ask which key algorithms and curves are supported, how keys are backed up, and what audit logs are produced.
- Plugin maintainers: Ask which Besu releases the plugin supports and how it is tested after each Besu release.
- Failover design: Ask how signing continues during module maintenance, and whether a second module is available.
- Key inventory: Confirm that every validator and node key is listed, with its storage location and owner.
- Exit path: Confirm how a key moves from a file to a module, or between modules, without changing validator identity.
Record the answers with the risk decision so the choice can be reviewed when any of these facts change.
Curve choice and TLS for RPC in practice
Besu does not terminate HTTPS natively, so the transport security for JSON-RPC has to come from a reverse proxy, load balancer or API gateway placed in front of each RPC endpoint. That component becomes part of the cryptography story for A.8.24: it holds the TLS certificates, selects protocol versions and cipher suites, and terminates the connection before Besu sees the request. Put it inside the ISMS scope, give it an owner, and record its configuration in the same key management register as the validator keys. Confirm with your network team whether traffic between the proxy and the Besu node stays on a private segment or is also encrypted, because an auditor will ask where plaintext credentials could appear.
Authentication sits on top of that transport layer. Besu supports either a username and password credentials file or JWTs validated against a public key, using RS256, RS384, RS512, ES256, ES384 or ES512. Each option carries different key material: the credentials file needs protected storage and a rotation procedure, while the JWT option moves signing keys to your identity provider and requires you to document which issuer and which public key Besu trusts. Choose the algorithm family from your organization's approved cryptography list, not from the Besu defaults, and confirm with your assessor whether RSA key sizes or ECDSA curves on that list match the expectations in your certification scope. This document does not treat any of these algorithms as compliant on its own.
Before go-live, ask the team to produce three records: the TLS configuration exported from the proxy (protocol versions, cipher suites and certificate chain), the JWT validation settings with the accepted algorithms and issuer, and a list of who can change either. Test that Besu rejects requests that do not present valid credentials and that the proxy refuses deprecated protocol versions. Revisit these records whenever a Besu release changes JSON-RPC behavior, since release notes for each version should be checked against your settings before upgrading. Your reference for the control itself is the A.8.24 entry in ISO/IEC 27001:2022, which you should read alongside your internal cryptography standard.
What Besu does not cover under A.8.24
Besu gives you key handling options, but A.8.24 is an organizational control. The cards below cover the policy, certificate, custody and rotation decisions that sit outside the Besu node and must be documented by the organization. They also flag where a mapping to another framework is a starting point, not proof of equivalence.
Cryptography policy and approval
A.8.24 asks for rules on the effective use of cryptography to be defined and implemented. Besu does not write that policy. Your organization must decide which algorithms, curves and key lengths are approved for validator, node and RPC keys, record who approved them, and show that the Besu configuration matches the approved list. Check that the policy names the Besu version and curve settings in use, and that it is reviewed when you plan a client upgrade.
PKI and certificate lifecycle
Besu does not terminate HTTPS natively, so TLS certificates for RPC endpoints come from a reverse proxy, load balancer or service mesh that you run. Issuance, renewal, revocation and trust chain management belong to your public key infrastructure, not to Besu. Confirm who issues these certificates, how renewal is monitored, and how a certificate expiry on an RPC endpoint would be detected and escalated before it causes an outage.
Key ceremonies and custody
Generating, witnessing, storing and destroying validator and node keys is a process run by people. Besu's node private key file is not encrypted, and an HSM plugin changes where keys are held but not who is authorized to start a signing operation. Define who may perform key generation, how the ceremony is witnessed and logged, who holds custody of backups, and what evidence is kept for each key event.
Rotation schedules set by your organization
Besu does not set a rotation period for validator, node or RPC credentials. Your policy must define rotation intervals for each key class, the trigger for an unscheduled rotation such as suspected compromise or staff departure, and the steps to replace a validator key without losing quorum. Check how the Besu JSON-RPC credentials file or JWT signing key is rotated and whether the change is recorded in your change process.
Removed features that changed the key picture
Besu removed the Tessera privacy feature and onchain permissioning in 25.6.0, removed the EEA and PRIV privacy RPC API groups in 25.7.0, and removed Clique consensus in 26.4.0. Any key or privacy design that relied on those features must be re-assessed. If your inventory still references them, update the cryptography documentation and confirm which replacement, such as a plugin or a different privacy approach, now protects the relevant keys and data.
Mapped controls are not equivalent
NIST's crosswalk relates A.8.24 to SC-12, SC-13 and SC-17, and ENISA's mapping links it to point 9.1 of the NIS2 implementing regulation annex. NIST itself cautions that mapped controls are not always equivalent. Use these mappings to find evidence, not to claim compliance. ISO/IEC 27002:2022 gives guidance on the Annex A controls and cannot itself be certified to. Only an accredited certification body can assess your ISMS against ISO/IEC 27001.
Configuration sequence for A.8.24 readiness
This sequence turns A.8.24 from a policy statement into a set of Besu settings, key records and evidence that an assessor can sample. Each step closes with an output you can show the certification body.
Define cryptography rules and scope
The information security lead and the network owner write a short cryptography rule set for the Besu network. It covers which keys exist, which algorithms and curves are approved, who may generate, rotate and retire keys, and which systems are in scope, including validator nodes, RPC nodes, JSON-RPC authentication and TLS endpoints. Legal and contractual requirements for key custody, which relate to A.5.31, should be recorded alongside. The step is done when the rule set is approved and linked to the ISMS scope document.
Inventory every key and its location
The platform engineer lists each key the network uses: validator keys, node keys, JWT signing keys for JSON-RPC authentication, TLS certificate keys at the gateway, and any transaction signing keys held outside Besu. For each entry, record the owner, storage location, algorithm and curve, creation date, rotation trigger and the node or service that depends on it. The inventory is complete when every running node and gateway can be traced to its key records, and a sample check on two nodes matches the register.
Select key storage and record the risk treatment
For each validator and node key, the team chooses between hardware-backed storage and a key file. Besu documentation states that the local node private key file is not encrypted, so a file-based choice needs a documented risk treatment covering host access, file permissions, backups and monitoring. Where a hardware security module is used, the team confirms with the vendor that the module supports the chosen curve and the Besu HSM plugin path. The step closes with a signed decision record for each key class.
Configure the security module or file permissions
For HSM-backed keys, the platform engineer starts Besu with the --security-module option and the plugin settings the HSM plugin documentation requires, then confirms the node signs blocks through the module. For file-based keys, the engineer restricts read access to the Besu service account and confirms ownership and mode on the key file and its directory. The check is a captured startup log showing the chosen storage mode and a permission listing of the key file, both attached to the key record.
Enable JSON-RPC authentication and TLS at the gateway
The platform team enables JSON-RPC authentication, either with a credentials file or with JWTs validated against a public key using an approved algorithm such as ES256 or RS256. Besu does not terminate HTTPS natively, so TLS is terminated at a reverse proxy or gateway that the team operates, with certificate issuance and renewal recorded against the key inventory. The verification is a rejected unauthenticated request and an accepted authenticated request, plus a TLS scan of the gateway showing the approved protocol versions.
Set up metrics and logs for key events
The operations team turns on metrics with --metrics-enabled, forwards node logs to the central logging platform, and sets retention in line with the ISMS log policy. They confirm which key-related events appear in the logs, such as startup with a security module, authentication failures and configuration changes, and set alerts on the events that matter. Clock synchronization on every node should be confirmed so log timestamps can be correlated. The step closes with a test event that appears in the log store and triggers the alert.
Rehearse backup and restore before each upgrade
Before every Besu upgrade, the operations team takes a backup of node data and key material, then restores it on a segregated system. The Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and older versions cannot open an upgraded database, so the restore test is the only proof that rollback works. The step is done when the restored node starts on the prior version and the test record, including who ran it and the outcome, is filed with the change record.
Assemble the evidence pack for the certification body
The ISMS owner collects the cryptography rule set, key inventory, storage decision records, startup and permission evidence, gateway TLS scans, log samples, alert tests, restore records and change records into one indexed pack. Each artifact is mapped to A.8.24 and to the related controls the organization has chosen. The pack is ready when a team member who did not build the network can locate each item within a few minutes. Certification decisions rest with the accredited certification body, so the pack should be reviewed with them before the audit window opens.
Questions buyers ask before hiring help for A.8.24 on Besu
Can a Hyperledger Besu network be ISO 27001 certified?
No. A network, software product or node cannot be ISO/IEC 27001 certified. Certification applies to the organization's information security management system, and an accredited certification body audits that system. What a Besu network can do is provide evidence for the A.8.24 part of that system: documented cryptography rules, how validator and node keys are generated and stored, TLS configuration for RPC, and records of key handling. The auditor decides whether that evidence is sufficient. ISO does not certify organizations either; certification bodies do, and they operate to the ISO/IEC 17021-1 and ISO/IEC 27006-1 requirements. Confirm the scope and certification body with your own compliance lead before you plan the evidence.
How long does an A.8.24 key management readiness project take?
The duration depends on how much of the key lifecycle already exists in writing. The main drivers are the number of validator and node keys in scope, whether an HSM is already in place or must be selected, how many organizations share the network and must agree on key ownership, and whether the cryptography policy and key-handling procedures exist or need to be written. Work that usually takes the longest is agreeing on who approves key generation and rotation, and producing evidence that shows the process has run. Ask for a timeline in the written scope, with milestones tied to deliverables such as the key inventory, the HSM configuration record and the key handling procedure.
What does a Besu key management engagement cost, and what drives the price?
Cost depends on scope, HSM choice, number of nodes and the maturity of your existing information security management system. Scope sets how many validators, RPC nodes and signing paths need documentation and testing. HSM choice affects the hardware or cloud key service you buy, its licensing and its integration effort, and whether the Besu security module plugin needs to be built and tested in your environment. Node count multiplies configuration, verification and evidence work. ISMS maturity decides whether the project adds controls or only maps existing ones. Ask for a fixed-scope quote that lists each deliverable, the environments covered, what is one-time and what recurs (for example, key rotation reviews), and which items you must provide, such as HSM hardware or cloud accounts.
What does the work need from our security and platform teams?
The engagement needs named people from both teams for the whole project. Security owns the cryptography policy, approval of key generation and rotation, the HSM access model and the evidence standard that the certification body will expect. The platform team owns node hosts, the TLS termination design, the secrets path into the node and the change process for node restarts. Both teams must review the key inventory and sign off on the records. Expect the platform team to provide access to test environments and the HSM, and expect security to make decisions on exceptions quickly, because undecided exceptions are the most common cause of schedule slips.
Can our own team implement A.8.24 controls for Besu without outside help?
Yes, if your team has engineers who understand Besu node configuration, HSM integration and TLS, and a compliance lead who can translate the controls into evidence. Many teams start internally and bring in a partner for specific gaps. The questions to answer first are whether the team has run key ceremonies before, whether it can test HSM failover and key recovery, and whether it will keep the records current after go-live. Build an internal plan that lists the controls, owners, evidence and review dates, then compare it with the written scope from a partner. Using the Besu documentation on node keys and the permissioning and RPC authentication pages will help you check what the software already supports and what you must confirm in your own environment.
Which parts of the Besu key setup need the most attention?
The local node private key file is not encrypted, so the most important decision is whether that file is protected by file permissions and disk controls alone or moved into hardware-backed storage. Besu supports a security module plugin, such as the Besu HSM plugin, enabled with the --security-module option, but you must confirm compatibility with your Besu version and HSM. Other areas that need attention are TLS for RPC, because Besu does not terminate HTTPS natively, so a reverse proxy or load balancer must handle it, and JSON-RPC authentication, which uses a credentials file or JWTs validated against a public key. Each setting should appear in your key inventory and configuration records.
Which standards and frameworks does A.8.24 map to?
A.8.24 covers rules for the effective use of cryptography, including key management. NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.24 to SC-12, SC-13 and SC-17, and NIST notes that mapped controls are not always equivalent, so check each mapping against your own control set. ENISA's mapping for its NIS2 technical implementation guidance links A.8.24 to point 9.1 on cryptography in the annex to Commission Implementing Regulation (EU) 2024/2690. Closely related Annex A controls include A.5.31 on legal and regulatory requirements and A.5.17 on authentication information. Ask your certification body and your regulator which mapping they accept before you design the evidence set.
Who owns what between your team and DeployOpen
Your organization owns the ISMS, and that ownership cannot be delegated. Under ISO/IEC 27001:2022, the information security management system, its policies, risk treatment decisions and the Statement of Applicability belong to your organization. Your management approves the cryptography policy that A.8.24 requires, decides which keys are in scope, accepts residual risk and chooses the certification body. Your compliance lead also owns the relationship with that body. DeployOpen does not issue audit reports, attestations or certificates, and nothing in this engagement should be presented to an auditor as if it did. Confirm internally who signs the cryptography policy and who owns the key register before the scope is written.
DeployOpen works inside a written, fixed scope. Within that scope, DeployOpen plans and configures the node and key handling for your Besu validators and RPC nodes, including where validator keys are generated and held, how the --security-module option is wired to an HSM plugin where you choose that route, TLS termination in front of JSON-RPC, and how authentication settings are applied. DeployOpen also prepares the evidence that your auditor will sample, such as configuration baselines, key lifecycle records and change logs, and documents how those records are produced. Your team supplies the HSM, the certificate authority, the infrastructure and access to the people who approve changes. Ask for the scope to name each artifact, its owner and its acceptance criteria, so gaps are visible before go-live.
Ongoing work is separate from the implementation scope. Key rotation, periodic evidence collection, Besu client upgrades and monitoring of key-related alerts continue after handover. These can be covered by a retainer for ongoing support, upgrades and continuous testing, which is priced and written separately from the fixed-scope build. When you compare options, ask who performs each recurring task, how often it runs, and who reviews the output. Those answers determine whether your team can sustain the A.8.24 controls once the project closes, which is the question an assessor will test first.
How DeployOpen scopes and delivers A.8.24 readiness for Besu
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Hyperledger Besu networks. For validator keys and A.8.24, we agree a written scope first, build the key handling and TLS controls in your environment, and leave you with the records an assessor will ask to see.
How we scope
- Written scope lists which Besu nodes, validators and RPC endpoints are in and which key stores they use.
- We map your existing cryptography rules and key lifecycle records against A.8.24 and the controls it draws on.
- We confirm with your team and vendors which HSM or security module approach is supported for your node versions.
How we build
- We configure validator and node keys in the HSM or security module you choose, or document the key file controls if no HSM is used.
- We set up TLS and JSON-RPC authentication for API access, then test each endpoint against the agreed configuration.
- We record curve choices, key generation steps, access roles and rotation procedures as operating documentation.
How we hand over
- You receive configuration files, runbooks and key handling records mapped to the agreed A.8.24 scope.
- Test results show which cryptographic settings were verified, with the evidence location for each control.
- Your team is trained to run key rotation, backup of key material and access reviews without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Changes to Besu versions, HSM plugins or key policy are re-checked against the agreed scope before rollout.
- We prepare systems and evidence for your assessment, while independent certification bodies issue any certification.
