User control should come first, because a wallet only improves identity security if people can decide what gets shared, with whom, and for what purpose. A wallet-first approach can easily become a new container for the same old centralisation problem. The better model is to define disclosure and assurance rules before choosing the wallet experience.
What the right starting point is for digital identity strategy
A wallet can be a strong delivery mechanism, but it is not the strategy itself. The strategy has to start with disclosure rules, assurance levels, consent boundaries, and the relying-party conditions that govern when data should be shared. That order matters because the wallet experience only works well when the underlying identity model is already clear.
For teams building a broader identity operating model, the question is usually less about technology choice than identity strategy and governance. A wallet-first programme often begins with a product promise and then tries to force policy into the interface. A user-control-first programme starts with the policy outcome and then selects the wallet pattern that can safely express it.
That distinction also fits the way modern digital identity ecosystems are being shaped by eIDAS 2.0 and the European Digital Identity Framework, where wallet capability sits inside a larger framework of trust, disclosure, and cross-border use. In practice, the wallet should implement an agreed identity policy, not define it.
Why wallet-first models can recreate centralisation
A wallet-first model can look decentralised while still leaving control concentrated in the hands of issuers, platform operators, or a dominant wallet provider. If the user cannot decide what is disclosed, to whom, and under what purpose, the wallet becomes only a new container for old gatekeeping. That shifts the centralisation problem rather than solving it.
The core failure mode is that technical possession of a wallet is mistaken for actual user agency. A person may hold the wallet, but still face rigid attribute release, opaque trust decisions, or a narrow set of approved journeys. That is why digital identity wallets and verifiable credential patterns need selective disclosure, relying-party policy, and trust framework design to be defined before implementation choices harden.
There is also an assurance issue. If wallets are treated as the answer before the assurance model is agreed, organisations may overstate what the wallet proves. Identity proofing strength, binding between holder and credential, and acceptable levels of re-use all affect whether the wallet improves trust or just repackages it. The wallet is therefore a mechanism, not a substitute for identity design.
What user-control-first changes in practice
User-control-first means the strategy defines the user decisions that must remain explicit, then chooses wallet capabilities to support those decisions. That usually includes disclosure minimisation, purpose alignment, selective release, and a clear boundary between what the user can approve and what the relying party must enforce.
This approach is closer to how mature identity programmes are built: govern the lifecycle and policy first, then select the container. The same principle appears in identity security programme design, where operating model, governance, and accountability come before tooling, and in identity maturity planning, where capabilities are sequenced rather than assumed to arrive with a new front end.
For practitioners, the real test is whether the wallet supports informed choice without weakening assurance. If the wallet lets users share less data without breaking trust in the transaction, that is progress. If it only hides centralised policy behind a more modern interface, the strategy has not changed, only the packaging has.
Risk and Threat Considerations
Wallet-first programmes can introduce governance risk when the product roadmap outruns the trust model. The main exposure is false confidence, where organisations assume the presence of a wallet means better privacy, better security, or better user control, even though disclosure and assurance logic remain unresolved.
Failure mechanism: Centralised policy, overbroad attribute release, or weak assurance can turn the wallet into a convenient wrapper for concentrated control, reducing visibility into who decides what is shared and why.
Impact: The result can be consent fatigue, unnecessary data disclosure, weaker relying-party trust decisions, and strategic lock-in to a wallet design that is hard to correct later.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Wallet-based digital identity concerns external-user authentication and assurance. |
| IA-2 — Identification and Authentication (Organizational Users) | Identity programmes must define who is authenticated and under what rules. | |
| AC-6 — Least Privilege | User-control-first identity design depends on limiting unnecessary disclosure and access. | |
| Recommendation — Specify assurance and authentication requirements before selecting wallet UX. Define authentication policy and user authority before implementing identity tooling. Constrain attribute release and data access to the minimum required for each relying party. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Proofing, Authentication, and Binding | Wallet strategy depends on how identities are proofed and bound to credentials. |
| Recommendation — Set proofing and binding requirements before approving wallet-based journeys. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Digital identity wallets need explicit access and disclosure governance. |
| Recommendation — Define access and disclosure rules before deploying wallet experiences. | ||
Practitioner Guidance
Decision rule: If the wallet cannot express user choice at the level of disclosure, purpose, and assurance, do not let it define the strategy. Fix the policy model first, then choose the wallet implementation that can enforce it.
What to verify: Confirm that the relying party can validate the credential without demanding more data than the use case requires, and that the user has a genuine ability to approve or refuse release without breaking the identity journey.
What good looks like: The organisation can explain, in plain terms, why each attribute is requested, what assurance it carries, and what the user can meaningfully control. If those answers are unclear, the wallet design is premature.
Practitioner takeaway: Wallets are delivery mechanisms; user control is the control plane. If the control plane is weak, a better wallet only makes the weakness easier to scale.
Related resources from NHI Mgmt Group
- What is the difference between a federated identity model and a user-controlled digital identity wallet?
- How should cities implement a digital identity wallet for citizen services without making the user experience too complex?
- How should organisations prepare identity and access processes for the eIDAS 2 digital wallet model?
- Why does first-party fraud create a different control problem than identity theft in digital onboarding and payments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org