TL;DR: Passkeys are moving into digital identity wallets through wwWallet, a passkey-enabled wallet project developed by Yubico and European research partners, with pilots now extending into interoperability, credential decryption, and verifiable credential presentation. The shift matters because wallet security, privacy, and cross-border trust now depend on identity controls that span human, NHI, and cryptographic credential lifecycles.
At a glance
What this is: This is a Yubico analysis of wwWallet, a passkey-enabled digital identity wallet that brings passkeys into wallet login, credential decryption, and credential presentation.
Why it matters: It matters because IAM, wallet, and cryptographic credential controls now overlap, so practitioners have to govern identity proofing, authentication, and portability together.
Context
Passkeys are now common across mobile platforms, browsers, enterprise IAM, and major cloud services, but digital identity wallets have only recently entered that same authentication pattern. wwWallet changes the boundary by making passkeys part of wallet access and credential handling rather than only account sign-in.
For IAM and digital wallet programmes, the practical issue is not whether passkeys work, but where trust is anchored when a wallet becomes both a holder and a presenter of credentials. That shifts attention toward authentication strength, credential store protection, and the governance model for interoperable identity ecosystems.
Key questions
Q: How should security teams govern passkeys when they also unlock digital identity wallets?
A: Treat wallet passkeys as high-value authenticators because they can do more than start a session. When the same credential unlocks stored identity data and signs presentations, authentication policy, key protection, and recovery governance must be designed together rather than managed as separate controls.
Q: Why do digital identity wallets change IAM assumptions about trust and recovery?
A: Wallets turn identity into a portable container that may cross services, organisations, and jurisdictions. That breaks the assumption that access is anchored in a single tenant and recovered through a single help desk process, so governance has to follow the credential and the device.
Q: What are the main control risks when verifiable credentials are stored in wallets?
A: The main risk is concentrated blast radius. If wallet access, decryption, presentation signing, and recovery are not separated, one compromise or recovery failure can affect both authentication and the integrity of the credentials being presented.
Q: When should organisations rethink their passkey programme for digital wallet use?
A: They should rethink it when passkeys move from login convenience to a mechanism for accessing and presenting regulated identity material. At that point, the programme is no longer just about replacing passwords, but about governing a cryptographic identity container.
Technical breakdown
Passkeys as wallet authenticators and decryptors
wwWallet uses passkeys in three roles: authenticating into the wallet, decrypting the credential store, and signing presentations of verifiable credentials. That means the passkey is no longer only a login factor. It becomes the root action key for accessing the wallet’s stored identity material and for proving claims to relying parties. From an identity architecture perspective, this tightens the link between authentication and data access, because successful possession of the passkey can unlock both entry and cryptographic operations. The relevant control question is therefore not just whether passkeys replace passwords, but whether the wallet’s trust boundary is built to treat passkey possession as high-value authorization.
Practical implication: Treat wallet passkeys as high-impact authenticators and review how credential storage, presentation signing, and recovery are separated.
Digital identity wallets and verifiable credential trust
A digital identity wallet is a container for credentials that can be presented to other parties under the owner’s control. In wwWallet, passkeys are part of the mechanism that lets the wallet decrypt and present those credentials securely. This matters because the wallet is not a passive store. It is an active trust boundary where identity data, cryptographic keys, and presentation policies intersect. If that boundary is weak, the result is not just account compromise but misuse of identity assertions across services, borders, and use cases. The operational challenge is to govern wallet custody, credential lifecycle, and presentation assurance as one control plane.
Practical implication: Map wallet access, credential custody, and presentation rights into the same governance model instead of treating them as separate systems.
Interoperability raises the bar for identity governance
The article places wwWallet inside EU pilot activity, cross-border mobility use cases, and WebAuthn-based work tied to eIDAS-compliant security. That combination shows why interoperability is a governance issue, not just a standards issue. Once credentials must work across organisations and jurisdictions, the relevant control set expands from local IAM policy to how trust is established, transported, and verified between relying parties. The more interoperable the wallet ecosystem becomes, the more practitioners need repeatable rules for assurance levels, device binding, recovery, and presentation integrity.
Practical implication: Define governance requirements for cross-border wallet use before interoperability becomes the default operating model.
NHI Mgmt Group analysis
Wallet passkeys collapse the old separation between authentication and credential control: The same factor that opens the wallet also protects the stored credential set and the presentation step. That means authentication policy, cryptographic key protection, and credential governance now sit in one trust chain rather than in separate layers. Practitioners should treat wallet passkeys as a control surface spanning IAM and digital credential custody.
Interoperable wallets create a new governance problem, not just a new user experience: Once a credential can move across borders and relying parties, local IAM assumptions stop being enough. The operational question becomes who defines the assurance boundary when the wallet is portable, the issuer is external, and the presentation target changes by context. Practitioners need a governance model that follows the credential, not the tenant.
eIDAS-style wallet security pushes identity teams toward cryptographic assurance as a programme requirement: The article ties passkeys, WebAuthn, and zero-knowledge work to secure wallet adoption. That points to a broader shift where identity teams must understand how cryptography, device binding, and presentation integrity affect trust outcomes. The implication is that wallet security is becoming part of identity architecture, not an optional add-on.
Digital identity wallets should be governed as high-value identity containers: The article’s model makes the wallet the place where authentication, decryption, and presentation converge. That creates a concentrated blast radius if recovery, revocation, or device loss are not well controlled. Practitioners should design wallet governance around lifecycle, recovery, and assurance rather than around sign-in alone.
Passkey-enabled wallets sharpen the need for a named control concept: wallet trust boundary governance: wwWallet shows that the trust boundary now includes entry, key use, and credential presentation in one flow. That boundary is fragile if teams still govern passkeys only as MFA replacements. The practical conclusion is that wallet adoption should be assessed as a full identity architecture change, not a single authentication upgrade.
From our research library:
- eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
What this signals
Wallet trust boundary governance: passkey adoption in wallets should be treated as a structural change to identity architecture, because the authenticator now protects storage, presentation, and sometimes recovery in one flow. Teams that keep wallet controls inside a standard sign-in model will miss the real governance boundary.
Interoperability is the hard part: the value of a wallet grows when credentials can move across borders and services, but that also means assurance, recovery, and revocation need to be consistent outside the home tenant. The programme implication is to define trust rules before interoperability scales.
Digital credentials need lifecycle thinking: once passkeys are used to open a wallet and present verifiable credentials, the relevant questions become who can recover, revoke, and re-bind that trust after device change or loss. IAM teams should align wallet controls with lifecycle governance, not treat them as a point-in-time login feature.
For practitioners
- Govern the wallet trust boundary Define the wallet as a protected identity container, with controls for authentication, decryption, presentation signing, and recovery under one policy set.
- Classify passkeys by assurance role Separate ordinary login use from passkeys that unlock credential stores or sign verifiable credential presentations, because those functions raise the assurance requirement.
- Map interoperability trust assumptions Document which relying parties, issuers, and jurisdictions are allowed to trust the wallet, and specify the assurance level each integration requires.
- Build recovery and revocation into wallet governance Ensure device loss, key reset, and credential revocation are handled as lifecycle events, not as ad hoc support cases.
Key takeaways
- Passkeys in digital identity wallets create a combined authentication and credential-custody problem that standard sign-in controls do not fully cover.
- The article’s key implication is that wallet interoperability raises governance questions about trust, recovery, and presentation integrity across boundaries.
- Identity teams should treat wallet-based passkeys as part of lifecycle governance, with recovery, revocation, and assurance designed together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Passkeys are used as the wallet authentication mechanism in this article. |
| NHI-08 — Environment Isolation | The wallet must separate login, decryption, and presentation trust boundaries. | |
| Recommendation — Apply NHI-04 to ensure wallet authentication is resistant to misuse and weak recovery paths. Use NHI-08 to isolate wallet access from broader identity and device trust assumptions. | ||
| NIST SP 800-63 | SP 800-63C — Federation | The article focuses on cross-border wallet trust and credential presentation. |
| Recommendation — Align wallet presentation and relying-party trust with federation assurance requirements. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Wallet access combines authentication with entitlement to stored credential material. |
| Recommendation — Map wallet access to PR.AA-05 so entitlement to credential use is explicitly governed. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | Interoperable wallets depend on external services and relying-party integrations. |
| Recommendation — Review wallet integrations for unsafe API consumption and trust assumptions at each boundary. | ||
Key terms
- Digital Identity Wallet: A digital identity wallet is software that stores and presents credentials for a person or organisation. It is a portability layer, not an authorization system. The wallet moves verified proof between parties, while the relying party still has to decide whether the proof is sufficient for the requested action.
- Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
- Verifiable Digital Credential: A verifiable digital credential is structured identity data that can be checked cryptographically by a relying party. Instead of relying on visual inspection, the verifier validates issuer signatures and presentation rules, which gives the control a clearer trust basis than an image-based document.
- Credential Presentation: The moment a user enters, pastes, or autofills a secret into a login form. This is the highest-value interception point in phishing scenarios because once the credential is presented to the wrong site, the attacker no longer needs to deceive the user.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 26, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org