The common mistake is assuming immutability automatically creates trust. Blockchain can preserve records, but it does not verify whether the original identity, credential, or transaction request was legitimate. If upstream identity proofing is weak, the chain simply preserves bad data with better auditability. Security teams still need governance, verification, and access control around the workflow.
Why This Matters for Security Teams
Blockchain can strengthen integrity, but it does not create trust on its own. Trust depends on verifying who initiated an action, whether the credential was valid, and whether the transaction should have been allowed in the first place. That distinction matters because immutable logs can make bad input harder to remove, not easier to prevent. NHI Management Group’s reporting on the DeepSeek breach shows how exposed identities and credentials can turn a supposedly controlled environment into an abuse path. The same problem appears in broader governance programs when teams treat ledger technology as a substitute for identity proofing, access control, and workflow approval.
The practical risk is that leaders over-invest in the record of trust instead of the mechanisms that create trust. A blockchain may preserve provenance, but it cannot determine whether a signer was a legitimate service account, whether a secret had already leaked, or whether an agent had permission to act in context. Current guidance from the NIST Cybersecurity Framework 2.0 still points back to governance, identity, and protection controls as the real foundation. In practice, many security teams discover this only after an irreversible transaction, not during design review.
How It Works in Practice
The right way to think about blockchain is as a tamper-evident control, not a trust engine. It can help with provenance, non-repudiation, and ordered history, but it does not replace upstream validation. If an organisation uses weak identity proofing, long-lived API keys, or permissive signing workflows, the chain will faithfully preserve the result of those weaknesses. That is why NHI controls still matter even when a ledger is involved: credential lifecycle, workload identity, privilege boundaries, and approval logic all remain separate security problems.
In practice, a trustworthy workflow usually has three layers:
- Identity proofing or workload identity for the entity that is requesting action.
- Policy checks that decide whether the request is allowed in the current context.
- Immutable logging that records what happened for audit and dispute handling.
This is especially important for service accounts, automation pipelines, and AI agents that can chain actions quickly. A signed transaction from a compromised identity is still a compromised transaction. The goal is to make the blockchain an evidentiary layer, not the sole control plane. The secrets-management gap highlighted in The State of Secrets in AppSec shows why this matters: if secrets are leaked or mishandled, the ledger simply preserves the consequences. Security teams should align ledger use with access governance, secret rotation, and transaction-level approval, rather than assuming the platform itself enforces trust. These controls tend to break down in environments with shared wallets, hardcoded keys, or unauthenticated automation because the ledger cannot distinguish legitimate action from replayed or stolen authority.
Common Variations and Edge Cases
Tighter on-chain controls often increase operational overhead, requiring organisations to balance stronger provenance against developer friction and transaction latency. That tradeoff becomes more visible in hybrid architectures, where some steps happen on-chain and others happen in off-chain services that still need conventional IAM, secrets management, and audit review. There is no universal standard for this yet, so current guidance suggests treating the ledger as one control among many rather than the centre of the architecture.
Edge cases usually arise when teams assume that public verifiability equals business trust. A public chain may improve transparency, but it does not solve false attestations, compromised signing keys, or bad oracle input. Private or permissioned blockchains can reduce exposure, yet they still depend on governance over node operators, key custody, and update authority. The result is a familiar pattern: the stronger the cryptographic record, the more important it becomes to secure the identities and systems feeding that record. For organisations building around AI, automation, or delegated service identities, the lesson from NHIMG research on the DeepSeek breach is clear: a durable log does not compensate for a weak trust decision upstream.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Trust fails when NHIs are poorly verified before signing or acting. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control remain required even with immutable logs. |
| NIST AI RMF | GOVERN | Governance must control whether automated or AI-driven actions are trustworthy. |
| NIST Zero Trust (SP 800-207) | SC-4 | Zero trust requires continuous verification, not trust by immutability. |
| CSA MAESTRO | TRU-02 | Agent and workflow trust still depends on upstream validation and policy. |
Establish oversight for identity, approval, and accountability before ledger writes.
Related resources from NHI Mgmt Group
- What do organisations get wrong about decentralisation when evaluating blockchain for security use cases?
- What do organisations get wrong when they assume blockchain automatically removes the need for intermediaries?
- What do organisations get wrong when they treat zero trust as a compliance checkbox?
- What do organisations get wrong when they assume EDR covers cloud risk?
