MFA can harm experience when it forces customers into card readers, callback flows, document checks, or face-to-face visits for routine activity. Those controls may improve assurance, but they also add delay, complexity, and abandonment risk. In banking, that friction matters because access issues affect satisfaction, public rankings, and ultimately churn.
Why MFA Friction Feels Worse in Digital Banking
Digital banking is a high-frequency, high-expectation environment, so even small authentication delays feel like product failure rather than background security. MFA is often introduced into journeys that customers expect to be routine, such as checking balances, paying bills, or approving transfers, and that changes the experience from immediate access to interruption and verification. The customer does not experience the control objective; they experience the extra step, the timeout, or the blocked session.
That friction becomes more visible when the MFA method is poorly matched to the channel. A card reader, out-of-band callback, or document-based recovery path can make strong assurance look like unnecessary bureaucracy, especially when the user is already on a trusted device. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that authentication design often focuses on assurance mechanics while underestimating operational usability. In practice, banks usually learn where the experience breaks only after abandonment, call-centre load, or complaint volume has already risen.
How MFA Breaks the Banking Journey
MFA damages customer experience when it is applied as a blanket gate instead of a context-sensitive control. The underlying problem is not that stronger authentication is undesirable; it is that banks often use the same challenge for low-risk and high-risk actions, then force customers through recovery paths that are slower than the action itself. That creates a mismatch between the value of the task and the burden of proving identity.
In practice, customer frustration usually comes from four patterns. First, step-up prompts appear too often, especially after device changes, cookie loss, or short inactivity windows. Second, the method itself is awkward, such as hardware tokens, SMS codes with weak delivery reliability, or knowledge-based fallback that customers cannot complete quickly. Third, recovery is expensive, because failed MFA often pushes the user into call-centre verification or branch visits. Fourth, the bank does not distinguish between normal behaviour and suspicious behaviour, so even low-risk actions are treated as if the account is under attack.
- Use step-up authentication only when the action, device, or risk signal justifies the interruption.
- Prefer methods that fit the channel, such as app-based approval or biometric reauthentication, when policy allows it.
- Keep recovery paths short, because a cumbersome fallback often causes more abandonment than the original MFA prompt prevented.
Frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the NHI-focused guidance in Ultimate Guide to NHIs both reinforce the same practical point: authentication should be proportionate to risk and manageable in the real workflow. These controls tend to break down when banks rely on one-size-fits-all challenge logic across mobile, web, and assisted-service channels because the user journey is not uniform.
Where the Trade-off Becomes Acceptable
Tighter authentication often increases abandonment and support cost, so banks have to balance fraud reduction against transaction completion. The trade-off is legitimate when the action is sensitive, the account is newly accessed, or the behaviour is unusual. It is much harder to justify when the bank applies the same friction to every login, every balance check, or every routine transfer without any contextual trigger.
Best practice is evolving toward risk-based and intent-aware authentication, but there is no universal standard for how much friction is acceptable. Some banks can safely reduce friction because they have strong device binding, better anomaly detection, or more resilient recovery flows. Others cannot, because their environments still depend on weak fallback channels or inconsistent customer identity data. In those cases, the issue is not simply “too much MFA”; it is poorly governed MFA that is not aligned to customer journey design.
Practitioner takeaway: Treat customer experience as an authentication control quality signal, not just a product metric. If legitimate users are repeatedly pushed into fallback paths, the bank is likely over-challenging low-risk activity or under-investing in recovery design, and both conditions should be corrected before the friction becomes a trust problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | MFA design affects authentication strength and user access experience. |
| PR.AC-07 — Least Privilege Access | Over-broad challenge policies create avoidable access friction and scope creep. | |
| DE.CM-08 — Anomalies and Events | Risk-based MFA depends on detecting unusual access patterns before prompting. | |
| Recommendation — Tune authentication strength to task risk and reduce unnecessary user interruption. Limit step-up challenges to the minimum set of high-risk actions. Use anomaly signals to trigger MFA only when behavior departs from normal patterns. | ||
| NIST SP 800-63 | AAL — Authentication Assurance Level | Assurance levels govern how strong and burdensome MFA needs to be. |
| Recommendation — Match assurance level to transaction risk and channel sensitivity. | ||
| CIS Controls v8 | 6 — Access Control Management | MFA friction often comes from access control policies and fallback handling. |
| Recommendation — Streamline access controls so routine banking actions do not trigger avoidable friction. | ||
Related resources from NHI Mgmt Group
- Why does multi-factor authentication help with online banking security?
- Why does multi-factor authentication matter more for financial services with high transaction volume and sensitive customer data?
- What is the difference between biometric authentication and risk-based multi-factor authentication in digital identity programs?
- Why does fraud prevention often damage customer experience when identity checks are applied too broadly?
