How should security teams evaluate blockchain systems that promise decentralisation but still rely on trusted intermediaries?

Why This Matters for Security Teams

“Decentralised” is often treated as a security outcome, but for practitioners it is only a design claim. The real question is where trust, control, and failure converge when the chain still depends on exchanges, wallet providers, validator operators, bridge services, or custodial key holders. That dependency map matters as much as the ledger itself. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reminds teams to assess accountability, monitoring, and contingency controls around the system, not just the protocol.

This is especially important because blockchain architectures frequently shift trust rather than remove it. A permissionless chain may be resilient at the protocol layer while remaining fragile at the service layer. NHI Management Group’s The State of Non-Human Identity Security shows how commonly hidden dependencies undermine confidence: only 1.5 out of 10 organisations are highly confident in securing NHIs, and 85% lack full visibility into third-party vendors connected via OAuth apps. That same pattern shows up in blockchain stacks when access, signing, and orchestration sit with intermediaries. In practice, many security teams discover the true trust boundary only after an incident forces them to trace who could sign, freeze, upgrade, or reroute assets.

How It Works in Practice

Evaluate the system by separating the blockchain from everything that surrounds it. The chain may provide consensus and immutability, but the operational risk often lives in wallets, key custody, bridges, off-chain APIs, oracle feeds, governance contracts, and the organisations that administer them. A good assessment asks which components can alter outcomes without on-chain consensus, which ones can block transactions or withdrawals, and which ones can be compelled through legal, technical, or insider action.

A practical review should include:

• Identify all trusted intermediaries and rank them by blast radius, not by branding claims.
• Test key custody and signing paths, including who can rotate, pause, or recover access.
• Review upgrade and governance mechanisms for hidden admin privileges or multisig concentration.
• Check whether off-chain dependencies have logging, alerting, and contingency plans equivalent to the risk they carry.
• Map the system against NIST SP 800-53 Rev 5 Security and Privacy Controls to make sure the surrounding controls are not weaker than the protocol assurances.

In blockchain environments, “decentralised” should be treated as a spectrum. A well-governed intermediary can be acceptable if the residual risk is explicit, monitored, and recoverable. That is why teams should also examine attacker learning paths: the DeepSeek breach is a reminder that exposed keys and unmanaged secrets create real-world compromise faster than most response processes can react. These controls tend to break down when custody, governance, and infrastructure are split across multiple vendors with no single party owning end-to-end incident response.

Common Variations and Edge Cases

Tighter decentralisation often increases operational overhead, requiring organisations to balance resilience against performance, cost, and recoverability. That tradeoff becomes sharper in hybrid systems where a public chain is paired with centralised wallets, hosted validators, compliance middleware, or proprietary bridge services. Current guidance suggests treating these cases as shared-trust environments rather than fully decentralised systems.

Edge cases often include permissioned chains, consortium governance, and custodial services. In those designs, the key question is not whether decentralisation exists, but whether the intermediary controls are proportionate to the value being protected. A platform may be technically distributed yet still depend on one administrator to approve upgrades, halt transfers, or restore assets. That is a material trust concentration even if the white paper describes a distributed architecture. The same logic applies to wallets and exchanges: if a service can seize, freeze, or reconstruct access, then it is part of the security perimeter.

Security teams should also be careful with marketing language around “trustless” systems. There is no universal standard for measuring decentralisation yet, so assessments should focus on verifiable control points, recovery paths, and failure modes. Where off-chain service dependencies dominate, the relevant control question is whether those dependencies are contractually bound, continuously monitored, and technically limited in what they can do.

Related resources from NHI Mgmt Group

• How should security teams evaluate blockchain platforms that promise easier decentralised application development?
• How should security teams evaluate authentication as a service for remote work environments?
• How should security teams use identity proofing before granting passwordless access to enterprise systems?
• What do organisations get wrong about decentralisation when evaluating blockchain for security use cases?