They should do both in sequence, but fraud resilience must come first where remote onboarding is already exposed to synthetic identity and deepfake abuse. Wallet readiness matters for interoperability and future acceptance, but a wallet does not by itself prove that the verification stack can resist manipulation.
Why fraud controls should lead the sequence
When remote onboarding is already exposed to synthetic identity and deepfake abuse, the first question is whether the verification stack can resist manipulation, not whether the organisation can issue a wallet later. Fraud controls establish that the person, device, or credential flow is trustworthy before any reusable identity artifact becomes part of the acceptance model.
A wallet is valuable for portability and future interoperability, but it does not by itself strengthen the front door. If the onboarding journey can be spoofed, a wallet can simply become a cleaner wrapper around bad evidence unless the fraud layer is already hardened.
Teams should therefore treat fraud controls as the gating capability and wallet readiness as the enabling capability that follows. The sequencing matters because the wrong order can create a false sense of modernisation while the underlying verification process remains easy to manipulate.
What wallet readiness actually changes
Wallet readiness is about whether the organisation can accept, issue, or consume reusable identity credentials without breaking trust, privacy, or interoperability. That usually involves support for standards, assurance rules, selective disclosure, and a relying-party design that can interpret credential data reliably.
For practitioners, the useful distinction is between a wallet that can exchange data and a verification stack that can withstand adversarial presentation. The latter is what determines whether onboarding decisions remain valid under synthetic identity, camera injection, document tampering, and similar abuse patterns.
In other words, wallet readiness reduces future integration friction, but it does not remove the need to validate the quality of the identity proofing flow itself. If the acceptance logic is weak, a wallet may simply make weak trust easier to reuse across channels.
Where identity teams should draw the line between readiness and acceptance
The right operating model is to make wallet support a planned capability while keeping fraud-resistant onboarding as an immediate control objective. That means deciding what must be true before a wallet credential is trusted, what signals still need independent verification, and where step-up checks or manual review remain necessary.
Identity teams also need to distinguish interoperability work from trust work. Interoperability answers whether the wallet can be consumed; trust answers whether the presented credential should be accepted for this use case. Those are related, but they are not the same control.
For this reason, it is sensible to align wallet acceptance with an assurance policy, not with a rollout timeline alone. The wallet path should inherit the same fraud thresholds, exception handling, and evidence standards that govern other remote onboarding channels.
Risk and Threat Considerations
Fraud exposure is the immediate concern because synthetic identities and deepfake-enabled presentation attacks target the weakest part of the onboarding chain, which is usually the evidence-gathering stage. If that stage is brittle, downstream wallet adoption can amplify the damage by reusing a compromised identity across more relying parties and more transactions.
Failure mechanism: Attackers exploit weak document checks, liveness flaws, or over-trusting acceptance logic to create identities that appear legitimate at onboarding and remain credible after issuance.
Impact: The organisation can admit fraudulent users, propagate bad identity data into later wallet-based flows, and increase the blast radius of a single compromised verification decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST SP 800-63 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Wallet acceptance can fail when trust and verification settings are misconfigured. |
| Recommendation — Harden verification settings so wallet-based acceptance cannot weaken onboarding trust. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Remote proofing, assurance and binding are central to deciding when wallet credentials can be trusted. |
| Recommendation — Apply assurance and proofing guidance before accepting wallet-based identities. | ||
| CIS Controls v8 | 5 — Account Management | The topic centers on trustworthy identity onboarding and lifecycle decisions before acceptance. |
| Recommendation — Validate account and identity onboarding controls before rolling out wallet acceptance. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Wallet readiness and fraud controls both hinge on how humans use reusable identity artifacts in practice. |
| Recommendation — Prevent users from bypassing verification by treating wallet use as an acceptance control. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Acceptance of reusable identity credentials depends on controlled access decisions and trust boundaries. |
| Recommendation — Define access acceptance rules for wallet-presented identity before enabling reuse. | ||
Practitioner Guidance
What to prioritise: Start by hardening the onboarding journey against synthetic identity, presentation attacks, and deepfake abuse, then layer wallet acceptance once you can explain which evidence is trusted and why. That ordering is especially important for remote channels where face capture, document checks, and remote proofing are already a known attack surface.
What to verify: Confirm that the wallet path does not bypass the controls used to detect manipulated identity evidence. If a wallet is used as an input, verify the issuer, assurance level, and the policy for when additional checks still apply.
Practitioner takeaway: Wallet readiness is a distribution and interoperability problem, but fraud resistance is a trust problem, and trust must be solved first when the onboarding channel is already under active manipulation.
Related resources from NHI Mgmt Group
- Should customer identity teams use fraud trends to prioritise controls?
- How should teams prioritise fraud controls when identity risk spans onboarding and login?
- How should identity teams evaluate mobile wallet adoption without weakening fraud controls?
- How should security teams balance frictionless sign-in with stronger fraud controls in mobile-first identity journeys?