A digital identity wallet that uses passkeys to authenticate the user, unlock stored credentials, and sign credential presentations. The security model shifts from shared secrets to device-bound cryptographic proof, which improves phishing resistance but increases the importance of key governance and recovery design.
Expanded Definition
A passkey-enabled wallet is a digital identity wallet that uses passkeys as the primary authenticator for unlocking the wallet and authorising credential presentation. In practice, the wallet relies on device-bound cryptographic proof rather than shared secrets, reducing phishing exposure and removing password reuse from the access path. The model aligns with modern passwordless identity guidance such as the NIST Cybersecurity Framework 2.0, but definitions vary across vendors because some products treat the passkey only as wallet login, while others use it for step-up approval, recovery, and transaction signing.
That distinction matters in NHI and agentic workflows because a wallet may store multiple credentials, proofs, or delegated tokens, each with different assurance and recovery requirements. A passkey can protect access to the wallet itself, yet it does not automatically secure the lifecycle of the assets held inside it. Organisations should therefore separate authentication strength from credential governance, especially when the wallet is used to present identities to relying parties or to trigger downstream automation. The most common misapplication is treating passkey login as a complete wallet security solution, which occurs when teams ignore recovery, device loss, and trusted-device enrollment controls.
Examples and Use Cases
Implementing a passkey-enabled wallet rigorously often introduces recovery and device-management overhead, requiring organisations to weigh phishing resistance against help desk complexity and account restoration risk.
- An employee unlocks a wallet on a managed device with a passkey and presents a verifiable credential to a portal without ever entering a password.
- A contractor uses the wallet to approve a higher-risk authentication event, where the passkey acts as a step-up control for credential release.
- A mobile identity wallet stores multiple credentials and uses a passkey to gate access to each presentation request, supporting privacy-preserving selective disclosure.
- An organisation that tracks service and identity sprawl applies lessons from the Ultimate Guide to NHIs to ensure wallet recovery does not become an unmanaged backdoor.
- A product team follows passwordless assurance patterns from NIST Cybersecurity Framework 2.0 while deciding whether the wallet can be used for login, signing, or both.
In mature deployments, the wallet must also define what happens when a device is replaced, biometrics fail, or a user is migrated to a new trust boundary. Those edge cases are where security design is either validated or exposed.
Why It Matters in NHI Security
Passkey-enabled wallets matter because they shift risk away from reusable secrets and toward key governance, trust enrollment, and recovery design. For NHI programs, that is a significant improvement when compared with API keys, shared tokens, or password-based delegated access. It also reduces the chance that a phishing event yields a portable secret that can be reused across environments. The same principle is reflected in NHIMG research, where Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.
However, the wallet can become a governance blind spot if teams assume the authenticator alone solves the lifecycle problem. Recovery links, device enrollment, and delegated presentation rights must be controlled with the same discipline applied to privileged access and secrets management. In environments using autonomous agents, a compromised wallet may also authorise presentations or approvals that appear legitimate unless there is strong attestation and policy enforcement. The lesson is not that passkeys are weak, but that they are only one control in a broader identity fabric. Organisations typically encounter the operational cost of weak wallet governance only after a lost device, recovery abuse, or failed audit, at which point the term becomes operationally unavoidable to address.
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 Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-63, NIST Zero Trust (SP 800-207) 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-01 | Covers identity credential misuse and wallet-style access paths for non-human identities. |
| NIST SP 800-63 | AAL2 | Passkeys map to strong authenticator assurance for phishing-resistant authentication. |
| NIST Zero Trust (SP 800-207) | ID | Zero Trust requires verified identity and continuous trust decisions for wallet access. |
| NIST CSF 2.0 | PR.AC-1 | Identity and credential management underpins secure authentication and authorization. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems need strong control over delegated actions and authentication handoffs. |
Treat passkey wallets as governed NHI authenticators and enforce lifecycle controls around enrollment, use, and revocation.
