Accountability still sits with the relying party that accepts the credential and the issuer that vouches for it, but each organisation must govern its own acceptance policy and assurance thresholds. Cross-border portability does not remove responsibility. It makes policy alignment and audit evidence more important.
Why This Matters for Security Teams
Wallet-based identity changes the trust boundary, but it does not delete accountability. When a bank or fintech accepts a wallet credential, it is still responsible for the acceptance decision, the assurance threshold, and the downstream controls tied to that identity. That is why policy, evidence, and revocation handling matter as much as the credential itself. NIST CSF 2.0 frames this as an enterprise risk and governance problem, not just an authentication problem.
This is also a familiar NHI pattern: the credential may be portable, but the risk stays local to the party that relies on it. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a reminder that acceptance controls are often weaker than teams assume. In practice, many security teams discover shared accountability only after a dispute, fraud event, or audit finding has already exposed gaps in who approved what.
How It Works in Practice
Accountability in cross-organisation wallet identity usually splits into two layers. The issuer is accountable for proving the identity, binding the wallet to the subject, and maintaining the assurance of the credential lifecycle. The relying party is accountable for deciding whether that proof is enough for its own risk appetite, transaction type, and regulatory obligations. A strong model treats wallet identity as an input to policy, not as a substitute for policy.
Practitioners should separate authentication from authorisation and from business acceptance. A wallet may establish that a subject is known, but the bank still needs to decide whether that subject may open an account, move funds, access premium features, or trigger a high-value transfer. That decision should be based on contextual controls such as jurisdiction, transaction amount, fraud signals, device posture, and whether the issuer’s assurance level maps to the relying party’s internal policy. The NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations to define governance, risk ownership, and control evidence, rather than assuming a credential proves everything.
Operationally, banks and fintechs should document:
- who owns credential issuance and revocation
- what assurance level each wallet profile represents
- which transactions require step-up verification
- how disputes, fraud, and recovery events are handled
- what logs and attestations are retained for audit
That is consistent with NHI governance guidance in the Ultimate Guide to NHIs, which treats lifecycle control and visibility as core security requirements. These controls tend to break down when wallet portability crosses multiple legal jurisdictions because acceptance rules, liability models, and evidence retention requirements diverge.
Common Variations and Edge Cases
Tighter acceptance controls often increase friction, so organisations must balance customer experience against fraud loss and regulatory exposure. That tradeoff becomes sharper when wallet identity is used for both low-risk and high-risk actions, because one credential may be acceptable for login but not for funds transfer or account recovery.
There is no universal standard for this yet. Current guidance suggests aligning wallet assurance with the specific relying-party use case, rather than assuming a single cross-border trust level will satisfy all banks and fintechs. In practice, some ecosystems may accept issuer attestations at face value, while others require independent risk checks, step-up verification, or regional compliance overlays. The 52 NHI Breaches Analysis shows why that matters: when trust is overextended, the failure is often not at issuance but at over-acceptance.
The hardest edge cases are recovery, delegation, and cross-tenant reuse. If a wallet is recovered through weak procedures, or if a single wallet is reused across multiple institutions without clear subject binding, then accountability becomes blurred and incident response slows down. In those cases, the relying party still owns the decision to accept the credential, and the issuer still owns the quality of the identity proof, but neither can rely on the other to close the loop automatically.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight fit shared accountability across issuers and relying parties. |
| NIST SP 800-63 | IAL/AAL/FAL | Identity assurance levels map directly to wallet trust and acceptance thresholds. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero trust requires explicit verification and policy enforcement for each wallet use. |
Treat every wallet assertion as contextual input and verify before granting access or transaction approval.
Related resources from NHI Mgmt Group
- Who is accountable when a compromised identity is used for intrusion and exfiltration?
- Who is accountable when access is decided in real time across multiple identity types?
- Who is accountable when a compromised machine identity is used to reach sensitive systems?
- Who is accountable for reducing identity false positives across IAM and detection tools?
