A common mistake is treating blockchain as automatically decentralised in a meaningful governance sense. In practice, decentralisation depends on who can join, validate, and change the system. If one authority controls permissioning and consensus, the network behaves more like a distributed ledger with cryptographic protections than a fully decentralised public system.
Why This Matters for Security Teams
Decentralisation is often treated as a binary property, but security teams need to evaluate who actually controls entry, validation, governance, and upgrade authority. A blockchain can use cryptography and distributed replication without being meaningfully decentralised in the governance sense. That distinction matters because attackers, insiders, and consortium members exploit control concentration, not marketing labels. The NIST Cybersecurity Framework 2.0 reinforces that asset trust and control boundaries should be explicit rather than assumed.
For NHI and security workflows, the same mistake appears when organisations assume a ledger removes the need for accountability, access control, or revocation discipline. If one operator controls permissioning, key management, and consensus changes, the system may still be highly resilient, but it is not decentralised in a way that reduces governance risk. The practical question is not whether records are distributed, but whether trust is actually dispersed across independent parties. In practice, many security teams discover that a “decentralised” design still concentrates power after a permissioning change, an incident, or a consortium dispute has already exposed the control points.
How It Works in Practice
In security evaluations, decentralisation should be broken into separate control questions: who can join the network, who can validate transactions, who can upgrade smart contracts or chain rules, and who can reverse or freeze activity. If the same organisation answers all four, the architecture may be useful, but it is not decentralised in the governance sense. That is why The State of Non-Human Identity Security is relevant here: control concentration is a recurring theme across identity and access failures, even when systems appear distributed.
Practitioners should evaluate the design as a trust model, not as a technology category. Useful checks include:
- Permissioning: can new validators or nodes be added without unilateral approval?
- Consensus: does a small operator set control block production or finality?
- Upgrade power: can one party deploy changes that alter security assumptions?
- Operational control: who manages private keys, admin accounts, and recovery paths?
For public chains, decentralisation may be stronger at the protocol layer but weaker in token concentration, client dependence, or infrastructure hosting. For private or consortium chains, the system can still support integrity, auditability, and tamper-evident logging, but those properties should not be confused with distributed governance. The right conclusion is often that blockchain can reduce reliance on a single database administrator while still leaving trust concentrated in a small administrative coalition. That distinction is central to security architecture, especially when decision-making, revocation, or emergency intervention remains centrally controlled. These controls tend to break down when a small committee controls both validator admission and software upgrades because governance can be overridden faster than the trust model was designed to detect.
Common Variations and Edge Cases
Tighter decentralisation controls often increase operational overhead, requiring organisations to balance resilience against speed, cost, and recovery complexity. In practice, that tradeoff is where many blockchain security proposals become overstated. A fully permissionless model can improve censorship resistance, but it may not fit regulated environments, incident response requirements, or data handling obligations. A permissioned consortium may be easier to govern, but it should be described honestly as shared control rather than full decentralisation.
Best practice is evolving on how to score decentralisation for security use cases, and there is no universal standard for this yet. Current guidance suggests documenting the specific trust assumptions that matter most: validator diversity, administrative separation, software supply chain control, and recovery authority. For example, a system can be decentralised for record integrity while remaining centralised for onboarding and policy changes. That is not a failure if the design intent is explicit. It is a failure only when teams assume the label itself provides assurance.
Security reviewers should also watch for edge cases where decentralisation exists on paper but not in practice, such as hosted validator clusters, single-vendor wallet custody, or emergency multisig arrangements controlled by the same executives. The most common error is using decentralisation as a proxy for trust minimisation without examining who can still intervene, override, or exclude participants. The DeepSeek breach shows how quickly exposed secrets and weak control boundaries turn “distributed” systems into concentrated risk events.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM | Decentralisation claims should map to real asset and control ownership. |
| NIST AI RMF | GOVERN | Governance is central to evaluating whether decentralisation is meaningful. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Blockchain systems still rely on identities, keys, and privileged control points. |
| CSA MAESTRO | AIC-03 | Shared control and policy enforcement are core to trustworthy decentralised architectures. |
| NIST Zero Trust (SP 800-207) | SC-8 | Decentralised systems still need explicit trust boundaries and continuous verification. |
Verify each transaction and administrative action instead of assuming distributed infrastructure is inherently trusted.
Related resources from NHI Mgmt Group
- What do organisations get wrong about DLP for AI use cases?
- What do organisations get wrong about explainable AI in regulated use cases?
- What do security teams get wrong about using AI for specialised or minority language use cases?
- What do security teams and investigators get wrong about blockchain anonymity in criminal cases?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
