Poorly implemented MFA can frustrate recognised users, which creates churn pressure and can push people to abandon the control entirely. When customers repeatedly face unnecessary prompts, especially on trusted devices, the login experience degrades. That creates a security paradox: the control meant to reduce risk can drive weaker user behaviour, while also harming retention and customer lifetime value.
Why friction turns MFA from safeguard into a customer-experience problem
Poorly implemented MFA adds steps at the exact moment customers expect speed and certainty. If the system cannot reliably recognise returning users, it forces repeat challenges, device re-verification, or unnecessary step-up prompts. That creates abandonment pressure, support burden, and confusion about which login attempts are legitimate.
From a fraud perspective, inconsistent MFA can also train users to accept abnormal prompts or approve logins they do not fully understand. When the control is noisy, people become less able to distinguish genuine verification from an attacker’s attempt to social-engineer access.
Returning customers are the most sensitive test case because the control should adapt to known devices, established behaviour, and lower-risk sessions. If it does not, the business pays twice: legitimate users are slowed down, and fraudster-friendly habits become more likely.
Where friction and fraud risk come from in practice
The main failure mode is not “MFA exists,” but “MFA is applied without context.” Common causes include prompting on every login, ignoring device trust signals, failing to persist session confidence, and using challenge methods that are difficult to complete under real customer conditions. The result is a control that behaves like a hurdle instead of a risk-based check.
That matters because login friction changes user behaviour. Some customers retry until they succeed, some contact support, and some stop using the account altogether. Others begin to approve prompts reflexively, which weakens the very assurance MFA is supposed to provide. The more often a system asks for proof, the more likely users are to treat proof as routine rather than meaningful.
Well-implemented MFA should still resist account takeover. The problem is that repeated false friction can make legitimate users easier to manipulate. An attacker does not need to defeat the control if the control has already taught the user to expect interruptions and click through them.
Risk and Threat Considerations
Poor MFA design can raise both operational and fraud risk at the same time. Excessive prompts increase abandonment and support load, while noisy or poorly explained challenges create the conditions for prompt fatigue, false approval, and social-engineering success.
Failure mechanism: The control is triggered too often, lacks reliable recognition of trusted sessions, or uses inconsistent step-up logic, so legitimate users are repeatedly forced to prove themselves and begin to normalise or bypass the challenge.
Impact: Customers churn, conversion drops, support costs rise, and attackers gain more room to exploit user confusion, fatigue, or habitual approval behaviour during account takeover attempts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL — Authenticator Assurance and Digital Identity Guidance | Sets assurance expectations for login steps and phishing-resistant MFA. |
| Recommendation — Use assurance levels and phishing-resistant authenticators to reduce unnecessary prompts for returning users. | ||
| CIS Controls v8 | 6 — Access Control Management | Addresses account access, least privilege, and control of login pathways. |
| Recommendation — Tune access controls so repeated verification only occurs when session risk justifies it. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | Covers authentication design and access decisions that shape user friction. |
| PR.AC — Access Control | Applies to enforcing appropriate access without over-challenging known users. | |
| Recommendation — Align authentication with risk-based access decisions to preserve security and usability. Apply access control logic that distinguishes trusted returning sessions from higher-risk logins. | ||
Practitioner Guidance
What to prioritise: Treat returning-customer MFA as a risk-based access experience, not a fixed hurdle. The control should adapt to session confidence, device familiarity, and behavioural consistency so that genuine low-risk logins are not challenged as often as high-risk ones.
What to verify: Check whether the login flow can distinguish first-time access, a new device, a risky network, and a normal return visit. If those states all receive the same challenge, the MFA design is probably driving unnecessary friction and training users into blind approval.
Common mistake: Teams often measure MFA only by enrollment or challenge volume. For this question, the more useful signals are repeat login failures, help-desk contacts, abandonment after step-up, and the share of prompts generated for known-good returning users.
Practitioner takeaway: MFA should raise assurance without teaching customers to expect noise; once the control becomes routine interruption, both user trust and fraud resistance start to degrade.
Related resources from NHI Mgmt Group
- How should security teams reduce phishing risk in MFA without creating more user friction?
- Why do poorly governed NHIs increase lateral movement risk?
- Why do conflicting access rights increase fraud risk more than broad access alone?
- Why does weak segregation of duties increase fraud and compliance risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
