Why permissioned blockchain infrastructure for manufacturing needs a different build
A permissioned network is justified when several legal entities need a shared, tamper-evident record that none of them controls alone, such as a manufacturer and its tier-one and tier-two suppliers sharing lot traceability and purchase confirmations without giving each other access to their ERP or plant systems. Hyperledger Fabric usually fits multi-party supply chains because its channels keep data visible only to the members a channel names, and its membership service providers let each organization run its own identities. Besu is the better fit when the team already runs Ethereum tooling and wants EVM smart contracts on a private network with proof-of-authority consensus, provided it can handle the Besu release cadence and the removal of features such as Tessera privacy and onchain permissioning. Confirm the choice against your partners' existing skills before you commit.
Manufacturing is a critical sector under NIS2 Annex II, covering computer, electronic, electrical, machinery, motor vehicle and other transport equipment divisions, and medical devices. For in-scope manufacturers, the ledger is rarely the exposed part of the stack. The real attack surface is the operational technology beneath it: PLCs, SCADA and DCS systems, MES connections and the engineering workstations that reach them. ISA/IEC 62443 and NIST SP 800-82 Rev. 3 treat these systems as their own security domain, with performance, reliability and safety requirements that a ledger deployment does not carry. Keep node hosting, ERP connectors and plant data gateways in separate network zones with narrow, logged paths between them.
Before any supplier is onboarded, decide which party operates each node, who holds the enrollment and signing keys, and who approves changes to the permissions configuration. Ask your implementation partner to show how a new supplier is admitted, how a suspended account is removed from a channel or permissions file, and how an upgrade is rolled back if a Besu database has been auto-upgraded. Those answers determine your incident reporting path, since NIS2 sets a 24-hour early warning and a 72-hour notification for significant incidents. Confirm with your legal team which entities count as in scope for your own obligations and those of your suppliers.
Which manufacturing rules shape the network build
This table maps each rule that applies to a manufacturer running a permissioned ledger to what it means for where nodes sit, how plants connect, and how suppliers are onboarded. Read each row as a design constraint to settle before the network topology is fixed, and confirm applicability with counsel and your own regulator. The main takeaway is that the ledger is rarely the hardest part; the plant network boundary and incident reporting duties usually decide the design.
| Rule or standard | What it asks for | Effect on node placement, plant connectivity and supplier onboarding |
|---|---|---|
| NIS2 Annex II (manufacturing) | Lists manufacturing as a critical sector, covering medical and in vitro diagnostic devices and NACE Rev. 2 divisions 26 to 30. | Confirm whether your entity falls in these divisions. If it does, a ledger node that supports operations becomes part of the in-scope estate, so node hosting and access must be documented. |
| NIS2 incident reporting (Article 23(4)) | Significant incidents require an early warning within 24 hours, a notification within 72 hours and a final report within one month. | Each member's node operator must be able to detect and escalate a ledger or connectivity incident within these windows. Define who reports for each node in the onboarding agreement. |
| NIS2 fines (Article 34(5)) | Important entities face fines of at least EUR 7 million or 1.4% of worldwide turnover. | Fine exposure makes it worth confirming, for each supplier, whether it is in scope and who carries reporting duties for a shared ledger node it hosts. |
| ISA/IEC 62443 for asset owners (ANSI/ISA-62443-2-1-2024, 3-2-2020, 3-3-2013) | Security program requirements, risk assessment for system design and system security levels for industrial automation and control systems. | Plant-facing integrations should sit in a separate zone from the ledger node. Place nodes outside the control network and document the conduits between the two. |
| ISA/IEC 62443 for component suppliers (ANSI/ISA-62443-4-1-2018, 4-2-2018) | Secure development lifecycle and technical security requirements addressed to product suppliers rather than asset owners. | When you buy a plant component or gateway that talks to the ledger, ask the supplier for evidence against these requirements during supplier onboarding. |
| NIST SP 800-82 Rev. 3 (OT security, September 2023) | Guidance for operational technology, including PLCs, SCADA and DCS, with performance, reliability and safety requirements. | Ledger nodes must not degrade OT performance or availability. Confirm node resource limits and failover behavior with plant engineering before connecting any OT data source. |
| Cyber Resilience Act Article 14 (from 11 September 2026) | Manufacturers must report actively exploited vulnerabilities and severe incidents in products with digital elements. The wider CRA applies from 11 December 2027. | If you build or customize a product that connects to the ledger, track vulnerability reporting duties in your release process. Ask Fabric or Besu suppliers how they notify you of exploited flaws. |
| Machinery Regulation Annex III, 1.1.9 (from 14 January 2027) | Machinery must be protected so that connecting another device or remote device does not lead to a hazardous situation. | Any plant integration that lets a ledger gateway or external device connect to machinery needs a safety review. Keep the ledger off the machine control path. |
| CMMC (32 CFR Part 170), defense suppliers only | Level 1 uses 15 FAR 52.204-21 requirements, Level 2 uses 110 NIST SP 800-171 Rev. 2 requirements for CUI, and Level 3 adds 24 selected NIST SP 800-172 requirements. | Applies only if you are a defense contractor. The Department of War has suspended CMMC Phase II requirements as of 13 July 2026, so confirm current contract clauses before scoping nodes that handle CUI. |
Who operates which node: OEM, suppliers and logistics partners
The anchor manufacturer usually sponsors the network and often takes on the ordering and governance roles, because it sets the channel design and the membership rules. In a Hyperledger Fabric network, that can mean hosting some of the ordering nodes and the root of the Fabric CA hierarchy, while also running its own peers for the channels it joins. Whether the anchor should host the ordering service at all is a governance question that the consortium should settle in writing before build starts.
- Ordering nodes: Fabric documentation recommends Raft ordering, which keeps working while a majority of nodes are available. A five node Raft cluster tolerates the loss of two nodes, so the anchor should not hold more than a minority of orderers alone.
- Peers and CA: The anchor runs its own peers and typically the root or intermediate CA that issues member identities, which needs HSM-backed key storage and documented revocation steps.
- Keys and data: Keep the anchor's signing keys, MSP material and ledger backups in its own infrastructure, with backups taken before any binary upgrade.
- Channel scope: Channel membership and collection policies should limit each supplier to the channels where it trades. Confirm whether the anchor can see supplier-private data at all.
- Operations: The anchor usually owns the upgrade calendar and the monitoring view across members.
Confirm with the partner the number of orderers and peers the anchor will host, and who holds the majority in a failure.
Tier-one suppliers deliver directly into the manufacturer's production and usually have the most system integration with it. They typically run one or two peers for the channels that carry their purchase orders, shipment notices and quality records. They may also need to connect their ERP or manufacturing execution system to those peers, which makes their node a data integration point and not only a ledger participant.
- Peer nodes: Host the peers for the channels that include their orders, certificates and inspection results, and keep them patched on the Fabric release line the network uses.
- Identity: Enroll their own identities through the network CA, with multi-factor authentication for every person who administers a node.
- Integration: Their ERP connector should call the Fabric Gateway client API, which works with both v2.5 and v3.0, so application code can move on its own schedule.
- Private data: Keep unit prices, capacity and cost data in private data collections shared only with the parties named in the policy.
- Access limits: Account permissioning on Besu, or channel membership in Fabric, should block them from channels they have not joined.
Ask the partner which systems will write to the ledger, how credentials for those connectors are stored and rotated, and how the supplier's node is removed from a channel when a contract ends.
Tier-two suppliers often have smaller IT teams and less integration with the anchor's systems. Hosting a full peer may be disproportionate for them, so the network design should offer a lighter path, such as a peer hosted by a service partner or by a tier-one supplier on their behalf, or a client application that submits transactions through an operator's gateway. Whichever path is used, the network must still record which organization is accountable for each identity.
- Node hosting: Decide whether the supplier runs its own peer, uses a hosted peer under a written service agreement, or only uses an application front end. Each choice changes who holds the keys.
- Keys: Any signing key the supplier holds should be stored in a managed store or HSM where possible, and the supplier should be able to revoke its own identity quickly.
- Onboarding: Membership begins with a certificate authority enrollment and a channel policy change, both of which should be documented for the supplier's auditors.
- Data scope: Limit the supplier's view to its own purchase orders and shipments, using private data or channel design rather than trust in the front end.
- Support: Smaller suppliers depend more on the network's runbooks and the operator's support hours.
Confirm the minimum set of duties a supplier must perform itself and what the partner will operate on its behalf.
Logistics providers and certification bodies usually write events rather than manage the network. A carrier may record pickup and delivery milestones, while a test laboratory or certification body may record test results or conformity certificates. These parties need the least administrative access and the most narrowly scoped identities, because their role is to attest to events, not to decide how the network runs.
- Node hosting: Depending on volume and policy, they may host a peer for their own events or submit through a client application. Confirm whether an independent body is allowed to host any node.
- Identity scope: Issue them identities that can endorse only the event types they are authorized to write, and avoid shared service accounts.
- Audit trail: Certification and test records may fall under customer audit or regulatory retention. Confirm the retention period with the auditing parties, since no period is set here.
- Connectivity: Carriers often work from unreliable links and mobile devices, so plan for retries and offline submission at the application layer.
- Separation: Keep their node and identity administration separate from the manufacturer's so that one party cannot change another's permissions.
Ask the partner how an accredited third party would be onboarded, how its identity is limited to its attestations, and how it is removed when accreditation lapses.
Which platform fits a manufacturing supply chain network
Supply chain networks usually fail on membership, identity and integration long before they fail on ledger software. The cards below compare the Fabric and Besu options against those needs, and each choice depends on the ERP and plant systems your network must connect to and on the skills your team can keep running.
Hyperledger Fabric v3.1.5 for private channels
Fabric fits a supplier network where each trading pair needs its own channel and private data collections, so one supplier's pricing or quality data is not visible to every member. Multi-org endorsement lets you require specific members to approve a transaction, such as a plant confirming a shipment. Fabric v3.1.5 is the current 3.x release, but it does not decide membership or data governance for you. Check whether your partners will accept a 3.x upgrade path and who signs off on channel policies.
Fabric v2.5 LTS for production stability
Fabric v2.5 is the long-term support line that the Fabric documentation names for production users, and it receives patch releases in parallel with 3.x. For a manufacturing network with many suppliers on uneven upgrade schedules, this is often the safer starting point. It does not include the v3.0 BFT ordering option, so plan the eventual move to 3.x, including migrating any Kafka ordering to Raft and moving channels to the v2.x lifecycle. Confirm with partners which line they will run.
Besu with QBFT or IBFT 2.0
Besu fits a consortium that already builds on Ethereum tooling and wants proof-of-authority consensus, either QBFT or IBFT 2.0, for a private network. It suits teams whose developers know Solidity and EVM tools, and whose supplier onboarding is handled through node permissioning. Besu does not provide Fabric-style private channels, so private data between suppliers needs a separate design. Confirm your consensus choice, the JDK version your nodes need, and how permissioning files are managed across members.
Fabric CA for member identity
Fabric CA registers identities, issues enrollment certificates, handles renewal and revocation, and generates certificate revocation lists, or connects to LDAP as the user registry. In a supplier network this is how a new supplier gets a certificate tied to its organization, and how a departing supplier is cut off. The open question is who runs the root and intermediate CAs, and whether keys are held in an HSM. Ask your partner to document enrollment, revocation and CRL distribution for every member.
Avoid legacy Besu features
Several Besu features have been removed, so older designs will not carry forward. Tessera privacy and onchain permissioning were removed in 25.6.0, and Clique consensus was removed in 26.4.0, so pure Clique networks can no longer start or produce blocks. Any Besu design that depends on these features needs a migration plan before it is built. Ask partners to confirm which features their proposed design uses and to show the upgrade path from the current release.
Integration points between the ledger, ERP and plant systems
A manufacturing ledger touches three zones: the ERP that owns orders and inventory, the plant systems that produce the data, and the supplier nodes that join the network. The cards below cover the connections between them, the operational tooling around them, and the boundaries that keep plant control networks out of reach of the ledger.
ERP to gateway integration
The ERP should talk to the ledger through a client application that calls the Fabric Gateway, not through peer or orderer endpoints directly. The Fabric upgrade docs state that the Gateway client API is compatible with both v2.5 and v3.0, so the integration can be upgraded separately from the network. Check who owns the service account, how purchase order and shipment events are signed, and how failed submissions are retried without duplicating records.
MES and historian data kept off-chain
Machine telemetry, historian time series and detailed MES records are high volume and rarely need to be shared with every partner. Keep them in the plant's own systems and write only the events partners must verify, such as a batch identifier, a hash of a quality certificate or a shipment milestone. Confirm which fields leave the plant, who can query them, and how a hash can be traced back to the source record during a dispute.
Supplier enrollment through certificate authorities
Each supplier joins as a member with identities issued by a Fabric CA, which registers users, issues enrollment certificates and handles renewal and revocation. Define who approves a new supplier, how a certificate is revoked when a supplier leaves or is compromised, and whether the CA uses LDAP for user registry. Confirm the enrollment workflow with your partner before the first supplier is onboarded, because revocation lists must reach every peer.
Operations service for monitoring
The Fabric operations service exposes node health and metrics that a monitoring stack can collect across each member's peers and orderers. Agree on who receives alerts for a stalled ordering service, a peer falling behind, or a certificate nearing expiry. Ask whether each member sees only its own node data or a shared view, because the answer shapes the governance terms of the network.
HSM-backed signing keys
Peer, orderer and client signing keys are the most valuable credentials in the network, and a plant integration service account can sign transactions that move goods between members. Fabric supports storing keys in a hardware security module, so the private key never leaves the device. Confirm which keys sit in the HSM, how key ceremonies are documented, and who can authorize a signature from the ERP side.
Plant DMZ between ledger and control networks
Plant control networks, including PLCs, SCADA and DCS, should not be reachable from the ledger or its nodes. The ISA/IEC 62443 series and NIST SP 800-82 Rev. 3 both place these systems in zones with defined conduits, and the ledger sits outside them. Route plant data through a DMZ with one-way or tightly filtered flows, and ask your partner to document each conduit and the rule that governs it.
Rollout from one supplier pilot to a governed multi-party network
The rollout starts with one manufacturer and one supplier, then adds members only after identity, OT scope, integrations and upgrade rules have been tested. Each phase closes with a written output that the next phase depends on.
Scope members, data and process boundaries
The manufacturer and its pilot supplier agree which documents, quality records and shipment events go on the ledger, which stay in each party's systems, and who must sign off on membership. DeployOpen facilitates the workshops, and the buyer's legal and procurement teams own the governance decisions. The step closes with a signed scope note listing members, data classes, and the systems that will and will not connect to the network.
Inventory OT assets and set security zones
Plant engineers and security staff list the systems that would touch the integration, such as MES, historians, PLC-adjacent gateways and ERP interfaces, and classify them against the ISA/IEC 62443 series, starting with the asset owner program requirements in ANSI/ISA-62443-2-1-2024 and the zone and conduit risk assessment in ANSI/ISA-62443-3-2-2020. Ledger nodes stay outside the control network, with only defined data flows crossing the boundary. The output is an asset register, a zone and conduit diagram, and a risk assessment that the plant owner approves.
Design the certificate authority and identity model
The team decides how many Fabric CA or identity hierarchies the network needs, who may register and revoke identities, how enrollment certificates are renewed, and where CA keys are stored, including whether an HSM is used. For Besu networks, the team defines node keys and the node and account permissioning files. The output is a written identity design, a documented revocation procedure, and a test that a revoked supplier identity can no longer submit transactions.
Run a two-party pilot on a non-production network
The manufacturer and one supplier run a pilot with the agreed data classes, using separate nodes for each party and a test ordering service. The pilot tests enrollment, transaction endorsement or validation, error handling and the reconciliation of records against each party's ERP. Success is measured against the scope note, and the pilot report records every defect and the decision to fix or accept it before expansion.
Integrate ERP, gateways and plant systems
Integration teams connect the ledger client application or gateway to the ERP and the plant-side systems through the zones defined earlier, with only the required data flows permitted. Interface logic, retry behavior and reconciliation jobs are tested with production-like volumes and documented in runbooks. The output is a tested integration, an interface register, and evidence that unauthorized network paths are blocked.
Write the supplier onboarding runbook
The team writes the steps a new supplier follows to join: due diligence on the supplier's node hosting, identity enrollment, permission changes, test transactions, and cutover. Each step names the party who approves it, the evidence retained, and the rollback path. The runbook is validated by onboarding a second supplier in a controlled test before it is used for live members. The output is an approved runbook with a signed record for every onboarding.
Set monitoring and the upgrade policy
Operators configure node health, metrics and alerting for every member, with clear ownership of each alert. The upgrade policy follows the Fabric four-step process: back up the ledger and MSPs, upgrade orderers in a rolling fashion, upgrade peers in a rolling fashion, then update channel capability levels. For Besu, a backup must be taken before each upgrade because the Bonsai database cannot be opened by older versions. The output is a monitoring matrix, a version policy, and a tested rollback that the members have signed off.
Evidence regulators and suppliers will ask for
This table maps each piece of evidence that assessors, NIS2 authorities and supply chain partners commonly request to the component that produces it. Read it as a checklist for the operating model: if a component is not generating a record, the gap will surface during a supplier audit or an incident review.
| Evidence | Produced by | What it shows |
|---|---|---|
| Asset inventory | Network inventory maintained by the node operator, covering peers, orderers, Besu validators, HSMs and connected ERP and plant gateways | Which parties run which nodes and where each node sits in the plant and cloud estate |
| Risk assessment records | Security risk assessment for system design, aligned with ISA/IEC 62443 series practice, kept per zone and conduit | How the network was segmented from plant control systems and which threats were accepted or mitigated |
| Enrollment and revocation logs | Fabric CA issuance, renewal and revocation records, plus generated certificate revocation lists | Which member identities were enrolled, when, and when a supplier's access was removed |
| Permissioning configurations | Besu node permissions and account permissions files, with change history in version control | Which nodes may connect to the network and which accounts may submit transactions or be suspended |
| Change records for chaincode and binaries | Change tickets, approved chaincode lifecycle commits, and rolling upgrade logs for orderers and peers, or Besu release upgrade records | Who approved each contract or binary change, what was tested, and in what order nodes were updated |
| Backup and restore test records | Ledger and MSP backups taken before each upgrade, plus documented restore exercises by the node operator | That a backup exists and that it restores, which matters because older Besu versions cannot open an upgraded database |
| Incident reporting timelines | Incident runbook and log of early warning, notification and final report dates for NIS2, plus CRA Article 14 reporting for actively exploited vulnerabilities | Whether the 24-hour, 72-hour and one-month NIS2 clocks and the CRA Article 14 obligations were met for each event |
| Vulnerability assessment records | Scan and penetration test reports for nodes, gateways and integration endpoints, and patch status against published releases | That assessments run on schedule and that known issues in node software were tracked to closure |
What to ask an implementation partner before signing
Start with node count and ownership, because it sets the cost, the failure modes and the accountability model for every supplier. Ask how many peer, orderer or validator nodes the partner recommends per member, and who hosts each one: the supplier, the buyer, or the partner under a written operating agreement. For Fabric, ask how the ordering service is laid out, since the Fabric documentation recommends Raft and a five node Raft cluster tolerates the loss of two nodes. Ask whether the partner will hold any node keys or administrative credentials for a supplier, and what they will refuse to operate, such as a supplier's peer that sits inside another member's OT zone. Get the answers in writing before the network design is frozen.
Next, press on the boundary between the ledger and plant systems. Ask how the partner separates the ledger network from OT zones, including whether ERP or manufacturing execution system connectors run in a demilitarized zone with one-way or narrowly scoped flows, and which ports and API paths cross that boundary. Ask how the partner maps the design to the ISA/IEC 62443 series, including the security risk assessment in ANSI/ISA-62443-3-2-2020 and the zone and conduit model. For keys, ask where Fabric MSP and enrollment keys and Besu node keys are stored, whether an HSM is used (the Fabric HSM documentation covers this), and how Fabric CA registration, renewal and revocation are run and tested. Confirm who approves permissioning changes: Besu node and account permissioning files, and Fabric channel membership and chaincode definitions, should each have a named approver from every affected member.
Finally, ask how the partner keeps the network current. For Fabric, ask how they follow the 2.5 LTS line and the 3.x line, how they test the four-step upgrade in the Fabric upgrade guide, and how chaincode upgrades are approved across members. For Besu, ask how they absorb roughly monthly releases, which features were removed in recent versions (such as Clique consensus in 26.4.0), and whether they back up the Bonsai database before every upgrade, since older versions cannot open an upgraded database. Ask for their monitoring design across members, including who sees the Fabric operations service and Besu metrics, and who is paged. Request a written list of responsibilities separating the partner, each supplier and the buyer.
How long, what it costs and what the manufacturer must provide
What drives the cost of a permissioned ledger for a manufacturer?
Cost follows the number of nodes, the key and certificate design, and the integration work, because Hyperledger Fabric and Besu carry no license fees. Each member that hosts its own peer or validator node pays for its compute, storage, network, backups and monitoring. Hardware security modules, custom node images, Fabric CA operations, smart contract (chaincode) development, ERP and plant system integration, and the governance work of a multi-party network are the larger items. Recurring costs include hosting, certificate renewal, monitoring, patching and upgrades. Ask for a quote that lists each node, each integration and each recurring service separately, with the assumptions behind them.
Can our internal team run a supply chain ledger network alone?
Some manufacturers can, but the work is wider than the ledger itself. Operating a node means managing identities and enrollment certificates, key storage, ordering or validator availability, upgrades and backups across organizations. Fabric documentation recommends the Raft ordering service, and Besu documentation covers node and account permissioning, so each member needs people who understand those controls. Ask a partner which parts they would hand over, which they would run as a retainer, and which skills your staff must already have before go-live.
What do OT and ERP staff need to contribute to the project?
OT and ERP staff define which events, orders, lot records and quality data cross the network and which systems are authoritative for each. Plant engineers confirm network zones, the existing ISA/IEC 62443 zone and conduit model, and any constraints on connecting controllers or historians. ERP owners confirm master data, identifiers, and how records are posted back. Expect them to review interface designs, test data flows in a non-production environment and sign off on change windows that do not disturb production. Ask the partner for a written list of these inputs before scope is agreed.
How does onboarding each supplier change the effort?
Each new supplier adds an organization to the membership, its own identity and certificate chain, a node or a defined way to participate, network connectivity rules, and testing of the data it submits. Effort rises with the number of members, the variety of their systems and how many data types each one shares. The governance decisions on membership, channel or privacy design, and the process for suspending an account also grow with membership. Ask for a per-supplier onboarding procedure, the artifacts each supplier must provide, and whether onboarding is priced per member or in bundles.
Does NIS2 apply to our suppliers in manufacturing?
It depends on each supplier's size, sector and location, so the answer is not automatic. NIS2 Annex II lists manufacturing as a critical sector, covering medical devices, electronics, electrical equipment, machinery and motor vehicles and other transport equipment under NACE Rev. 2 divisions 26 to 30. In-scope entities must report significant incidents with an early warning within 24 hours, a notification within 72 hours and a final report within one month. Confirm each supplier's status with national authorities or legal counsel, and agree in the network rules which incident information each member shares.
How are fixed-scope blockchain engagements quoted?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. A useful quote separates one-time work such as design, build, integration and testing from recurring work such as hosting, support and upgrades. It should state which members are responsible for their own nodes and keys, which assumptions about ERP and plant systems are included, and what changes would reopen the price. Ask for a sample scope document before you compare proposals.
How long does a manufacturing ledger rollout take?
The duration depends on the number of members, the number of integrations and how much governance agreement is needed before technical work starts. No timeline figure is given here, because the project scope determines it. Phases usually cover network design and membership agreement, identity and key setup, node build, ERP and plant integration, testing with real supplier data flows and a controlled go-live. Ask the partner for a phased plan with entry and exit criteria for each phase, and identify which steps depend on suppliers and which on your own teams.
How DeployOpen scopes and operates this network
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted Hyperledger Fabric or Besu nodes inside the infrastructure the network members own or contract, whether that is their cloud accounts, data centers or plant-adjacent networks. For a supply chain network, the first scoping decision is which organization runs which node: each supplier, the manufacturer and any logistics or certification partner may host its own peer, and the ordering service may be shared or split across members. DeployOpen documents that allocation in writing, along with who holds the Fabric CA administrator role, who controls the MSP material and who approves changes to the permissions configuration. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and ongoing upgrades, support and continuous testing are available as separate retainers.
Security testing of the network is scoped as its own deliverable. It covers the member-facing APIs and gateways, the certificate authority enrollment flow, the node hosts and the integration points with ERP and plant systems. Before go-live, confirm with DeployOpen which of these are in the fixed scope and which will repeat under a retainer after each Fabric or Besu upgrade. Ask for the test plan, the findings handling process and the retest criteria in the written agreement. DeployOpen prepares evidence for your compliance and customer audits, such as configuration baselines, access records, backup and restore results, change logs and test reports, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. DeployOpen is a Chainscore Labs company (chainscorelabs.com). Ask any partner to name the evidence it will produce for each control your customers or regulators care about, and to state in writing which parts remain your responsibility as a network member.
