A holder or wallet provider is the service that stores and presents digital credentials or tokens on behalf of a user. It manages secure storage, device binding, unlocking, and the presentation flow to a verifier, often using cryptographic keys and local protections such as biometrics or a passcode.
What the holder or wallet provider does
The holder or wallet provider is the component that stores a user’s digital credentials or tokens, protects them at rest, and presents them to a verifier when the user approves a disclosure or authentication flow. Its security role is to keep credential material usable without making it broadly accessible.
That role usually includes secure local storage, unlocking with a passcode or biometrics, device binding, and controlled presentation of selected attributes or claims. In practice, the wallet provider sits between the user, the device, and the relying party, so it must preserve both usability and trust.
Why the holder or wallet provider matters in digital identity
A wallet provider is not just storage, it is part of the trust boundary for the credential itself. If it mishandles unlock, binding, or presentation, the verifier may accept claims that were not properly authorised by the user or protected by the device.
In regulated digital identity ecosystems, the holder experience often depends on the surrounding trust framework. For example, the role definitions, certification model, and provider obligations in the UK Digital Verification Services Trust Framework Guide show how holder-facing services are governed as part of a broader identity assurance chain.
Because the wallet provider mediates access to sensitive credentials, it also has to respect stronger local protections than a normal app. Device-bound storage and attestation controls are especially important when the wallet is expected to resist cloning, replay, or export of the underlying keys.
Security properties a wallet provider must preserve
The most important properties are confidentiality of the stored credential, integrity of the credential state, and user-controlled release. The provider should prevent silent extraction, prevent unauthorised presentation, and make it obvious when credentials are being shared.
Cryptographic binding to the device or secure element helps ensure that possession of the app alone is not enough to use the wallet elsewhere. The Wallet Unit Attestation and Device-Bound Keys Guide is useful here because it explains how attestation and device-bound keys strengthen trust in the wallet instance itself.
Unlock mechanisms also matter. A passcode or biometric prompt is not merely a convenience feature, it is the gate that controls when stored credentials can be presented. If that gate is weak, the wallet can become a local privilege target even when the verifier side is well designed.
Common failure modes and operational expectations
Wallet providers fail when they overtrust the device, reuse secrets across contexts, or allow credentials to be exported without strong binding. They also fail when presentation logic is too permissive, because that can turn a selective disclosure flow into a bulk data leak.
Operationally, organisations should treat the wallet provider as part of the identity assurance stack, not as a generic mobile app. That means monitoring update integrity, certificate or attestation trust chains, key lifecycle events, and the conditions under which a wallet may be enrolled, restored, or revoked.
When the holder experience is built into a wider digital identity programme, the policy question is often who is trusted to issue, host, or mediate the wallet function. The EU’s digital identity direction makes that governance relationship explicit in eIDAS 2.0 — EU Digital Identity Framework, which anchors wallet-based identity in a formal regulatory model.
Risk and Threat Considerations
Holder and wallet provider risk concentrates around credential theft, device compromise, and abuse of the presentation flow. If an attacker can unlock the wallet, clone its secrets, or hijack the session before disclosure, the verifier may receive apparently valid credentials from the wrong actor.
Failure mechanism: Weak local protection, poor device binding, or insecure key storage can let malware, a stolen device, or a malicious app extract or replay the material needed to present credentials.
Impact: That can lead to account takeover, fraudulent claims presentation, and loss of trust in the wallet ecosystem, especially when the same holder service is reused across multiple verifiers or credentials.
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 SP 800-63 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Wallet providers depend on secure lifecycle handling of secrets and authenticators. |
| IA-9 — Service Identification and Authentication | Wallet presentation and verifier interactions depend on authenticated machine-to-machine trust. | |
| IA-2 — Identification and Authentication (Organizational Users) | Holder approval and local unlocking rely on strong user authentication before credential release. | |
| Recommendation — Manage wallet secrets with lifecycle controls that limit exposure, rotation gaps, and reuse. Authenticate wallet-to-verifier interactions before accepting presented credentials or tokens. Require strong user authentication before the wallet releases stored credentials. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Defines assurance and authenticator expectations for wallet-based digital identity flows. |
| Recommendation — Align wallet unlock and presentation flows to the applicable assurance and authenticator requirements. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Wallet providers rely on cryptography to protect stored credentials and presentation integrity. |
| Recommendation — Use cryptographic protections to keep wallet-held credentials confidential and tamper-resistant. | ||
Practitioner Guidance
Why practitioners should care: The wallet provider is where storage security, user approval, and presentation integrity meet, so design mistakes here create identity failures even when the credential issuer is sound. Practitioners should verify that the provider enforces strong unlock, keeps keys non-exportable where possible, and preserves the user’s ability to control each disclosure.
What to watch for: Pay close attention to recovery, restore, and cross-device migration paths, because those are common points where binding weakens and secret handling changes. If the wallet can be moved or reinstated too easily, the trust model often changes more than teams realise.
Related resources from NHI Mgmt Group
- What is the difference between a digital identity wallet and a Holder Service Provider?
- How should security teams protect cryptocurrency private keys without creating unnecessary trust in a wallet provider?
- What breaks when a company holds digital assets in a regular wallet with one key holder?
- What happens when a crypto exchange or wallet provider expands into the EU without CASP registration and supporting controls?
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 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org