Subscribe to the Non-Human & AI Identity Journal

Who should be accountable for identity assurance in digital wallet models?

Accountability should sit with the programme owners who decide what attributes are shared, how long they persist, and which assurance standards apply. Wallet models do not remove governance, they shift it to data minimisation, anti-spoofing validation, relying-party trust, and recovery controls. That makes identity assurance a cross-functional security and privacy responsibility.

Why This Matters for Security Teams

Digital wallet models do not eliminate identity assurance obligations; they redistribute them across programme owners, relying parties, and the teams that define what gets asserted, when it expires, and how it is recovered. That matters because assurance is only as strong as the weakest linkage between issuer, wallet, verifier, and recovery path. NIST SP 800-63 digital identity Guidelines frames this as a trust and lifecycle problem, not just an authentication event, and the same logic shows up across NHI governance when identity material is over-shared or left too durable.

For security teams, the real issue is governance drift. If no one owns attribute minimisation, anti-spoofing validation, and revocation testing, the wallet becomes a delivery mechanism for stale or over-trusted claims. NHIMG research shows how often identity material lingers in unsafe states: in the Ultimate Guide to NHIs, 79% of organisations report secrets leaks and 97% of NHIs carry excessive privileges. Those patterns are a warning for wallet programmes too, because assurance failures usually appear first as trust gaps, not obvious compromise. In practice, many security teams encounter wallet assurance failures only after a relying party has accepted an unfit credential, rather than through intentional governance review.

How It Works in Practice

Accountability should be assigned to the business or programme owner who chooses the assurance profile and the attributes to be shared, while security and privacy teams validate the control design and the implementation. Current guidance suggests treating wallet assurance as a lifecycle control set: issuance, presentation, verification, refresh, suspension, and recovery all need named owners and documented decision criteria. NIST’s Digital Identity Guidelines are useful here because they separate identity proofing, authenticator assurance, and federation trust into distinct functions.

Operationally, that means:

  • Define which attributes are mandatory, optional, or prohibited for each relying party.
  • Set maximum age and revalidation rules for stored claims and credentials.
  • Require anti-spoofing and cryptographic verification of wallet presentations.
  • Document recovery and revocation paths for lost devices, compromised wallets, and stale claims.
  • Test whether relying parties actually reject expired or downgraded assurance.

For NHI teams, this maps cleanly to control discipline already used for secrets and service identities. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same lesson: trust fails when identities are assumed durable after the original assurance context has changed. These controls tend to break down when wallet ecosystems span multiple issuers and relying parties because policy drift makes assurance rules inconsistent at the point of verification.

Common Variations and Edge Cases

Tighter assurance often increases friction, requiring organisations to balance user convenience against fraud resistance and recovery overhead. That tradeoff is especially visible in wallet models used across regulated sectors, cross-border services, or high-value transactions, where there is no universal standard for exactly which assurance level must be reused versus re-verified. Best practice is evolving, but one principle is stable: the party that decides trust should also own the residual risk when trust is misplaced.

Edge cases usually involve delegated wallets, shared devices, and recovery after loss or compromise. In those scenarios, accountability may be split across the issuer, the wallet operator, and the relying party, but the programme owner still owns the policy decision and the acceptance criteria. Where assurance depends on third-party attestations, the owner must validate revocation handling, fraud response, and data minimisation before launch. That is why wallet assurance cannot be treated as a one-time procurement decision. It is an ongoing governance control, much like NHI lifecycle management, where the control owner must continuously verify that access, proof, and revocation still match the intended trust model.

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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-63 Defines identity assurance, proofing, and federation trust responsibilities.
NIST CSF 2.0 GV.OV-01 Governance oversight is central to wallet assurance accountability.
OWASP Non-Human Identity Top 10 NHI-01 Wallet trust failures mirror weak identity lifecycle and overprivileged credential issues.

Treat wallet claims like sensitive identity assets and enforce lifecycle, minimisation, and revocation controls.