Subscribe to the Non-Human & AI Identity Journal
Home FAQ What do security and compliance teams get wrong…

What do security and compliance teams get wrong about decentralised systems?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated July 10, 2026

They often assume decentralisation removes governance dependencies. In practice, access to wallets, exchanges, validation infrastructure, and analytics still sits with identifiable operators. Effective governance looks at those control points directly, including approval authority, monitoring, and the ability to revoke access when conditions change.

Why This Matters for Security Teams

Decentralised architectures are often described as removing intermediaries, but they do not remove control points. Wallet custody, exchange access, smart contract administration, validator operations, and analytics platforms still depend on identifiable operators, secrets, and approval paths. That means the real governance question is not whether a system is decentralised, but whether privileged actions are traceable, revocable, and aligned to policy.

This is where teams commonly misread the risk. They assume blockchain transparency equals security transparency, when the harder problem is who can move value, change code, or approve exceptions. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both stress that governance follows the control plane, not the marketing narrative. In practice, many security teams discover that decentralisation was never the control model, only the distribution model, after an incident exposes a weak key, a stale approval workflow, or an unaudited admin path.

Security and compliance teams should therefore evaluate decentralised systems through the lens of NIST Cybersecurity Framework 2.0 and clear accountability for access, monitoring, and recovery. That includes privileged access to wallets, signing services, governance contracts, and any automation that can act without human review. When this is not mapped explicitly, controls tend to look strong on paper while the highest-risk actions remain under-governed in production.

How It Works in Practice

Effective governance starts by identifying the operational choke points, then assigning ownership for each one. In decentralised environments, those choke points often include multisig signers, key management systems, admin consoles, validator nodes, bridge operators, oracles, and the pipelines that feed trading or risk analytics. Each should have a named owner, an approval rule, logging, and a revocation process. The control objective is simple: no critical action should depend on a hidden individual, undocumented script, or unrecoverable credential.

That approach aligns well with NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially for access control, auditability, and configuration management. It also supports audit expectations described in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. For teams handling wallets or token flows, the governance model should also incorporate fraud and financial crime considerations from the FATF Recommendations, particularly where identity assurance, transaction approval, and monitoring intersect.

  • Inventory all operational identities, not just human users, including service accounts, bots, validators, and signer roles.
  • Separate initiation, approval, and execution for high-impact actions wherever the architecture allows it.
  • Apply least privilege to keys and admin roles, with rotation and break-glass procedures that are tested, not assumed.
  • Log control-plane events in a way that supports forensic review, compliance evidence, and incident response.
  • Define recovery thresholds so a lost key, compromised signer, or failed node does not become a systemic failure.

This guidance breaks down when decentralised components are embedded in third-party custodial services or opaque managed infrastructure, because the organisation may own the risk but not the underlying control evidence.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance resilience against speed, and auditability against user autonomy. That tradeoff is especially visible in decentralised systems where different components carry different trust assumptions. A governance rule that works for a validator cluster may be too rigid for a hot wallet rotation process, while a flexible developer workflow may be unacceptable for production treasury actions.

There is no universal standard for this yet, so current guidance suggests treating the environment as a portfolio of control zones rather than one monolithic decentralised system. Public blockchain activity may be visible, but visibility is not the same as control. On-chain transparency can help with detection, yet it does not eliminate the need for access governance, exception handling, or evidence retention. Teams should be careful not to overstate what decentralisation guarantees.

Edge cases appear most often in cross-border operations, tokenised finance, and systems that combine on-chain execution with off-chain governance. In those settings, compliance teams should map policy obligations to the people and processes that can actually pause activity, rotate keys, or amend smart contract permissions. NHIMG’s research on Top 10 NHI Issues is useful here because the same failure pattern recurs: the system looks decentralised, but the decisive control still sits with a small set of operators. That gap is where assurance programs most often fail to match the reality of production governance.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV.OC-01Decentralised systems still need clear organisational roles and accountability.
NIST SP 800-63High-risk approvals still depend on strong identity proofing and authentication.

Define who owns each control point and document responsibility for approval, monitoring, and recovery.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org