The main failure is that the original link between the person and the stored record can persist indefinitely. Even if an organisation attempts to nullify an identifier, copied transactions and distributed replicas may still retain traceable history. That can undermine both privacy obligations and trust in downstream records, especially where later blocks depend on earlier data.
Why This Matters for Security Teams
Writing personal identity data directly to a blockchain creates a permanence problem that privacy teams cannot “undo” later. Even if an organisation stops using a field or replaces a pointer, replicated ledger history can keep the original link available through prior transactions, forks, exports, or downstream copies. That creates tension with erasure obligations, data minimisation, and record integrity. NIST’s Cybersecurity Framework 2.0 emphasises governance and risk treatment, but blockchain immutability changes the remediation model.
NHIMG’s 52 NHI Breaches Analysis shows how durable identifiers and copied access paths keep creating exposure long after the original event, and the same pattern applies when personal data is anchored on-chain. Once identity fields are committed into an append-only system, later deletion requests often become operationally ambiguous rather than technically clean. In practice, many security teams discover the conflict only after legal, privacy, or audit teams have already assumed the record could be made to disappear.
How It Works in Practice
The core issue is that blockchains are designed to preserve history, while privacy obligations often require selective removal, suppression, or disassociation. If a person’s name, national identifier, email, or other personal attribute is written directly into a transaction, the ledger becomes a durable source of truth for that link. Even when a later transaction marks the record as revoked, the earlier data still exists in the chain’s history and may still be replicated across nodes, backups, analytics pipelines, and third-party exports.
Security and privacy teams usually need to separate three layers of control:
- What is written on-chain, which should be limited to non-personal or non-reversible references.
- What is held off-chain, where deletion, retention, and access rules can actually be enforced.
- How identity mapping is protected, so the person-to-record relationship can be rotated, revoked, or destroyed without rewriting the ledger.
Current guidance suggests that direct on-chain storage of personal identity data should be avoided wherever possible. Better practice is to place only hashes, commitments, or pointers on-chain, while keeping the underlying personal data in a system that supports deletion and access control. That approach aligns better with privacy engineering and with the governance intent reflected in Ultimate Guide to NHIs and Top 10 NHI Issues, which both stress lifecycle control and the risk of durable identifiers.
Where organisations need attestations, they should consider revocation registries, off-chain consent records, and key destruction as part of the deletion workflow, rather than assuming ledger edits are possible. These controls tend to break down when the blockchain is public or widely mirrored because the organisation no longer controls all copies of the data path.
Common Variations and Edge Cases
Tighter immutability often improves auditability, but it increases privacy and remediation overhead, requiring organisations to balance evidentiary value against the right to suppress personal data. That tradeoff becomes most difficult in consortium and public chains, where no single party can guarantee removal across every replica or index. Best practice is evolving, and there is no universal standard for this yet.
A frequent edge case is pseudonymised identity data. If a hash, wallet address, or derived identifier can still be linked back to a person using external records, deletion requests may not eliminate the privacy risk even if the raw field is removed elsewhere. Another edge case is smart contract dependency: if later blocks rely on earlier personal data for entitlement, provenance, or eligibility checks, “forgetting” the data can break downstream business logic unless the system was designed for revocation from the start. That is why organisations should treat direct personal data writes as a design flaw, not just a compliance problem.
The safest pattern is to keep the ledger as proof of event state, not as a repository for identities. In practice, NHIMG’s research on JetBrains GitHub plugin token exposure and DeepSeek breach reinforces a broader lesson: once sensitive links are widely copied, true erasure becomes far harder than organisations expect.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Blockchain identity writes require explicit risk treatment and governance decisions. |
| NIST AI RMF | AI RMF helps govern durable identity data and downstream misuse risk. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Directly addresses overexposed or improperly stored non-human and identity-linked data. |
| CSA MAESTRO | IAM-03 | Identity lifecycle controls are essential when records cannot be edited or removed. |
| NIST SP 800-63 | IAL2 | Identity assurance matters when persistent identifiers can outlive their purpose. |
Design revocation and off-chain identity mapping so ledger history never becomes the sole source of truth.
Related resources from NHI Mgmt Group
- What breaks when identity systems ask for more personal data than the transaction actually needs?
- How should organisations implement decentralized identity for age or attribute verification without exposing unnecessary personal data?
- What breaks when blockchain identity systems are treated as automatically secure?
- Why is it important to integrate identity and data governance?
