A decentralised application is software that runs on a distributed blockchain network instead of a single central server. It uses network rules and cryptographic mechanisms to coordinate execution, state, and value transfer. The design can reduce platform dependency, but it also shifts responsibility for identity, permissions, and key protection to the operating environment.
Expanded Definition
A decentralised application, often called a dApp, is software whose execution and state depend on a distributed ledger or blockchain rather than one centrally controlled backend. In NHI and IAM discussions, the important distinction is not whether a user interface exists, but whether authority is split across network rules, smart contracts, and cryptographic keys. That makes dApps relevant to identity governance because access is often mediated by wallet signatures, contract roles, or off-chain services that still need controlled credentials. Definitions vary across vendors when they describe dApps as fully on-chain systems, hybrid systems, or simply applications that interact with a blockchain. The operational reality is usually hybrid: front ends, indexers, relayers, oracles, and API integrations introduce traditional secrets and privileged service identities even when the core logic is decentralised. For governance, a dApp should be treated as a distributed application boundary with identity and key-management obligations, not as a substitute for security controls. The most common misapplication is assuming decentralisation removes authentication and privilege management, which occurs when teams overlook the off-chain services and administrator keys that still control critical functions.
For a broader NHI lens, the Ultimate Guide to NHIs is useful because it frames how machine identities, secrets, and privilege boundaries operate outside human user accounts. Core identity concepts in distributed systems are also reflected in the NIST Cybersecurity Framework 2.0, especially where governance and access control must remain measurable across a mixed architecture.
Examples and Use Cases
Implementing a decentralised application rigorously often introduces coordination overhead, requiring organisations to weigh resilience and reduced platform dependency against harder incident response and more complex key custody.
- A DeFi application that executes trades through smart contracts, while a separate admin wallet manages upgrades and emergency pauses.
- A supply chain dApp that records provenance on-chain, but uses an API key to push events from enterprise systems into the ledger.
- A DAO governance portal where voting is decentralised, yet the website, analytics stack, and alerting tools still depend on centrally managed secrets.
- An identity-linked dApp that uses wallet signatures for user actions, while backend automation relies on service accounts and restricted contract operator keys.
- A cross-chain application that depends on an oracle network, making the integrity of the oracle’s credentials and relayers part of the security model.
These patterns align with the NHI reality described in Ultimate Guide to NHIs, where machine identities and secrets frequently outnumber human users. The application boundary may be decentralised, but the operational controls around deployment pipelines, wallet custody, and integrations remain conventional security responsibilities.
Why It Matters in NHI Security
Decentralised applications are attractive because they reduce reliance on a single platform owner, but they can also multiply identity risk when teams assume the blockchain itself solves security governance. In practice, the biggest failures come from exposed private keys, overprivileged admin wallets, insecure contract deployment pipelines, and unmanaged third-party integrations. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is a strong reminder that decentralised logic does not eliminate secret exposure. A dApp ecosystem also complicates revocation because contracts may be immutable, keys may be embedded in automation, and off-chain components may keep functioning after a compromise. That is why the relevant security question is not only whether the contract is trustworthy, but whether every non-human identity around it is inventoried, rotated, and constrained. The NIST Cybersecurity Framework 2.0 remains useful for mapping these risks into governance, detection, and recovery actions. Organisations typically encounter the true scope of dApp identity risk only after a wallet compromise, contract abuse, or leaked deployment secret, at which point the term becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | dApps often rely on exposed secrets and wallet-adjacent machine identities. |
| NIST CSF 2.0 | PR.AA | dApps need identity, authentication, and access governance across on-chain and off-chain components. |
| NIST Zero Trust (SP 800-207) | SC-7 | Decentralised execution still needs segmented trust boundaries and limited pathways. |
| NIST AI RMF | dApps introduce governance and accountability concerns when autonomous logic executes with authority. | |
| CSA MAESTRO | Agentic and distributed workflows need explicit control of tools, credentials, and escalation paths. |
Inventory every dApp secret, service account, and operator key, then remove uncontrolled storage.
