Organisations often assume blockchain eliminates intermediaries in every context, but that is only partly true. Even decentralised systems still need governance, software maintenance, key management, identity controls, and rules for dispute handling. In enterprise settings, the middleman may change form rather than disappear, so the real question is which trusted functions are being redistributed and which remain necessary.
Why This Matters for Security Teams
Blockchain does remove some forms of central control, but it does not remove the need for trusted functions. Enterprises still need onboarding, permissioning, incident response, key custody, application governance, and dispute handling. That is why “no intermediary” is usually a shorthand for “different intermediary,” not “no controls.” NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because decentralised architecture still depends on identifiable control owners and measurable safeguards.
For security teams, the risk is assuming that protocol decentralisation automatically creates operational decentralisation. In practice, wallets, exchanges, node operators, smart contract admins, cloud hosts, and governance groups all become part of the trust chain. NHIMG research on the DeepSeek breach shows how quickly exposed credentials and weak control boundaries can turn a technical platform into an identity and access problem. In practice, many security teams encounter intermediary risk only after a key compromise, contract dispute, or governance failure has already caused loss.
How It Works in Practice
The practical mistake is treating blockchain as if the ledger itself replaces all operational trust. A blockchain can reduce dependence on a single recordkeeper, but it does not eliminate the need for organisations to decide who may write transactions, who may upgrade code, who can recover keys, and how exceptions are handled. In most enterprise deployments, the “middleman” is redistributed across identity, infrastructure, and governance layers.
That means practitioners still need controls around:
- private key custody and recovery
- smart contract change management and approval workflows
- node and validator administration
- access control for wallets, APIs, and administrative consoles
- monitoring, audit logging, and dispute escalation
The key issue is not whether a blockchain is permissionless or permissioned, but whether the organisation has made trust assumptions explicit. A permissionless network may reduce reliance on a traditional intermediary, yet the business still depends on infrastructure vendors, software maintainers, and operational responders. A permissioned network often makes this even clearer, because governance is formalised and the operator set is intentionally selective. NHIMG’s New York Times breach is a useful reminder that identity, access boundaries, and operational hygiene remain decisive even when the technology stack looks distributed.
Current guidance suggests treating blockchain as a control redistribution model, not a control elimination model. That approach aligns with NIST guidance on access control, auditability, and accountability, and it fits the reality that security and governance duties do not vanish when a ledger becomes shared. These controls tend to break down when organisations deploy blockchain for business processes that still require fast human intervention, because dispute resolution and emergency recovery inevitably reintroduce trusted intermediaries.
Common Variations and Edge Cases
Tighter decentralisation often increases operational complexity, requiring organisations to balance resilience against governance overhead. In permissionless systems, the main tradeoff is reduced central authority versus lower recovery control. In permissioned systems, the tradeoff shifts toward clearer governance versus the risk of recreating a traditional central administrator under a new name.
There is no universal standard for this yet, but current guidance suggests three common edge cases deserve special attention. First, smart contract admin keys can function as hidden intermediaries because they can change rules after deployment. Second, custodial wallet providers and exchange operators remain intermediaries even when the underlying ledger is decentralised. Third, cross-chain bridges, oracles, and off-chain services introduce new trust points that are often more fragile than the chain itself.
Security teams should also be cautious about using “decentralised” as a synonym for “trustless.” The system may be trust-minimised, but business accountability still exists. That is why governance, key management, and recovery playbooks should be designed explicitly rather than assumed away by the protocol. The practical lesson is simple: decentralisation can remove one class of intermediary, but it usually creates several operational ones that still need ownership and oversight.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Blockchain still needs explicit access governance and accountable control owners. |
| NIST SP 800-63 | Identity proofing and authentication still matter for wallets, admins, and operators. | |
| NIST Zero Trust (SP 800-207) | Distributed systems still need zero trust assumptions at each access decision point. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Keys and service identities remain intermediaries that must be secured and governed. |
| NIST AI RMF | The question is about governance and accountability, not just technical decentralisation. |
Verify each transaction, admin action, and service call independently instead of trusting network location.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they assume passwordless login automatically means stronger security?
- What do organisations get wrong when they assume EDR covers cloud risk?
- What do organisations get wrong when they assume AI is a general-purpose solution?
- What do organisations get wrong when they secure AI only at the model layer?
