How should businesses reduce identity fraud without relying on passwords and SMS codes alone?

Why passwordless identity checks reduce fraud more effectively than SMS alone

Passwords and SMS codes fail for different reasons, but both are weak as sole safeguards against identity fraud. Passwords are reused, guessed, phished, or reset through social engineering, while SMS one-time codes can be intercepted, forwarded, or defeated through SIM swap and account recovery abuse. Stronger identity proofing and layered authentication reduce the chance that a fraudulent enrolment or takeover succeeds in the first place, especially when a business has remote sign-up, self-service recovery, or high-value account actions. For a control perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it ties identity assurance to broader access, logging, and recovery controls rather than treating authentication as a single point solution. In practice, many security teams discover the weakness only after a recovery channel, enrolment flow, or helpdesk process has already been abused.

How layered identity controls work across enrolment, login, and recovery

A resilient fraud-reduction design separates three decisions: who may enrol, who may authenticate, and who may recover access. That matters because an attacker does not always need to defeat login if they can create a synthetic identity, hijack a recovery path, or exploit weak step-up checks later in the lifecycle. Businesses should treat identity proofing, authentication strength, and recovery friction as related but distinct controls.

• At enrolment, use document verification, face matching, and liveness checks to raise the cost of fake accounts and impersonation.

• At login, prefer phishing-resistant methods such as hardware or software-backed tokens and passwordless authentication rather than reusable secrets.

• At recovery, require stronger proof than normal access, because reset flows are a common bypass route.

• For higher-risk actions, apply step-up verification, risk scoring, and cooling-off periods so a newly compromised identity cannot immediately perform damaging actions.

This works best when the business also monitors for signals such as device change, impossible travel, mismatched identity attributes, and repeated failed proofing attempts. Those signals help distinguish a genuine user struggle from coordinated fraud. The control breaks down when organisations rely on one strong factor but leave recovery, support, or exception handling weak, because attackers usually look for the least protected path rather than the strongest one.

Where fraud controls need extra care: recovery, exceptions, and high-value actions

Tighter identity checks often reduce fraud, but they also increase friction, which means organisations must balance user experience against assurance. That tradeoff becomes most visible in customer onboarding, account recovery, and support-led overrides, where overly rigid rules can block legitimate users while overly loose rules create easy bypasses.

One common edge case is that a business may have strong passwordless login yet still expose itself through call-centre resets, manual document review shortcuts, or inconsistent step-up requirements across channels. Another is that fraud controls can behave differently at scale: a threshold that works for low-volume consumer onboarding may become noisy or expensive when applied to large enterprise populations or high-velocity sign-ups. Industry practice is still converging on how much friction is appropriate for each risk tier, so the safest approach is to align assurance level with the consequence of failure rather than applying one rule everywhere.

Identity fraud controls also need to account for account lifetime, not just first login. A newly verified identity may still warrant a cooling-off period before changing payment details, adding beneficiaries, or raising limits, because those actions are attractive targets after compromise. The strongest programmes treat fraud reduction as a lifecycle problem, not a point-in-time check.

Practitioner Guidance

What to prioritise: Protect the weakest path first, which is often recovery and support, not the login screen. If a business has strong enrolment but weak helpdesk verification, the fraud problem simply moves downstream.

What to verify: Confirm that proofing strength, authentication strength, and recovery strength are intentionally different and risk-based. A genuine control improvement should make it harder to create, take over, or reset an identity, not just harder to type a password.

What practitioners underestimate: SMS usually fails as a single factor because it is vulnerable to telecom and account-recovery abuse, but the larger mistake is assuming any one control can solve both identity proofing and ongoing authentication. Businesses reduce fraud most effectively when they design for the full identity lifecycle, not a single checkpoint.

Risk and Threat Considerations

The material risk is identity fraud through enrolment abuse, account takeover, or recovery-path compromise. If businesses depend on passwords and SMS codes alone, they leave a narrow trust model that is attractive to phishers, social engineers, and SIM-swap style abuse.

Failure mechanism: Attackers commonly exploit credential reuse, password reset weakness, intercepted OTPs, or weak support verification to gain control without defeating stronger primary authentication. Fraud also emerges when fake identities pass onboarding checks and later exploit trust already granted by the system.

Impact: The result can be fraudulent account creation, unauthorised access, payment diversion, support fraud, reputational damage, and control loss over downstream actions such as transfers, profile changes, or beneficiary updates.

Related resources from NHI Mgmt Group

• Why do passkeys reduce fraud better than passwords or SMS codes?
• How can fraud and identity teams reduce automation risk without relying on static puzzles?
• How should security teams reduce identity risk when MFA still relies on passwords and SMS codes?
• How should security teams reduce phishing, vishing, and smishing risk without relying only on passwords or one-time codes?