Besu key management for NIST SP 800-53 SC-12

Hyperledger Besu key management against NIST SP 800-53 SC-12: what the platform covers and what it does not

Besu can support parts of SC-12 through its configuration and documented key handling, but the key management policy, ownership, rotation rules and evidence of operation remain the organization's responsibility. SC-12, Cryptographic Key Establishment and Management, is a base control in the System and Communications Protection family of NIST SP 800-53 Rev. 5. It requires an organization to establish and manage cryptographic keys wherever cryptography is used in the system, according to defined key management requirements. Besu, an Apache 2.0 licensed Ethereum execution client, does not define those requirements for you. It gives you specific mechanisms to point at: the node private key file, the security module option for hardware-backed storage, and the separation of JSON-RPC authentication credentials and keys. Each of these is a configuration fact an assessor can check, but none of them is an assessment result on its own.

The platform documentation states that the local node private key file is not encrypted. That single fact shapes the SC-12 narrative for any entity running validators or nodes in production. Where the key must be protected by hardware, the Besu HSM plugin is loaded through the --security-module option, and the team must confirm with the plugin's maintainers which HSM families, key types and curves it supports in your environment. Permissioning files, JSON-RPC credential files and JWT public keys also hold trust material, and each needs a documented owner, storage location and change path. Besu's own documentation does not replace your key inventory, your generation procedure or your records of who handled each key.

DeployOpen plans and documents this work, prepares the configuration baselines, key handling procedures and evidence the assessment team will examine, and tests the configuration against those procedures. DeployOpen does not issue assessment results, attestations or certifications. Independent assessors make that determination against the SP 800-53A procedures for SC-12, which examine cryptographic mechanisms, system design documentation, configuration settings and audit records. Before scoping work, confirm with your assessor which baseline applies to your system (SP 800-53B selects SC-12 for the low, moderate and high baselines), which SC-12 enhancements are in scope, and which evidence they will accept.

Mapping SC-12 requirements and examine objects to Besu configuration

This table pairs each SC-12 assessment object from SP 800-53A with the Besu setting, file or record that can serve as evidence. Read each row as a question to answer for your own deployment, since the entity must define its key management requirements before any row can be satisfied.

Assessment object	What Besu provides	Evidence to prepare
Cryptographic mechanisms	Node private key file, which Besu documents as not encrypted; optional --security-module option with the Besu HSM plugin for hardware-backed keys	Key generation records, key storage location, HSM configuration and the plugin version in use
System design documentation	Node roles, validator set and where each node private key lives; the entity's own key management requirements, which SC-12 expects the organization to define	Key management standard written for the network, signed by the control owner, mapped to each key type
System configuration settings	Startup flags such as --security-module, --metrics-enabled and JSON-RPC authentication settings in the node configuration	Versioned configuration files, change history and a record of the settings active on each node
JSON-RPC authentication	Username and password credentials file, or externally issued JWTs validated against a public key; Besu does not terminate HTTPS natively	Credential handling procedure, JWT issuer and key rotation records, and the TLS termination design in front of Besu
Permissioning files	Node permissions and account permissions configuration files that restrict connections and onboard or suspend accounts	Current permissions files, approval records for each entry and the process for suspending access
System audit records	Metrics exposed for Prometheus when --metrics-enabled is set, with a default endpoint port of 9545	Retained metric and log data showing node identity, access and configuration changes over time
Organization-defined parameter (SC-12)	Besu does not set the parameter; it depends on the requirements the entity writes	Defined key lifecycle requirements for generation, storage, rotation and destruction, confirmed with the assessor before testing
SC-12(1) enhancement	Selected in the high baseline; confirm whether it applies to your system impact level before scoping	Written confirmation of applicability from your authorizing official or compliance lead

Why the default node key file needs a documented decision

The Besu documentation states that the local node private key file is not encrypted. That single fact forces a decision you must document before an SC-12 assessment: either accept file-based key handling and defend it with compensating controls, or move the node key into a hardware-backed security module. Assessors do not expect every organization to choose the same option, but they do expect the choice to be deliberate, recorded and matched to the actual deployment. A node key that sits in a plain file with no stated rationale reads as an unmanaged key, whatever the team intended.

If you keep the file, the assessor will examine what protects it in practice. Expect questions about the operating system permissions on the key file and its parent directory, which service accounts can read it, and whether it lives on the same volume as the ledger data or in a location covered by your host hardening baseline. They will ask how key material is included in backups, who can restore it, where those copies are stored and whether restores are tested. They will also ask whether access to the key file or its directory is logged and reviewed. Write each answer down with the file path, the owner, the permission mode and the evidence source, such as a configuration extract or an audit record.

If you plan to use an HSM through the Besu HSM plugin with the --security-module option, confirm several points before you rely on it. Ask the plugin maintainers which HSM models, firmware levels and Besu versions they have tested, how the signing key is generated and whether it can be exported, how the node behaves when the HSM is unreachable, and how the plugin is versioned and patched against your Besu release cadence. Confirm with your HSM vendor which FIPS 140 validation applies to your exact module and firmware, rather than assuming it. Record the answers in your SC-12 narrative, because an assessor will ask who in your organization owns the plugin and its upgrade.

Evidence assessors examine for Besu key management and how to keep it

An SC-12 assessment is decided by whether the evidence matches the system as it runs today. The items below connect the written key management requirements to the configuration, hardware and records an assessor will sample, and each needs an owner who refreshes it after every Besu release.

Key management requirements document

This is the defined set of key management requirements that SC-12 measures the system against. It should state which key classes exist (node, validator and signing), who owns each, how long each is valid, and how generation, storage, rotation and destruction are handled. Check that every key class named here appears in the configuration and HSM records below. Review it when the Besu version changes, since a new release can change how a key is loaded or which module supports it. Keep prior versions so an assessor can see what was in force during the assessment period.

System design documentation with key classes

Design documentation should show where each key class lives: the local node private key file, validator signing keys and any transaction signing keys held outside Besu. For each, record the storage location, the process that reads it, and the systems that can reach it. The Besu documentation states that the local node private key file is not encrypted, so the design must say whether that file is used at all in production. Assessors often trace a key from generation to use, so diagrams should match the deployed topology, including Kubernetes secrets or volumes if they are used.

Configuration files and launch parameters

Assessors sample the launch configuration to confirm that the design is what runs. Capture the exact flags used to start each node, including --security-module where an HSM plugin is used, and the file paths for keys and credentials. Store these in version control with change records, so each change maps to an approval. Compare the flags after every Besu upgrade, because a release can rename or retire options. Redact secrets from the copy you provide, but keep a record of what was set and when.

HSM configuration and access records

Where a security module plugin such as the Besu HSM plugin is used, the HSM configuration, partition and key object inventory, and operator access logs are the core evidence. Confirm which HSM and which plugin version are approved, and check that the plugin release matches the Besu release in production. Access records should show who can use the signing material, how credentials are issued and revoked, and how a failed or replaced HSM is handled. Ask your HSM vendor which audit logs it produces and retains, and confirm them before the assessment window opens.

Permissioning configuration and metrics as audit records

Permissioning files show which nodes and accounts are allowed to connect and transact, which supports the control over who can use keys on the network. Keep a dated copy of each node permissions file with the change that produced it. Metrics exposed through --metrics-enabled and the logs from nodes and RPC access can serve as audit records if they are retained and time-synchronized. Set a retention period with your records team and confirm that exported Prometheus or log data is protected from edits. Sample both, since a reviewer will ask whether a logged event matches a recorded change.

Node, validator and signing keys: different controls for different roles

A node key identifies a Besu node to its peers. Besu writes the node private key to a file in the data directory, and the public key derived from it forms the node's enode identity. The Besu documentation states that this key file is not encrypted, so the protection of the file depends on the operating system controls around it. Permissioning files on other nodes often list peers by enode, which means a rotated node key also changes the identity that other operators must allow.

Generation: Confirm whether your deployment lets Besu create the key on first start or whether your platform team generates and places it, and record which method your runbook uses.
Storage: Restrict read access to the Besu service account and the data directory, and keep the key out of images, repositories and shared volumes.
Rotation: Define the trigger, such as suspected compromise or a node rebuild, and the steps to update permissioning files across the consortium.
Access: Limit who can read the key file, and log administrative access to the host.
Backup: Decide whether the key is included in node backups and how that backup is itself protected.

Assessors typically look for a written rule for each of these points and evidence that the host controls match it.

A QBFT validator signs the blocks it proposes and votes on, so compromise of a validator key lets an attacker sign for that validator. Besu documentation describes a security module plugin, such as the Besu HSM plugin, that a node loads with the --security-module option so that the signing key can live in hardware. Confirm with the plugin's maintainers which key types and HSM models your version supports, because support varies by release and by vendor.

Generation: Generate validator keys inside the HSM where the module allows it, and document the key ceremony, witnesses and the resulting public key or address.
Storage: Confirm the signing key never leaves the HSM in plaintext, and record the HSM partition and access policy that holds it.
Rotation: Changing a validator changes the validator set, so treat rotation as a QBFT change with approvals, not as a file swap. The QBFT validator management content covers the voting and transition steps.
Access: Separate the people who administer the HSM from those who operate the Besu node, and record every administrator action.
Recovery: Plan how a replacement validator is provisioned if an HSM fails, and test that path on segregated systems.

The key ceremony record and HSM access logs are usually the first items an assessor requests.

Configuring Besu key management so SC-12 evidence exists before assessment

This sequence turns Besu key handling into a set of documented decisions, configured settings and retrievable records, so an assessor examining SC-12 finds evidence already in place rather than reconstructed later.

Define key management requirements for the network
Write down which keys the network depends on, who owns each key type, how keys are generated, rotated, backed up and retired, and which policy each requirement answers to. Your organization's own key management policy is the starting point. SC-12 expects these requirements to be defined before the system is assessed, so this document is the first artifact an assessor will ask for. The step is done when every key type has a named owner and a written lifecycle rule approved by the control owner.
Classify each key by role and exposure
Inventory the node private key, validator signing keys, RPC credentials, JWT signing keys and any transaction signing keys held outside Besu. Classify each by what it authorizes and what happens if it is copied or lost. Record where each key lives today and which system reads it. The output is a key inventory table linked to the requirements from the previous step, which lets an assessor trace each key to a decision. Confirm with your security team whether any key falls under other control families before finalizing the classes.
Choose file-based or security module storage
For each key class, decide whether it stays in a key file on a restricted host or moves to a hardware-backed security module. Besu's documentation states that the local node private key file is not encrypted, so a file-based choice needs compensating controls recorded in the decision. Where a hardware security module is used, confirm the vendor, module plugin and supported configuration with the plugin maintainers and your module vendor. The output is a signed storage decision per key class, which the assessor will compare against the cryptographic mechanisms in your system design documentation.
Configure the node with the security module option
Where a security module is chosen, configure the Besu node to use it with the --security-module option and the plugin your decision named, and keep the configuration under version control. Confirm that the node starts, signs with the module and does not fall back to a file key without a logged reason. The artifact is the node configuration file and a short test record showing the signing path in use. Keep the test on a non-production network first and retain the output for the assessment file.
Restrict file access and keep key material off shared hosts
Set ownership and permissions on the node key file and any validator key material so only the Besu service account can read it, and confirm that backups, container images and build logs do not contain copies. Record the permission settings with the command output and the host baseline that enforces them. Where keys are mounted into containers, document the secret source and the mount path. An assessor examining configuration settings will look for this evidence, and a retained permission listing is the simplest way to show it.
Enable metrics and logs for key-related events
Enable Besu metrics with the --metrics-enabled option and forward node logs to your central logging platform, so that restarts, signing-module errors, peer changes and configuration reloads leave a trail. Confirm the Prometheus endpoint is reachable only from your monitoring network. The evidence is a dashboard or log query that shows key-relevant events for a sample period, along with the alert rules that route them to the owner. Assessors reviewing audit records will ask whether these events can be retrieved, so test a retrieval before the assessment.
Document permissioning and authentication configuration
Record the node and account permissioning files, the JSON-RPC authentication method (a username and password credentials file or JWT validation against a public key) and how TLS is terminated in front of the node, since Besu does not terminate HTTPS natively. Tie each setting to the key or account it protects. Store the files and their change history together. This gives the assessor a single view of who and what can reach the signing path and how that access was approved.
Rehearse an evidence pull before the assessment
Run a dry-run in which a named person collects every artifact from the previous steps within a set window, without help from the engineers who built the configuration. Check that the requirements, key inventory, storage decisions, configuration files, permission listings, log queries and permissioning records all exist, match each other and carry dates. Record gaps and close them. The completed rehearsal, with its findings and fixes, becomes the index assessors use, and confirming the approach with your assessor or control owner beforehand avoids surprises.

What Besu does not cover for SC-12

The Besu client handles part of the key picture, but SC-12 is assessed at the level of the whole system. The cards below list the gaps your organization must document, decide or evidence itself, with DeployOpen preparing that evidence for an independent assessor to examine.

Organization-defined parameter and key policy

SC-12 includes one organization-defined parameter, so the assessor expects you to state the key management requirements yourself. Besu will not choose key lengths, algorithms, rotation intervals or key owners for you. Write a key policy that names each key class in scope (node keys, validator keys, RPC credentials and signing keys), the requirement for each, and who approves exceptions. Confirm that the policy matches what the node configuration actually does.

HSM provisioning and key ceremony

Besu documents that the local node private key file is not encrypted, and that hardware-backed storage needs a security module plugin selected with the --security-module option. The plugin choice does not settle how keys enter the HSM, who is present at generation, how key material is split or backed up, or how the ceremony is recorded. Define these steps as a written procedure and keep the signed records as evidence.

FIPS validation of the HSM and modules

Whether the HSM, its client library and any cryptographic module used for keys carry FIPS 140 validation is a fact about that product, not about Besu. Confirm the exact model, firmware and module version with the vendor, then check its listing on the NIST Cryptographic Module Validation Program (CMVP) yourself. Record the certificate number and the validated boundary in your evidence, because the assessor will ask which module protects which key.

Rotation and destruction procedures

SC-12 covers the full key lifecycle, which includes rotation and secure destruction. Besu can replace a node key by starting with a new key, but it does not manage retirement of old validator keys, removal of copies from backups or archived configuration, or proof that a retired key no longer signs. Document the trigger for each rotation, the steps for validator key changes in the QBFT set, and the destruction method and witness for every retired copy.

Staff roles shown in interviews

Assessors test SC-12 with interviews as well as documents, so people who generate, hold, approve and destroy keys must be able to describe their part of the process. Define separate roles for key custodians, approvers and administrators of the HSM, and confirm that deputies exist for each. Keep training and access records that match the roles the interviewees describe.

TLS for RPC outside the client

Besu does not terminate HTTPS natively, so transport encryption for JSON-RPC sits in a reverse proxy, load balancer or ingress that you operate. Besu's JSON-RPC authentication can use a credentials file or JWTs validated against a public key, but the certificates, their key storage and their rotation belong to the surrounding infrastructure. Include that component in the SC-12 scope, because keys it holds are cryptographic keys the system depends on.

Where SC-12 applies beyond federal systems

SC-12 reaches beyond federal agencies through two routes: the FedRAMP Rev5 baselines, which require SC-12 at Classes B, C and D (with SC-12(1) at Class D), and NIST SP 800-171 Rev. 3, which derives requirement 03.13.10 (Cryptographic Key Establishment and Management) from the same control. Most regulated financial entities will not be assessed against FedRAMP directly, because FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A Besu network that your organization runs in its own data centers or cloud accounts, for its own tokenization or settlement purposes, generally sits outside that scope. Confirm this with your compliance lead and any contracting agency before relying on it, because a cloud service offered to an agency would be treated differently.

Even outside FedRAMP, the control language is useful. Customers, auditors and regulators in your sector may ask you to map your key handling to SC-12, and a Besu operator can reuse the same evidence: a written key management standard, records of how validator and node keys were generated and stored, and proof that access was restricted and reviewed. Treat SC-12 as a vocabulary for internal and contractual assurance, and ask your assessor which requirement identifiers they will use so that one evidence set serves all of them.

If the network will process criminal justice information, the FBI CJIS Security Policy adds a specific rule. Version 6.1, which took effect on 26 June 2026, requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, up from 128-bit, according to the California DOJ bulletin 2026-ISRS-001. Confirm with your CJIS Systems Agency how this applies to any key material used by Besu nodes, and check whether the planned HSM or key storage option meets the FIPS requirement before the design is fixed.

Questions buyers ask about SC-12 and Besu key management

How much effort does SC-12 documentation take for a Besu network?

The effort depends mostly on how many key types the network uses, how many nodes hold them, and whether the key lifecycle is already written down. A small permissioned network with a few validators and one RPC tier needs a documented inventory of node keys, validator keys and any signing keys, plus the generation, storage, rotation and destruction procedures for each. Larger consortium networks add more nodes, more operators and more evidence to collect. Existing key management policy under your organization's control framework reduces the work, because SC-12 assessors look for defined requirements that the system actually follows. Ask any partner to break its quote into inventory, design, documentation, configuration evidence and assessor support, so you can see what drives each part.

Can our own team document SC-12 for Besu without a partner?

Yes, if your team has people who understand both the Besu key files and the key management requirements in your assessment scope. SC-12 is assessed through examine, interview and test methods, so the documentation must match what engineers see in configuration files, HSM settings and audit records. Teams usually struggle with three things: tracing every key to an owner and storage location, showing that the documented procedures are the ones operators follow, and keeping evidence current after upgrades or key rotations. Your team should first confirm which control baseline applies to the system and what the assessor expects as evidence. An outside firm can add capacity for the write-up and the configuration review, but accountability for the control stays with your organization.

What does the client need to provide for an SC-12 engagement?

The client needs to supply access and decisions that only the organization can give. Typically this includes:

System owners who confirm scope, data flows and which keys are in use
HSM administrators who explain how key objects are created, backed up and retired
Platform or infrastructure staff who provide node configuration, deployment records and access to change logs
A named assessor or compliance contact who states which evidence format and sampling approach they expect

Without these people available for review sessions, documentation stalls because key ownership and storage locations cannot be confirmed. Agree on who signs off each document before the work starts.

How long does SC-12 key management documentation take?

Duration depends on scope and on whether an HSM is already in place. A network that uses a supported HSM with documented procedures moves faster than one that stores node key files on disk and needs a new key protection design. Other drivers include the number of validator and RPC nodes, the number of organizations sharing the network, the state of existing policies, and how quickly the client can schedule reviews with system owners and HSM staff. Any timeline should come from a written scope that lists deliverables and dependencies. Ask for milestones tied to client inputs, because delays in access or approvals usually matter more than the writing itself.

Is an HSM plugin required to meet SC-12 for Besu?

No single product is required by the control, but SC-12 requires that key management follow defined requirements, so your design must explain how each key is protected. Besu's documentation states that the local node private key file is not encrypted and that deployments needing hardware-backed key storage can use a security module plugin, such as the Besu HSM plugin, through the --security-module option. Where no HSM is used, the documentation must justify file-based protection with compensating controls such as restricted file permissions, access logging and separated administration. Confirm with your assessor which protection level they expect for your impact level, and confirm the plugin's compatibility with your Besu version before choosing it.

Can DeployOpen certify that our Besu network meets SC-12?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent assessors and authorizing bodies make the determination against the applicable baseline. DeployOpen's role is to document the key inventory, configure and verify the key protection design, and assemble the evidence an assessor will examine and test. Ask any provider to state in writing which deliverables are documentation and configuration work and which decisions remain with your assessor and authorizing official.

How DeployOpen fits SC-12 work into a scoped engagement

DeployOpen scopes the Besu deployment first, then documents how each key class is generated, stored, rotated and retired, and assembles the evidence set in writing. The scope names the in-scope nodes, validators and signing keys, the planned use of a security module plugin such as the Besu HSM plugin through the --security-module option, and the boundary between the Besu node and any external key custody. Deliverables, timelines and acceptance criteria are agreed before work starts, so the client knows which artifacts exist at the end and who signs off on each one. Where a control is partly owned by another team, such as the HSM operator or the identity group, the written scope assigns that responsibility explicitly so that no SC-12 statement depends on an unnamed owner.

Two boundaries matter throughout. DeployOpen prepares the system description, configuration records, key-handling procedures and examinable evidence that an assessor would look for under SP 800-53A, but it does not issue assessment conclusions, attestations or certifications. Those remain the responsibility of the independent assessor or the authorizing body the client works with, and the client should confirm early which body will review the evidence and in what format. Before signing, ask for the written list of deliverables, the evidence index mapped to SC-12 determination statements, the assumptions about the client's environment and the process for changes after go-live. Those four items make the scope testable and show what will still need the client's own staff to maintain.

How DeployOpen scopes, delivers and supports SC-12 key management

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so Besu key handling is built and recorded where it runs. We scope the key inventory, build the controls, and hand over the records an SC-12 assessor would examine, with support available afterwards as a retainer.

How we scope

Inventory every node, validator and signing key, its owner, location and storage method before design starts.
Agree in writing which Besu node types, RPC endpoints and HSM or security module options are in scope.
Confirm which assessment baseline and system boundary the client needs, with the client's assessor or compliance lead.

How we build

Configure node key files, the --security-module option and any HSM plugin in the client's environment, then test signing end to end.
Set RPC authentication, file permissions and access to key material according to the documented design.
Test key generation, rotation and restoration in a segregated environment and record the results.

How we hand over

Deliver a key management standard covering generation, storage, custody, rotation, backup and destruction for each key class.
Provide configuration records, access lists and test evidence mapped to the examine objects used in SC-12 assessments.
Walk the client's team and assessors through the evidence set and record open items agreed in the written scope.

How we support

Keep key records current when Besu releases change configuration, plugin or key handling behavior.
Review key inventories and access records on a schedule agreed in the retainer.
Support assessor questions and retest key procedures after changes, with the client's auditors making their own determinations.

Hyperledger Besu key management against NIST SP 800-53 SC-12