The organisation remains accountable for the trust decision even when it uses a certified wallet. Certifications from standards bodies can reduce uncertainty, but they do not replace local governance. Teams still need policies for acceptable assurance levels, accepted issuers, attribute minimisation, interoperability, and when a wallet is sufficient versus when stronger verification is required.
Why This Matters for Security Teams
Certified identity wallets can improve trust signals, but they do not remove accountability from the relying organisation. The decision to accept a wallet, a credential type, or a presented attribute is still a local risk decision. That matters because access decisions often determine whether an agent, employee, or partner can reach sensitive systems, and the wrong acceptance policy can create silent over-permissioning.
Security teams should treat certification as one input to governance, not a substitute for it. A wallet may be standards-compliant yet still present attributes that are too broad, too stale, or issued by an unacceptable authority for a particular use case. This is the same governance gap seen in NHI programs where trust in a credential format gets confused with trust in the identity itself. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a reminder that accepted credentials still need explicit boundary-setting and review. Current guidance from the OWASP Non-Human Identity Top 10 aligns with this: trust must be enforced through policy, not assumed from packaging.
In practice, many security teams encounter trust failures only after a wallet is already being used broadly across applications, rather than through intentional acceptance criteria.
How It Works in Practice
Accountability stays with the relying party because certification only establishes that a wallet, issuer, or component met a defined assurance profile at a point in time. The organisation still has to decide what “good enough” means for each access path. That includes which issuers are accepted, what assurance level is required, which claims are minimised or excluded, and when a wallet is sufficient versus when a stronger verification step is needed.
Practical governance usually starts with a trust framework that maps business risk to wallet acceptance rules. Teams then define policy for attribute selection, issuer allowlists, revocation checks, and fallback verification when context changes. For example, a low-risk application may accept a certified wallet plus a minimal set of claims, while a privileged or regulated workflow may require additional proof, step-up controls, or human approval. This is consistent with NIST control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats identity and access as an enterprise responsibility rather than a vendor guarantee.
In NHI terms, the wallet functions like a trust-bearing credential container, but the organisation remains responsible for the lifecycle around it: validation, revocation response, auditability, and periodic policy review. That is why wallet trust should be integrated with identity governance, least privilege, and application-specific authorization. It also helps to anchor the policy in broader NHI lessons from the 52 NHI Breaches Analysis, where failure often came from misplaced trust in identities and credentials that were not continuously governed.
These controls tend to break down in federated ecosystems where multiple issuers, rapidly changing claims, and inconsistent revocation data make real-time trust evaluation unreliable.
Common Variations and Edge Cases
Tighter wallet acceptance rules often increase operational overhead, requiring organisations to balance user experience against assurance. That tradeoff becomes sharper when wallets are used across partners, jurisdictions, or high-friction workflows.
There is no universal standard for when a certified wallet alone is sufficient. Current guidance suggests organisations should distinguish between authentication and authorization: a wallet may prove possession and some attributes, but it does not automatically justify access to every resource. For low-risk use cases, a certified wallet may be acceptable with minimal claims. For high-risk access, the organisation may need stronger identity proofing, step-up verification, or additional contextual signals such as device posture or session risk.
- Accepted issuer policies should be explicit, versioned, and reviewed.
- Attribute minimisation should be mandatory where business purpose can be met with fewer claims.
- Revocation and expiration handling should be tested, not just documented.
- Exceptional access paths should exist for degraded wallet ecosystems or interoperability gaps.
For teams building governance around many credential types, NHIMG’s Top 10 NHI Issues is a useful reminder that trust failures usually come from policy gaps, not from certificates alone. The practical rule is simple: certification can reduce due diligence, but it cannot transfer accountability. The relying organisation still owns the access decision, the risk threshold, and the consequences when trust is misplaced.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Wallet acceptance is an identity trust decision that needs explicit governance. |
| NIST CSF 2.0 | PR.AC-1 | Access decisions still depend on verified identity and authorization governance. |
| NIST SP 800-53 Rev 5 | IA-2 | Identity proofing and authentication controls still apply when wallets are certified. |
| NIST AI RMF | Risk governance is needed when trusted credentials influence automated decisions. | |
| CSA MAESTRO | Federated wallet trust must be governed across issuers, policies, and runtime decisions. |
Define which wallets, issuers, and claims are accepted before any access decision is made.
