Passkeys prove control of the authenticator, while verifiable credentials prove something about the person or subject. The two are complementary when the wallet preserves selective disclosure and the identity programme separates proof of possession from proof of attributes.
Why This Matters for Security Teams
Passkeys and verifiable credentials solve different problems, but many identity programmes try to collapse them into a single control story. Passkeys are about strong, phishing-resistant authentication and device-bound proof of possession. Verifiable credentials are about portable, cryptographically signed claims that can be selectively disclosed. That distinction matters when organisations need to prove both who is holding the authenticator and what attributes they are entitled to assert.
The practical risk is design confusion. If a team treats a passkey as a full identity assertion, it can over-grant access. If it treats a verifiable credential as sufficient proof of login, it can weaken authentication. Current guidance from NIST SP 800-63 Digital Identity Guidelines supports separating authentication from attribute assertion, which is why wallet architecture and issuance policy need to be designed together. NHIMG’s Ultimate Guide to NHIs – Static vs Dynamic Secrets also underscores how static assumptions about identity become brittle once proof and privilege are decoupled.
In practice, many security teams discover the weakness only after a wallet, credential, or recovery flow has already been abused, rather than through intentional identity-boundary design.
How It Works in Practice
In a workable architecture, the passkey authenticates the user to a relying party or wallet provider, while the wallet presents a verifiable credential only when a specific attribute is needed. For example, a passkey can establish that the holder controls a registered authenticator, and a credential can then prove that the same holder is an employee, over a certain age, or licensed for a regulated action. The key operational principle is that the wallet should disclose the minimum necessary claim, not the full identity packet.
This separation becomes easier to manage when the identity programme treats the wallet as a presentation layer rather than the source of truth. Issuers should sign credentials with tightly scoped subjects, short validity where appropriate, and revocation checks that match the business use case. The wallet should support selective disclosure and, where applicable, pairwise identifiers so the relying party does not receive more linkable data than needed. For implementation discipline, teams often map authentication policy to OWASP Non-Human Identity Top 10 style identity hygiene and adapt the same rigor to digital wallets and credentials.
- Use the passkey for strong authentication and anti-phishing control.
- Use the credential for specific, verifiable attributes, not broad account takeover authority.
- Keep issuance, presentation, and revocation responsibilities separate.
- Prefer selective disclosure and minimal attribute release over full-profile presentation.
- Align wallet recovery, device binding, and credential refresh with documented assurance levels.
NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because credential ecosystems often fail when recovery paths, backup tokens, and trust anchors multiply without governance. These controls tend to break down when the wallet is allowed to act as both authenticator and attribute authority because that creates ambiguous trust decisions at the relying party.
Common Variations and Edge Cases
Tighter wallet security often increases recovery complexity, requiring organisations to balance user experience against fraud resistance. That tradeoff becomes visible in edge cases: shared devices, account recovery after phone loss, cross-border credential acceptance, and delegated access workflows. Best practice is evolving, and there is no universal standard for how much wallet portability should be allowed before assurance degrades.
One common pattern is to use passkeys for login and verifiable credentials for step-up or eligibility checks. Another is to issue credentials that can be stored in a wallet but presented through a separate identity proofing workflow. The latter is safer when attributes are highly sensitive, but it can frustrate users if the wallet is expected to behave like a universal identity container. In regulated environments, assurance mapping should also account for whether the verifier trusts the credential issuer, the wallet platform, or both.
For teams planning the architecture, the safest default is to avoid treating possession of a passkey as equivalent to entitlement to all wallet claims. NHIMG’s Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs – Static vs Dynamic Secrets both illustrate the same operational lesson: when trust is over-consolidated, failure domains expand quickly. The boundary between authentication and attribute proof must stay explicit, especially when wallets are reused across multiple services.
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 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL | Separates authentication strength from attribute assurance. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Identity proofing and credential misuse risk applies to wallet-bound claims. |
| NIST CSF 2.0 | PR.AC-1 | Access is based on authenticated identity and approved claims. |
| NIST Zero Trust (SP 800-207) | ID, PR.AC | Trust decisions should be explicit and contextual, not implicit. |
| NIST AI RMF | Risk governance applies to portable credentials and identity assertions. |
Establish governance for issuance, presentation, recovery, and revocation of credentials.
Related resources from NHI Mgmt Group
- How do organisations reduce the dwell time of exposed credentials at scale?
- How should organisations stop auto-sync from turning desktops into repositories of credentials?
- How should security teams use passkeys and digital credentials together?
- Why do digital credentials matter if passkeys already improve authentication?
