Start by separating the legal purpose of each data element from the technical place it is stored. Keep personal data off-chain where possible, minimise what is recorded on-ledger, and preserve an off-chain trust layer for verification, audit evidence, and deletion handling. That approach reduces conflict between immutable infrastructure and regulatory obligations.
Design the identity flow around data purpose, not ledger convenience
For Web3 identity, the first design decision is whether a data element truly needs to be on-chain, or whether it only needs to be referenced there. Personal data, recovery data, and anything that could later need correction or deletion should be held off-chain wherever possible. On-ledger records should be reduced to the minimum needed for verification, integrity, and workflow coordination.
This matters because blockchain immutability and privacy obligations can pull in opposite directions. A clean design separates the legal purpose of the data from the technical location of the record, so the identity flow can support verification without turning the ledger into a long-term personal-data store.
When teams need a broader control view, NHIMG’s Identity Security Regulatory Map is useful for mapping identity controls to regulatory obligations, while the Identity Data Privacy and Consent Guide is the better fit for minimisation, retention, consent, and rights handling.
Keep verification, audit evidence, and deletion handling in the off-chain trust layer
A compliant Web3 identity architecture usually needs an off-chain trust layer that can perform verification, maintain audit evidence, and handle deletion or correction workflows. The ledger can anchor trust, but the operational evidence should live in systems that can actually support access control, retention rules, and lifecycle updates.
That pattern lets teams preserve proof of issuance, revocation, and verification without embedding full identity dossiers on-chain. It also supports AML review, because the organisation can retain the evidence needed for monitoring and investigations while still limiting what is exposed to the public or shared ledger.
For identity lifecycle discipline, NHI Lifecycle Management Guide helps with provisioning, rotation, offboarding, and visibility, and Top 10 NHI Issues is a useful companion when wallet-backed or automated identity components begin to behave like long-lived operational identities.
Balance GDPR minimisation with AML traceability by scoping what must be linked, not broadly exposed
GDPR and AML do not require the same data handling model, so teams should design explicit linkage points rather than publishing everything in one place. For GDPR, the objective is lawful processing, minimisation, and controllable retention. For AML, the objective is enough traceability to support customer due diligence, risk-based monitoring, and suspicion handling without unnecessary disclosure.
In practice, that means using pseudonymous or reference-based on-chain artefacts where possible, with controlled off-chain resolution only for authorised compliance functions. If the flow requires stronger identity assurance at enrolment or access time, the authentication step should be treated as a separate control, not as a reason to expose more personal data on-ledger.
The direct regulatory anchors are the EU General Data Protection Regulation (GDPR) and FATF Recommendations. For operational programme work, teams often pair those with FinCEN guidance in US contexts or EBA AML/CFT Guidance in EU financial environments.
Risk and Threat Considerations
The main failure mode is making the ledger the primary identity store. That creates durable exposure, makes deletion difficult, and increases the blast radius if a wallet, credential, or identity mapping is compromised. It can also leave teams unable to reconcile immutable records with regulatory correction, retention, or minimisation obligations.
Failure mechanism: Sensitive identity data, linkage keys, or recovery details get written on-chain or become trivially inferable from public metadata, so the organisation loses practical control over disclosure and lifecycle handling.
Impact: The result can be privacy exposure, broken deletion workflows, weak AML segregation, and a difficult remediation path because the exposed data cannot simply be removed from the ledger.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Principles Relating to Processing of Personal Data | Web3 identity flows must minimise and limit personal data processing. |
| Art.25 — Data Protection by Design and by Default | Design must separate verification from unnecessary personal-data exposure. | |
| Art.32 — Security of Processing | Identity flows need controls that protect off-chain trust data and linkage keys. | |
| Recommendation — Minimise on-chain personal data and keep lawful-purpose boundaries explicit. Build off-chain defaults and only publish the minimum ledger reference needed. Protect identity records and linkage material with strong access and integrity controls. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Wallet or API-based identity verification can fail if authentication is weak or misbound. |
| API5 — Broken Function Level Authorization | AML and identity administration flows require strict role separation and access limits. | |
| Recommendation — Harden identity verification endpoints so asserted identity cannot be spoofed. Enforce function-level authorization for identity, recovery, and compliance actions. | ||
| OWASP ASVS | V8 — Authorization | Identity and AML workflows depend on tightly scoped access to sensitive operations. |
| V14 — Data Protection | The subject hinges on limiting disclosure and protecting personal identity data. | |
| Recommendation — Restrict identity-linkage and compliance functions to authorised roles only. Store sensitive identity data off-chain and protect all residual references. | ||
| CIS Controls v8 | CIS-5 — Account Management | Wallet-backed and off-chain admin accounts need disciplined lifecycle control. |
| Recommendation — Inventory, review, and remove unused identity-administration accounts and access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | AML and identity-resolution functions should only be available to narrowly scoped roles. |
| Recommendation — Limit access to identity-resolution and compliance functions to the minimum necessary. | ||
Practitioner Guidance
What to verify: Confirm which data fields are truly required for verification, which are only needed for compliance review, and which can remain off-chain with a signed reference or hash on-ledger. If a field would be hard to justify in a DPIA or AML record-retention review, it probably does not belong on-chain.
Decision rule: If a ledger entry must survive indefinitely, limit it to non-sensitive anchors and state transitions. If the business process needs reversible handling, correction, or deletion, keep the underlying personal data and audit evidence in the off-chain trust layer.
Practitioner takeaway: The safest Web3 identity design is usually not the most transparent ledger design, it is the one that makes the chain a verifier of state while keeping legally sensitive identity operations in systems that can actually govern them.
Related resources from NHI Mgmt Group
- How should security teams design browser-extension notification flows for identity actions?
- How should security teams handle GDPR requirements in identity programmes?
- How should security teams design identity proofing for account recovery and MFA reset flows?
- How should teams design event check-in flows that balance speed with identity validation?