Identity teams should shift from one-time verification to persistent authentication across the customer journey. That means combining strong identity proofing, cryptographic possession signals, and risk-based controls that adapt to context. The goal is to stop fraud attempts early while preserving a fast user experience, especially in high-value digital asset flows where attackers exploit weak handoffs and static trust decisions.
How to reduce fraud without turning onboarding into a bottleneck
The practical move is to stop treating customer identity as a one-time gate and instead treat it as a continuous control surface. In fraud-heavy crypto flows, the highest-value checks are the ones that happen at enrollment, at recovery, at payout, and when transaction behavior changes. That lets teams raise assurance only when the risk justifies it, which is how you preserve conversion while reducing attack success.
The cleanest design is layered, not singular. Strong proofing should establish who the customer is, then cryptographic possession and step-up signals should confirm the same customer is still in control later in the journey. Persistent authentication also helps teams avoid overloading the first session with every possible control, which is where friction usually becomes visible to legitimate users.
For teams that want a deeper operating model, NHIMG’s Identity Fraud Prevention Guide is useful because it ties fraud patterns to the full customer lifecycle rather than to a single onboarding event.
Where friction should be added, and where it should be deferred
Not every interaction deserves the same assurance. A low-value login, a balance check, and a high-value withdrawal are not equivalent trust events, so applying one static policy to all three creates either too much friction or too much risk. The better pattern is to reserve the strongest controls for moments where money movement, recovery, address changes, or device and geography shifts materially change the fraud profile.
That is why context matters more than raw challenge count. Risk-based controls should read the session, the device, the transaction path, and the recent account history, then decide whether a passive check is enough or whether the customer needs a stronger step-up. When done well, customers see fewer unnecessary prompts, while fraud attempts face more resistance at the exact point where attackers need momentum.
Teams should also separate first-party trust from recovery trust. Recovery flows are often the easiest place for fraud to win, because attackers do not need to defeat the strongest login factor if they can hijack the reset path. This is one reason authentication, recovery, and transaction authorization should not be designed as one shared control.
For customer-facing authentication design, NHIMG’s Customer IAM (CIAM) Guide is a strong reference point for step-up authentication, passkeys, and recovery abuse patterns that directly affect friction.
Crypto teams that are also tightening onboarding and verification can use NHIMG’s Identity Proofing and KYC Guide to align document checks, liveness, and assurance level decisions with the customer journey instead of treating them as isolated compliance tasks.
What good persistent authentication looks like in practice
Persistent authentication works best when it combines at least three things: a reliable initial identity signal, a possession signal that is hard to clone or replay, and behavior-aware controls that can step up only when the session changes in suspicious ways. In digital asset environments, that usually means the customer should not be re-verified from scratch every time, but they also should not be allowed to carry forward blind trust indefinitely.
A useful operating rule is to make the default experience smooth, then let higher assurance appear only when the account context changes. That keeps routine activity fast, while creating sharper controls around withdrawals, beneficiary changes, device resets, SIM-swap-like account recovery patterns, and unusual API or automation behavior. It also reduces the incentive for attackers to focus on a single weak point, because trust is no longer a permanent state.
Teams should also measure whether their controls are actually reducing fraud attempts versus simply shifting them to a different stage. If legitimate users are seeing more abandonment at verification but fraud losses are unchanged, the program has merely moved the burden without improving security. The right result is lower fraud conversion with stable or improved completion rates for trusted users.
For teams that need a broader view of lifecycle risk, NHIMG’s NHI Lifecycle Management Guide is a useful model for thinking about enrollment, rotation, and offboarding as continuous control points rather than one-time events.
Risk and Threat Considerations
Crypto fraud often succeeds when a team relies on a single moment of trust and then lets that trust persist too long. That creates exposure in onboarding, recovery, and withdrawal flows, especially when attackers can replay stolen credentials, intercept recovery, or abuse weak step-up rules to move from a low-risk interaction into a high-value transaction.
Failure mechanism: Static trust decisions, weak recovery paths, and over-broad session persistence let an attacker inherit a legitimate customer state without needing to defeat every control in sequence.
Impact: The result is account takeover, unauthorized transfers, avoidable false positives for good customers, and a fraud control stack that looks strict while still failing at the exact point of monetary loss.
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 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL3 — Authenticator Assurance Level 3 | Persistent, phishing-resistant customer auth needs high-assurance verification for high-value crypto actions. |
| Recommendation — Use phishing-resistant authenticators for high-risk customer actions and recovery. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Crypto fraud reduction depends on issuing, rotating, and protecting customer authenticators and possession signals. |
| Recommendation — Manage authenticators with rotation, revocation, and lifecycle controls. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Risk-based customer authentication often relies on modern federated auth flows and step-up decisions. |
| V6 — Authentication | The question centers on balancing stronger authentication with low-friction customer journeys. | |
| Recommendation — Apply strong OAuth and OIDC patterns for step-up and session assurance. Harden authentication while minimizing unnecessary customer prompts. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Crypto fraud frequently exploits weak or replayable authentication in customer and API flows. |
| Recommendation — Harden API authentication and remove replayable session paths. | ||
Practitioner Guidance
What to prioritize: Put the strongest controls around recovery, payout, and beneficiary change paths first. Those are usually the lowest-friction places to catch fraud that would otherwise bypass a clean login.
Decision rule: If the action can move funds, alter recovery, or widen access, require a stronger possession check or step-up decision; if it is a routine, low-risk customer action, keep the path lightweight and monitor context instead of forcing re-verification.
What to verify: Confirm that step-up requests are tied to transaction risk, not just generic login policy. Good control design should show fewer prompts for ordinary activity and more challenge precisely where losses concentrate.
Practitioner takeaway: The best fraud reduction strategy is not heavier onboarding, it is smarter trust persistence, where assurance stays continuous, risk-adaptive, and hardest to bypass at the points that matter most.
Related resources from NHI Mgmt Group
- How should banks use identity verification to reduce AI-driven fraud without adding too much customer friction?
- How should fraud teams use behavioural signals without adding too much customer friction?
- How should banks and digital businesses reduce fraud without adding too much customer friction?
- How should organisations combine AI and traditional controls to reduce fraud without adding too much customer friction?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
