Hyperledger Fabric vs Besu privacy: which keeps participant data private
If you are a consortium lead who must keep some data visible only to certain members, Fabric isolates data with channels and private data collections, while Besu no longer offers a native private transaction feature. Besu removed Tessera private transactions in 25.6.0 and removed the EEA and PRIV privacy RPC API groups in 25.7.0, so on Besu your confidentiality now rests on permissioning and on running separate networks for groups that must not see each other's activity. Fabric's model is built around this problem: a channel is a separate ledger shared by a defined set of members, and private data collections keep specific values off the shared channel ledger while still letting authorized organizations verify them through hashes.
The answer depends on two things you must define before you choose. The first is isolation granularity: do you need separation at the level of a group of organizations (channels suit this well), or at the level of a single value within a shared transaction (private data collections address this, but you must decide which fields belong in them)? The second is who must not see what, including peers, orderers, administrators and node operators. Besu's node permissioning restricts which nodes can connect, and its account permissioning governs who may transact, but neither hides transaction content from a node that is allowed to join the network. Confirm with your own architecture team whether a per-group network split is acceptable, because on Besu that split is an operational design decision you carry, not a platform feature.
Before committing, run a concrete check: map every data flow to the set of participants allowed to read it, then test whether the chosen platform can enforce that map without manual workarounds. The Besu permissioning documentation explains the local permissioning files you would configure, and the Besu release notes on GitHub show the privacy removals you must account for at your target version. The broader platform comparison sits in the sibling pages linked from this one.
How each platform isolates participant data
This table sets Fabric's channels and private data collections against Besu's permissioning and separate-network model, row by row on the isolation unit, where private payloads sit and what each platform removed. Read it as a map of where you must configure privacy yourself, since Besu no longer offers a built-in private transaction layer.
| Aspect | Hyperledger Fabric | Hyperledger Besu |
|---|---|---|
| Primary isolation unit | Channels, each with its own ledger, and private data collections inside a channel for narrower sharing | Separate private networks, with node and account permissioning limiting who can connect and transact |
| Where private payloads live | Private data is held by authorized peers in private data collections, while the channel ledger records only agreed references and hashes | Tessera privacy was removed in Besu 25.6.0, so private payload handling must be designed outside Besu or the network kept fully private |
| Participant access control | Membership is governed by the channel and MSP configuration, with Fabric CA issuing enrollment certificates and handling revocation | Local permissioning files on each node restrict connections to known participants and control which accounts may act |
| Onchain permissioning | Not applicable, as access is set through channel configuration rather than smart contracts | Onchain permissioning was removed in Besu 25.6.0, so permission rules must be managed in local configuration |
| Removed RPC privacy surface | No equivalent removal recorded in the supplied facts for Fabric privacy | The EEA and PRIV RPC API groups were removed in Besu 25.7.0, so applications relying on them need redesign |
| Operational effect | Architects must plan channel membership and collection policies before go-live, and changes are made through channel configuration updates | Operators must keep permissions files consistent across nodes and confirm each privacy approach against the current Besu documentation |
| Where to confirm | Fabric documentation on channels and private data, reviewed against your Fabric line (v2.5 or v3.1) | Besu private network permissioning docs and the Besu 26.x release notes for your target version |
How Fabric channels and private data collections keep data private
Fabric keeps data private by limiting who can see it at two levels: channels, which partition a network so that only member organizations of a channel see its transactions and ledger, and private data collections, which keep specific data off the shared channel ledger and deliver it only to the peers of organizations named in the collection. Smart contracts (chaincode) are written in general-purpose languages such as Go, Java and Node.js, so the team that builds privacy-sensitive logic can usually staff it from its existing developer pool. Fabric has no native cryptocurrency, which means a privacy design does not have to account for a token layer.
Who can join and transact is decided by identity. Fabric CA issues enrollment certificates, handles renewal and revocation, and generates certificate revocation lists (CRLs), so a participant whose access ends can be cut off without rebuilding the network. Fabric CA can register identities itself or use LDAP as the user registry, which matters if your organization already manages staff identities in a directory. Confirm with your security team whether certificate lifetimes, revocation handling and the hardware security module (HSM) option described in the Fabric documentation match your key management policy before you pick a Fabric line.
The exact rules for sharing private data, including how collection policies, endorsement and purge behavior are configured, differ between Fabric lines and can change between releases. Read the private data documentation for the line you plan to run (v2.5 or v3.x) and test a collection with your own organizations before you commit to a data model. Treat that test as a gate in the design, because a collection that exposes more than your legal team expects is much harder to correct after production data has been written.
What changes the privacy result in practice
Privacy in these two platforms is not a single feature you switch on. The factors below decide whether Fabric's channels and private data collections, or Besu's permissioning and separate networks, fit your data model. Check each one against your own requirements before you compare the platforms on features.
Required isolation granularity
Fabric isolates data at the channel level, and private data collections narrow visibility further inside a channel. Besu has no equivalent of channels, so isolation usually means running separate networks with their own nodes and membership. If your rules call for many small, overlapping groups of participants sharing some assets, count how many separate networks you would have to operate under the Besu model before you commit. Ask each vendor or your design partner to diagram the isolation boundaries for one real use case.
Hiding data from same-network members
Some consortia need a participant on the same network to be unable to read a transaction, not just unable to see the full ledger. Fabric private data collections store sensitive values only on authorized peers while the hash reaches the channel. Besu's Tessera private transactions have been removed, so Besu teams must design their own confidentiality layer or keep sensitive data off-chain. Confirm this requirement early, because it is the most common reason a Besu design needs rework.
Existing Tessera-based workloads
If your current Besu network relies on Tessera privacy, the removal is a migration decision, not a configuration change. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. Inventory every client application that calls those APIs and every contract that depends on private transactions. Ask whether the replacement design will be a Fabric rebuild, a Besu redesign or a separate privacy service.
Operator count and identity systems
Besu node permissioning and account permissioning are configured through local files on each node, which suits a small, stable operator group. Fabric uses membership service providers and Fabric CA, which can register identities or use LDAP as the user registry. The more operators and identity sources you have, the more you must agree on who can onboard, suspend and revoke participants. List every organization, its identity system and who signs off on changes before you select a model.
Auditability and evidence requirements
Regulators and internal audit often ask who saw which record and when. Fabric's channel and collection membership is explicit in the network configuration, and the ledger is the record of every endorsed transaction. Besu's audit trail depends on how you configure logging, metrics and JSON-RPC authentication around each node. Specify the evidence you must produce, such as access logs, membership history or key rotation records, and test that the chosen platform can produce it without custom work.
Team language and operations skills
Fabric chaincode is written in Go, Java or Node.js, while Besu runs on the JVM, and current Besu releases require JDK 25 to build and run. A team strong in Java can operate Besu nodes and extend its plugins with less retraining, while a team strong in Go or Node.js will find Fabric chaincode more familiar. Also weigh the upgrade path: Fabric 3.x requires moving Kafka ordering to Raft and all channels to the v2.x lifecycle first. Match the skills you already have to the platform you would run for years.
How to confirm privacy requirements in your own environment
This sequence turns a privacy requirement into test evidence: you define who may see which data, prove each candidate design enforces that rule on a test network, and record the results before any production upgrade or audit discussion.
Map who may see which data
Start with a written matrix that lists each data class, each participant organization, and the roles allowed to read, write or only verify it. Include regulators, auditors and your own operators, since they often hold access that is easy to forget. Assign the matrix an owner in compliance or data governance and get sign-off from business and security leads. The step is done when every data class has a named set of permitted viewers and a reason for each one.
Build a test network for each design
Stand up a small test network for each candidate: one using Fabric channels and private data collections, and one using Besu permissioned private network controls with the separate-network pattern you would use instead. Use the same participant names and data classes from the matrix so results are comparable. Record the exact versions you tested, for example the Fabric line and the Besu release you plan to run. The step is done when both networks start, transact and hold the test data you defined.
Attempt unauthorized reads and connections
From each non-permitted participant identity, try to read the protected data, query the peers or nodes that hold it, and open connections it should not reach. Also test what leaks through metadata, such as transaction existence, sizes or block-level visibility, and whether your design accepts that exposure. Your test team should run these attempts with scripted credentials, not only the happy path. The step is done when every denied attempt is logged with the error or behavior observed, and every unexpected success is open as a defect.
Review node and account permissions files
For Besu, review the local permissioning configuration for node permissions, which restricts connections to known participants, and account permissions, which govern onboarding, suspension and restricted actions. For Fabric, review channel membership, collection policies and the endorsement rules that decide who can access private data. Compare the files in version control against what is running on each node. The step is done when a reviewer can explain every allow rule and the running configuration matches the approved files.
Check identity revocation and renewal paths
Confirm how an identity is suspended or removed in each design. For Fabric, test enrollment, renewal and revocation through the certificate authority and confirm that revoked identities are excluded from the generated revocation list and rejected by peers. For Besu, test how account and node permissions are changed and whether the change takes effect on the running nodes. Time the revocation with your own process, not a vendor claim. The step is done when a revoked test identity is refused on every node you tested and the evidence is saved.
Verify backup and rollback before each upgrade
Before any version change, take and restore-test a backup of the ledger, key material and membership configuration. For Fabric, follow the documented upgrade order: back up the ledger and MSPs, upgrade orderers, upgrade peers, then update channel capability levels. For Besu 26.10.0 and later, note that the Bonsai database upgrades automatically on first start and older versions cannot open it, so a rollback is only possible from a backup taken before the upgrade. The step is done when a restore from that backup has been proven on the test network.
Document evidence for auditors
Assemble the matrix, test scripts, results, configuration snapshots, revocation logs and upgrade records into one evidence pack with dates, versions and named owners. Describe what each control is meant to achieve and what the tests showed, including residual metadata exposure you accepted. Share the pack with your internal audit or compliance team and the external auditor you intend to use. Be clear that this pack supports an assessment; it does not itself produce a certification, which only an independent auditor or certification body can issue. The step is done when the pack is reviewed and its gaps are tracked.
Privacy questions buyers ask before hiring help
Can we build Fabric private data collections in-house without a partner?
Yes, a team with Fabric experience can define private data collections, endorsement policies and access rules in-house, and many do. The work is the design decision, not the configuration syntax: you need to decide which organizations hold which data, who may read it, and what hash on the channel ledger is acceptable to auditors. Teams without prior Fabric operations experience usually find the hardest part is the operational model: certificate authorities, MSP structure, and rolling upgrades. Ask yourself whether your engineers can own that for the life of the network before deciding. DeployOpen can plan, implement and document a design under a fixed-scope written agreement if you prefer to hand off part of the work.
What drives implementation effort for Fabric privacy versus Besu permissioning?
Effort follows the number of data-sharing relationships and how often they change. In Fabric, the drivers are the channel layout, the number of private data collections, endorsement policies, and the identity model that Fabric CA or your existing directory supplies. In Besu, the drivers are the number of nodes, the node and account permissioning files, and how the plugins and separate networks you choose are operated. Besu no longer offers Tessera private transactions, so any privacy layer you build on it is your own design and is owned by your team. Ask any vendor or partner to break its quote into these drivers so you can compare like with like.
What does a migration off Tessera private transactions involve?
A migration off Tessera means moving from a feature Besu has removed to a design you control. Besu 25.6.0 removed the Tessera privacy feature and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups, so any application calling those APIs must change. Typical steps are:
- Inventory every contract, node and application that depends on private transactions.
- Choose the replacement design, such as Fabric channels and private data collections, or a separately operated network.
- Build, test and migrate data, with a backup taken before any upgrade.
Confirm the scope, timeline and data-handling steps in writing before work starts.
What does the work need from our internal team?
Your team needs to own the business rules and the operational runbook, even when an implementation partner builds the network. Expect to supply data classification decisions, a named owner for each participant organization's identities and keys, access to your cloud or data center accounts, and staff who can review designs and sign off on test results. On the engineering side, Fabric work needs people who can operate orderers, peers and Fabric CA, and Besu work needs people who can run JDK 25 based nodes and manage permissioning files. The more of that skill you keep in-house, the more your ongoing support retainer will focus on specific gaps.
How long does a privacy design phase take?
Duration depends on the number of organizations, channels, and data classes in scope, plus how quickly each participant can agree on decisions. No duration for DeployOpen design work is published here, so ask for a timeline as part of the written scope. A good scope names the workshops, the reviews by each participant's security and compliance teams, the test environment, and the acceptance criteria. Ask whether the timeline assumes your participants are available on fixed dates, because that assumption often drives the schedule more than the technology does.
How do Fabric or Besu upgrades affect our privacy controls?
Upgrades can change privacy behavior, so every upgrade needs a regression test of your access and data-sharing rules. For Fabric, the upgrade guide describes four steps: back up the ledger and MSPs, upgrade orderers in a rolling fashion, upgrade peers in a rolling fashion, then update channel capability levels. Fabric v3.0 removed Solo and Kafka ordering and the v1.x legacy chaincode lifecycle, so networks must migrate first. For Besu, the 26.10.0 release notes say the Bonsai database auto-upgrades on first start and older versions cannot open it, so take a backup before upgrading. Confirm each upgrade plan and rollback method in your written scope.
What switching later costs if privacy requirements change
Moving data isolation from Besu-style permissioning to Fabric channels or private data collections is a redesign, not a configuration change. Besu's permissioning controls who can connect (node permissioning) and what accounts can do (account permissioning, configured through a local permissions file on each node). Fabric isolates data by channel, a separate ledger that a defined set of organizations joins, and optionally by private data collections, which keep payloads off the shared ledger for a subset of members. Those are different trust boundaries, so the application data model, the chaincode, the identity setup through the Fabric CA and the network topology all change together. A team that starts on Besu and later needs Fabric privacy should expect to rebuild the isolation layer, not toggle a setting.
The Besu history shows how quickly a privacy foundation can disappear. Besu 25.6.0 (June 4, 2025) removed the Tessera privacy feature and onchain permissioning, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. Any private transaction design built on those features had to be replaced before the upgrade, not after. Before every Besu upgrade, take a backup: the 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older versions cannot open the upgraded database, so rollback depends entirely on that backup. Confirm the restore procedure with the Besu team and test it in a non-production environment.
The cost components that need written confirmation are these. Ask Besu's maintainers and your own platform team which privacy features remain supported in the version you plan to run, and how long each one is expected to stay. Ask Fabric's maintainers and your team which Fabric line you will standardize on, since the Fabric upgrade path requires moving all channels to the v2.x lifecycle and migrating any Kafka ordering to Raft. Then price the parts that recur: data migration, re-accreditation of identities, chaincode rewrites, client application changes and retesting of compliance evidence. The cost drivers are the volume of historical data, the number of applications touching private data and the number of participants who must re-onboard. Obtain these estimates in the written scope before committing to either platform.
How DeployOpen helps evaluate and implement privacy designs
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Besu or Fabric privacy decision, we work from the written scope to the data flows, access controls and evidence your team needs, and we do not issue audit reports or certifications.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which participants must see which data, and which data must stay off shared ledger state.
- The written scope names the Besu permissioning or Fabric channel and collection design under review.
- Quotes follow from that written scope, and DeployOpen publishes no price list.
How we build
- We configure Besu node and account permissioning, or Fabric channels, private data collections and MSP identities.
- We set up Fabric CA enrollment and revocation, or the authentication controls your Besu RPC endpoints need.
- We test that unauthorized participants cannot read private payloads, metadata or endorsement records.
- We document the design decisions and the test evidence your compliance assessor will ask for.
How we hand over
- Handover includes configuration files, runbooks and the privacy design record for your architecture board.
- We document the upgrade path for your chosen line, including backups taken before any database or binary upgrade.
- Your team receives written procedures for onboarding and offboarding participants and rotating identities.
- Deliverables are listed in the written scope so both sides can confirm completion.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover reviews when Besu or Fabric releases change permissioning, identity or privacy behavior.
- Repeat security testing of the privacy controls can be scheduled as the network membership grows.
- Confirm retainer terms, response expectations and service levels in writing with DeployOpen before committing.
