Governance should separate issuance, storage, presentation, and relying-party access so no single provider becomes the default owner of the entire identity lifecycle. Organisations should minimise stored attributes, require explicit consent for disclosure, and define clear oversight for wallet and attribute providers. The goal is control with bounded exposure, not a larger central identity repository.
What governance should control in a digital identity wallet
A digital identity wallet should be governed as a set of separable functions, not as one monolithic account store. Issuance, storage, presentation, and relying-party access each need distinct policy boundaries, because the biggest failure mode is turning a wallet into a new central repository for every attribute and interaction.
The practical governance question is who can issue, who can hold, who can present, and who can consume data. That division keeps the wallet from becoming the default owner of the whole identity lifecycle and lets organisations place controls where the actual risk sits.
For the wallet model itself, the European Digital Identity Framework is the clearest external anchor for eIDAS 2.0, because the regulation is built around wallet-based cross-border identity and trust services rather than a single central identity database.
How to avoid centralising user data while still maintaining assurance
Minimisation has to be the default design rule. Store only what the wallet must retain for its own function, and treat attributes as selectively disclosed assertions rather than a permanent replicated profile. That reduces exposure if the wallet, provider, or connected relying party is compromised.
Consent and disclosure policy also need to be explicit. Users should approve each release of attributes where the use case permits it, and organisations should distinguish between wallet possession, attribute issuance, and transaction-level presentation rights. This is where the governance model should favour bounded disclosure over broad reuse.
Good practice is to separate identity proofing from later wallet use, so the organisation can rely on strong onboarding without assuming the wallet itself should become an ongoing store of all identity evidence. The Identity Proofing and KYC Guide is useful for understanding that assurance at issuance is different from continuous data accumulation.
Where organisations need a better handle on what is being shared and by whom, Identity Data Privacy and Consent Guide helps frame minimisation, retention, and delegated access as governance controls rather than privacy afterthoughts.
Who should own oversight and what controls make the model sustainable
Oversight should be split across policy, provider assurance, and relying-party governance. Wallet operators, attribute issuers, and relying parties all need defined responsibilities, because the trust boundary moves when credentials and claims are presented across organisations.
That model works best when the organisation can answer three questions cleanly: which attributes are authoritative, which party may disclose them, and which relying parties may retain or correlate them. Without those answers, a wallet ecosystem can quietly recreate the same centralisation it was supposed to avoid.
The wallet ecosystem also depends on underlying identity data quality and source-of-truth discipline. If attribute provenance is unclear, the system encourages duplicate storage and downstream reconciliation, which is exactly the pattern that widens exposure. The Identity Data Quality and Identity Fabric Guide is relevant because it explains how authoritative sources and correlation should be used without collapsing everything into one repository.
For broader programme design, the Identity Security Programme Guide gives a useful operating model lens: clear ownership, explicit boundaries, and governance that spans the full lifecycle without treating every identity-related function as centrally controlled.
Risk and Threat Considerations
A wallet programme becomes risky when governance drift turns selective disclosure into broad attribute retention. The result is a larger trust concentration, more attractive compromise target, and more downstream correlation than the business actually needs.
Failure mechanism: If issuance, storage, presentation, and relying-party retention are not separately governed, the wallet provider can accumulate unnecessary attributes and create a single high-value dataset that outlives the transaction.
Impact: That creates higher breach impact, weaker user privacy, greater replay or correlation risk across services, and a governance model that is harder to justify under data minimisation expectations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 sets the technical controls, while EU AI Act, GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Regulatory framework | Wallet governance may intersect with AI-assisted identity checks and disclosure automation. |
| Recommendation — Track AI-assisted wallet processes under the EU AI Act when they affect identity decisions. | ||
| GDPR | Data minimisation and privacy by design | Wallets process personal data and selective disclosure directly implicates minimisation and consent. |
| Recommendation — Minimise stored attributes and limit disclosure to the specific purpose and lawful basis. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Wallet governance needs defined access boundaries for issuers, holders, and relying parties. |
| A.5.34 — Privacy and protection of PII | Selective disclosure and attribute retention are privacy-control problems in wallet ecosystems. | |
| Recommendation — Define and enforce access boundaries for wallet data and related trust relationships. Apply privacy controls to reduce retention and disclosure of wallet-held attributes. | ||
| NIST SP 800-63 | Digital identity guidelines | Wallet issuance and presentation rely on assurance, proofing, and authenticator trust concepts. |
| Recommendation — Use digital identity assurance and proofing guidance when defining wallet trust flows. | ||
Practitioner Guidance
What to prioritise: Define the trust boundary first, then decide which party is allowed to hold each attribute and for how long. If a party does not need persistent retention to complete the use case, do not grant it.
What to verify: Confirm that the wallet does not silently become the system of record for identity evidence, that attribute release is purpose-bound, and that relying parties cannot expand their access beyond the agreed presentation flow.
Common mistake: Teams often centralise data in the name of convenience, then call it wallet governance. In practice, convenience should sit in orchestration, not in storing more user data than the transaction requires.
Practitioner takeaway: The strongest wallet governance model is one that separates trust, storage, and disclosure so the organisation can improve assurance without creating a new identity super-repository.
Related resources from NHI Mgmt Group
- How should organisations use digital ID wallets for age assurance without over-collecting data?
- How should organisations secure mobile identity verification without over-sharing personal data?
- How should organisations govern digital forms that collect identity or biometric data?
- How should organisations implement interoperable digital identity acceptance without exposing unnecessary personal data?