How should financial institutions implement Strong Customer Authentication without creating high drop-off rates?

Financial institutions should treat Strong Customer Authentication as a security and usability design problem, not just a compliance task. The goal is to combine two independent factors, such as something the customer knows and something they are, while keeping the journey fast enough that customers do not abandon it. Mobile and web flows should be tested for friction, channel independence, and resilience to device compromise.

Design SCA as a journey, not a gate

strong customer authentication works best when the institution designs for completion as well as assurance. The practical question is not whether the flow technically satisfies a rule, but whether customers can move through it quickly, on the right channel, with a clear fallback when the first method fails. For customer authentication design patterns that reduce abandonment, the Customer IAM (CIAM) Guide is a useful starting point.

In practice, that means choosing factors that are easy to use under real conditions, such as a passkey, app-based approval, or a device-bound method, rather than defaulting to clumsy steps that create delay at the exact moment a customer is trying to pay or log in. NIST’s guidance on authenticator assurance and phishing-resistant authentication in NIST SP 800-63 Digital Identity Guidelines is a good reference point for balancing assurance and usability.

The most important design principle is channel fit. A bank should not force the same authentication journey on every transaction, every device, and every customer segment if that adds friction without improving real assurance. A well-implemented SCA flow keeps the factor challenge proportionate to risk, so low-risk journeys remain fast while higher-risk events trigger step-up verification only when justified.

What reduces drop-off in mobile and web flows

Drop-off usually comes from avoidable friction, not from authentication itself. Long redirects, poorly timed SMS codes, confusing recovery steps, and repeated prompts across the same session all increase abandonment. Customers are far more likely to complete a flow when the method is familiar, the prompt is immediate, and the handoff between banking app, browser, and device feels consistent.

Mobile flows often benefit from push, passkey, or in-app approval because they reduce typing and context switching, while web flows need robust browser support and a clean recovery path if the primary device is unavailable. The most effective programs test both journeys under realistic conditions, including weak connectivity, older devices, and interrupted sessions, because friction often shows up only outside the lab.

Financial institutions should also treat fallback and recovery as part of the main design. If the backup path is materially harder than the primary path, customers will fail at the exact moment they need help. That is why mature identity programmes, such as NHIMG’s Passwordless and Passkeys Guide and MFA Guide, place as much emphasis on recovery and method choice as on the challenge itself.

Make resilience and channel independence part of the control

SCA fails when the control is tied too tightly to one device, one app, or one delivery channel. Institutions should expect customers to lose access to a phone, change devices, or encounter temporary service disruption, and they should build authentication that still works without weakening assurance. This is where multi-channel design matters: the institution needs a secure alternative path, not a duplicate of the same brittle one.

Channel independence also matters for security. A flow that depends on a single SMS code or a single push approval can be disrupted by SIM swap, notification fatigue, or device compromise. That is why higher-assurance implementations increasingly favour phishing-resistant methods and stronger recovery discipline, especially for high-value accounts or high-risk transactions.

For that reason, banks should test not just whether customers can authenticate, but whether they can do so after device loss, number change, browser failure, or account recovery events. The control should remain usable when the primary path is unavailable, otherwise the institution ends up trading one kind of risk for another.

Risk and Threat Considerations

The main risk is that an SCA design that looks compliant on paper creates abandonment in practice, pushing customers toward unsupported workarounds, repeated retries, or support-assisted recovery. A second risk is that weak fallback logic becomes the easiest attack path, because adversaries often target recovery, fatigue, or delivery-channel weaknesses rather than the primary factor challenge.

Failure mechanism: Friction accumulates when the authentication step is slow, inconsistent, or poorly matched to the channel, while attackers exploit recovery paths, notification prompts, or weaker backup methods to bypass stronger controls.

Impact: The institution gets both worse conversion and weaker security, because genuine customers drop out while attackers concentrate on the least resistant part of the journey.

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, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Covers authenticator assurance and phishing-resistant auth for balanced SCA design.
Recommendation — Use assurance levels to select a factor mix that preserves security without unnecessary friction.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Supports controlled authentication design and step-up decisions for staff-managed financial systems.
Recommendation — Apply IA-2 to enforce strong authentication where user access to banking systems is authenticated.
ISO/IEC 27001:2022	A.5.15 — Access control	Applies because SCA is an access-control design issue balancing assurance and usability.
	A.8.5 — Secure authentication	Directly supports selecting secure but low-friction authentication methods for customers.
Recommendation — Define access control rules that permit risk-based step-up while keeping customer journeys usable. Implement secure authentication methods that meet assurance goals without forcing avoidable drop-off.
OWASP ASVS	V6 — Authentication	Relevant to authentication flow quality, factor handling, and user-facing friction in web journeys.
	V7 — Session Management	Session continuity affects whether customers are repeatedly challenged or dropped during SCA flows.
Recommendation — Verify authentication flows for usability, resilience, and correct factor enforcement across channels. Preserve secure sessions so users are not forced through repetitive authentication prompts.

Practitioner Guidance

What to prioritise: Start with the journeys that carry the most value and the most abandonment risk, usually log-in, payment confirmation, and account recovery. If those three are solid, the rest of the SCA programme usually becomes easier to govern.

What to verify: Test the complete path on real mobile devices and desktop browsers, not just the preferred flow. Verify that customers can complete the journey after device change, poor connectivity, session timeout, and a failed first factor.

Decision rule: If a step-up method increases abandonment more than it reduces fraud exposure for a given transaction type, reserve it for higher-risk events and simplify the default path.

Practitioner takeaway: The winning SCA design is the one customers can complete reliably under normal conditions, because security that routinely interrupts completion often drives both user loss and unsafe fallback behaviour.