Organisations should separate identity data into individual encrypted elements, keep encryption keys under user control, and minimise provider access to shared attributes. That design reduces the blast radius of a compromise and limits what the service itself can see or reuse. It also supports consent-based sharing, so users can disclose only the specific information needed for a transaction.
Design for data minimisation at the attribute level
Digital identity apps work best when they treat personal data as a set of separable claims, not a single profile that must be exposed wholesale. If the app can issue only the exact attribute needed for a transaction, users keep practical control over disclosure, and the organisation reduces unnecessary retention, replication, and secondary use.
That design should also make trust boundaries explicit. A user-facing wallet or identity app should not force the service provider to see or store the same data that is needed only for verification. Keeping those roles separate makes it easier to support selective disclosure, reduce internal access, and limit the data that can be aggregated later.
For organisations building digital identity products, the right question is not whether the app can collect more data, but whether each attribute has a clear purpose and a clear expiry. Where a data element is only needed for proof, verification, or consented sharing, it should not become part of a standing provider record.
Make user control technically enforceable, not just contractual
User control depends on cryptographic and architectural choices. If encryption keys remain under user control, or are protected in a way that the provider cannot unilaterally use them, the service cannot silently expand its access to the underlying data. That matters because policy statements about privacy are weak if the platform itself can decrypt and reuse everything at will.
The same principle applies to shared attributes and metadata. Organisations should minimise provider visibility into the full identity graph, transaction history, and any correlated attributes that are not required for the exchange. When the service can observe less, it can infer less, store less, and expose less if it is compromised.
A useful benchmark is whether the app can still function when provider access is tightly constrained. If the answer is yes, the design is closer to user-controlled identity. If the answer is no, the product may be convenient, but it is still behaving like a centralised data concentration point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.25 — Data Protection by Design and by Default | This design minimises personal data collection and disclosure by default. |
| Art.32 — Security of Processing | Encryption and key control are central to protecting identity data in transit and at rest. | |
| Art.5 — Processing Principles | Purpose limitation and data minimisation directly shape how identity attributes are stored and shared. | |
| Recommendation — Build selective disclosure and minimisation into the identity app from the outset. Protect identity data with strong encryption and tightly governed key handling. Limit identity data collection, retention, and reuse to what the transaction requires. | ||
| NIST CSF 2.0 | PR.DS — Data Security | The answer depends on protecting identity data and constraining exposure through architecture. |
| PR.AC — Identity Management, Authentication and Access Control | User-controlled access to identity attributes is an access-control design problem. | |
| Recommendation — Apply data protection controls that reduce exposure and limit unnecessary sharing. Enforce access boundaries so the service only sees the attributes it must verify. | ||
| CIS Controls v8 | 6 — Access Control Management | Selective disclosure and limited provider access are access-control outcomes. |
| 3 — Data Protection | Encrypted elements and reduced retention directly align to data protection safeguards. | |
| Recommendation — Restrict access paths to identity data to the minimum required for each transaction. Encrypt sensitive identity elements and minimise stored copies wherever possible. | ||
Practitioner Guidance
What to verify: Check whether each identity attribute has a purpose, a retention rule, and a disclosure boundary. If the provider can read or recombine more than the transaction needs, the control is weaker than the privacy promise suggests.
What to prioritise: Start with the data elements that create the biggest blast radius if exposed, then separate them from the verification path. In practice, that means designing the app so selective disclosure is the default and broad provider access is the exception.
Common mistake: Treating consent screens as the main privacy control. Consent is useful, but real user control depends on how data is stored, encrypted, and shared after consent is given.
Practitioner takeaway: The strongest design is one where the organisation can verify what it needs without becoming the permanent custodian of everything the user has disclosed.
Related resources from NHI Mgmt Group
- How should organisations design digital identity systems that minimise unnecessary data sharing during authentication?
- How should organisations implement interoperable digital identity acceptance without exposing unnecessary personal data?
- How should organisations design digital identity wallets so they share only the minimum data needed for each transaction?
- How should organisations build trust in digital identity without collecting more personal data than they need?
