Customers should verify which parts of the service are truly non-custodial and which depend on operator-controlled infrastructure. If a central database, recovery workflow, or internal permission layer can affect asset access, users should treat the platform like a partially centralised service and reassess exposure. The practical question is whether the architecture can survive compromise without direct loss of customer funds.
What “decentralised” should mean in practice
A platform is only truly decentralised if users can understand which functions are on-chain or self-custodied and which ones still depend on a central operator. That distinction matters because custody, recovery, routing, identity controls, and policy enforcement can all sit behind a decentralised front end. If any of those controls can independently affect access, the decentralisation claim is only partial.
Customers should test the operating model, not the marketing language. A service may use distributed ledgers, smart contracts, or non-custodial wallets while still relying on a central database, an admin console, a key recovery service, or a permissions layer that can block, redirect, or restore access. When that happens, the real question is not whether the platform is “web3”, but what can still be changed or seized by the operator.
That is why vendor evaluation for this class of product should focus on control boundaries: who can move assets, who can freeze them, who can recover accounts, and what happens if the operator’s systems are compromised. In customer identity and platform selection work, a useful CIAM Buyer's Guide lens is to treat account recovery, authentication, and access governance as first-class design questions rather than afterthoughts.
Which central dependencies matter most
The most important central dependencies are the ones that can still change an outcome even when the asset ledger itself is decentralised. A central database can become the source of truth for balances or entitlements. A recovery workflow can override a user’s cryptographic control. A backend approval step can delay, deny, or reroute transactions. Each of these creates a practical trust anchor outside the purportedly decentralised core.
Customers should also check whether the platform’s strongest protections are technical or administrative. If the service relies on operator approval for resets, exception handling, fraud review, or access restoration, then the operator’s internal permissions become part of the security boundary. That does not automatically make the product unsafe, but it does mean the user is depending on the operator’s operational security, not only on blockchain design.
For that reason, platforms that expose customer access through APIs, dashboards, or recovery portals should be treated as access-controlled services, not as purely autonomous protocols. The relevant control question is whether the operator can use those interfaces to change who can transact, when they can transact, or what they can see.
How customers should assess the real exposure
Customers should ask a simple sequence of questions: can the operator freeze assets, can support staff restore access, can internal policy block transactions, and can a compromise of the central layer affect funds without touching the user’s private key? If the answer to any of those is yes, the platform has a centralised control plane that deserves the same scrutiny as any other security-critical service.
That scrutiny should include failure modes, not just happy-path features. Review what happens if the operator loses administrative control, if a privileged account is abused, if the recovery service is spoofed, or if the central database is corrupted. Also verify whether the platform has a clear separation between informational convenience and control authority, because many services blur that line in ways users only discover after an incident.
External assurance can help, but only if it is tied to the specific dependency that matters. Standards such as ISO/IEC 27001:2022 Information Security Management and NIST SP 800-53 Rev 5 Security and Privacy Controls are useful when they translate into concrete control evidence for access administration, recovery, logging, and privileged operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Recovery and operator access depend on secret and authenticator lifecycle controls. |
| AC-6 — Least Privilege | Operator and support permissions can still change customer access or asset outcomes. | |
| Recommendation — Enforce strict lifecycle control over admin and recovery authenticators. Limit support and admin actions to the minimum required privilege. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Central permission layers and recovery paths are access-control dependencies. |
| A.8.5 — Secure authentication | Claims of decentralisation still depend on trustworthy admin and recovery authentication. | |
| Recommendation — Define and enforce access rules for all operator-controlled paths. Use strong authentication for any privileged operator workflow. | ||
Practitioner Guidance
What to verify: Ask for a plain-language architecture description that identifies the non-custodial components, the operator-controlled components, and the exact conditions under which support or administration can affect asset access. If the answer stays vague, assume the central layer is material.
Decision rule: If a central database, recovery flow, or internal permission layer can change custody, freeze access, or restore control, treat the service as partially centralised and size your exposure accordingly. Do not rely on decentralisation branding to offset that dependency.
What good looks like: The platform can explain, and ideally evidence, which actions are irreversible on-chain, which require operator involvement, and which are protected by separation of duties and auditability. Users should be able to distinguish convenience features from true control boundaries.
Practitioner takeaway: The critical issue is not whether a platform uses decentralised technology, but whether any central operator can still influence the loss, recovery, or movement of customer assets.
Related resources from NHI Mgmt Group
- What breaks when a decentralised crypto platform keeps a central database behind the scenes?
- Who is accountable when a sovereign platform still uses external dependencies?
- Who remains accountable when decentralised identity systems still handle regulated or sensitive user data?
- Why do agentic systems still need strong architecture judgment even when a platform provides a reusable harness?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
