MFA creates more friction than value when it is applied uniformly to every login without regard to context. If the user is on a recognised device, in a normal location, and performing a low-risk action, blanket challenges can increase abandonment without materially improving security. Risk-based branching is the better control.
Why This Matters for Security Teams
Consumer MFA decisions are not just a usability problem. They directly shape sign-in completion, account recovery demand, and fraud exposure. When MFA is forced on every login, even for recognised devices and low-risk actions, customers often treat the control as noise rather than protection. Current guidance suggests the real question is not whether MFA is good, but when it adds enough assurance to justify interruption.
That distinction matters because consumer identity is a high-volume environment with uneven risk. Static challenge rules cannot reliably tell the difference between routine logins and suspicious access. NIST Cybersecurity Framework 2.0 emphasises outcome-driven controls and adaptive response, which is why NIST Cybersecurity Framework 2.0 is a better fit than blanket enforcement. NHI Management Group’s research also shows how identity risk concentrates where controls are poorly targeted, with the 52 NHI Breaches Analysis illustrating how overexposed credentials can remain exploitable long after the original event.
In practice, many security teams encounter MFA abandonment and support escalation only after customer conversion has already dropped, rather than through intentional control design.
How It Works in Practice
The practical answer is risk-based authentication. Instead of challenging every user equally, the identity system evaluates context at sign-in and during sensitive actions. Typical signals include device familiarity, IP reputation, geo-velocity, session age, transaction value, and whether the action involves payout, profile change, credential reset, or new payee setup. If the risk score is low, access can proceed silently. If the risk score rises, step-up MFA is triggered.
This is not a universal standard yet, and implementation details vary by platform, but the operational pattern is consistent: reduce friction for routine sessions, reserve challenge for uncertainty. For consumer apps, that often means moving MFA from login to transaction step-up, or to recovery and enrolment workflows where the security value is highest. The Ultimate Guide to NHIs is focused on non-human identity, but its core lesson on lifecycle control still applies: the value of a control depends on where it is applied and how it is governed.
- Use remembered device or risk-based allowlisting for low-risk sessions.
- Require step-up MFA for account recovery, password changes, payment changes, and new device enrolment.
- Shorten session lifetimes only for higher-risk cohorts rather than forcing universal prompts.
- Log challenge outcomes so you can measure abandonment, fraud prevention, and false positives together.
For implementation guidance, the CISA guidance on risk-based controls aligns with this approach, and NIST’s identity guidance supports contextual decision-making rather than fixed friction. These controls tend to break down in shared-device consumer flows because device reputation becomes unreliable and session context changes too quickly to trust silently.
Common Variations and Edge Cases
Tighter MFA often increases abandonment, support cost, and recovery friction, requiring organisations to balance fraud reduction against customer drop-off. That tradeoff is especially visible in consumer banking, marketplace checkout, and subscription products where a single extra prompt can interrupt revenue-generating activity.
There is no universal standard for this yet, but current guidance suggests a few common exceptions. High-risk actions should still trigger MFA even when the initial login is low-risk. Newly created accounts often deserve stricter checks because trust has not been established. Likewise, step-up challenges may be justified after device changes, password resets, impossible travel, or repeated failed attempts. The point is not to remove MFA, but to place it where the assurance gain is highest.
Two practical pitfalls recur. First, teams sometimes rely on device cookies or “trusted browser” signals for too long, which weakens protection when browsers are shared or compromised. Second, overly aggressive risk engines can create false positives that punish legitimate users more than attackers. The best programs monitor both security events and customer friction metrics, then tune policies accordingly. That is the same reason Top 10 NHI Issues remains relevant across identity domains: poor lifecycle decisions usually become visible only after the control has already failed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and authentication should match the risk of the consumer action. |
| NIST SP 800-63 | AAL2 | AAL guidance helps determine when MFA meaningfully improves assurance. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Overly static credential policies can create weak, reusable access paths. |
Apply risk-based authentication so step-up MFA is reserved for higher-risk sessions and transactions.