How should financial institutions reduce reliance on SMS one-time passcodes for customer authentication?

Why This Matters for Security Teams

SMS one-time passcodes still appear convenient, but they are a weak primary factor for financial authentication because they depend on a phone number, the mobile network, and a message path that can be redirected or intercepted. Current guidance from NIST SP 800-63 Digital Identity Guidelines treats SMS as a restricted option, not a preferred one, because it is vulnerable to SIM swap, forwarding abuse, phishing, and number recycling.

For banks and payment providers, the real issue is not only fraud loss. SMS OTP also creates avoidable customer friction during step-up authentication, account recovery, and high-risk transactions, especially when users are roaming or using devices with poor signal. Institutions that keep SMS at the centre of authentication tend to inherit a control that is operationally familiar but increasingly fragile under targeted attacks.

NHI Management Group data shows why this matters in broader identity programs: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, reinforcing that authentication controls fail when the trust model is too static or too easy to redirect. In practice, many security teams encounter SMS weakness only after account takeover patterns have already been exploited at scale, rather than through intentional control design.

How It Works in Practice

The practical shift is to make SMS a fallback channel and move primary customer verification toward stronger, phishing-resistant methods. For mobile-first institutions, that often means device-bound authentication, push-based approval with transaction details, or cryptographic proofs anchored in the customer’s registered device. For regulated step-up flows, institutions should favour real-time verification that can evaluate risk at the moment of access rather than relying on a pre-issued code that may already be compromised.

Implementation usually works best when layered:

• Use NIST SP 800-53 Rev 5 Security and Privacy Controls to define stronger authentication and transaction protection requirements.
• Reserve SMS for low-risk fallback and recovery paths only, with explicit fraud monitoring.
• Bind authentication to a known device or app where possible, so the customer proves possession of the registered endpoint rather than a transferable phone number.
• Use risk signals such as new device, impossible travel, beneficiary change, or payment amount to trigger step-up instead of asking for SMS at every event.
• Provide recovery paths that do not collapse back into the same vulnerable phone number if the device is lost or swapped.

Where institutions can adopt stronger mobile network based authentication, that can reduce reliance on extra software while still improving assurance. The architecture should also account for privacy, accessibility, and customers who cannot use modern smartphones. This is where a mature identity program matters: Ultimate Guide to NHIs shows how weak lifecycle controls and poor visibility amplify identity risk across environments. These controls tend to break down in high-volume call-centre recovery flows because attackers exploit the weakest fallback path.

Common Variations and Edge Cases

Tighter authentication often increases customer support load and onboarding friction, requiring institutions to balance fraud reduction against conversion, accessibility, and recovery complexity. There is no universal standard for this yet, especially where legacy core banking, telecom dependency, and regional regulation all collide.

Some institutions can deploy app-based or device-bound authentication immediately, while others must support customers without smartphones, customers in low-connectivity regions, and high-value corporate accounts with shared service desks. In those cases, current guidance suggests a tiered model: stronger methods for high-risk actions, limited SMS fallback for account recovery, and tightly monitored exception handling for edge cases.

Risk teams should also avoid replacing SMS with another weak, reusable factor. If the new method still depends on a single transferable secret, the control merely changes shape. The better benchmark is whether the method resists phishing, replay, forwarding, and interception while allowing real-time decisioning. For implementation patterns and fraud lessons, see the Twitter Source Code Breach and the Zacks Investment Research breach, both of which illustrate how weak identity controls compound into broader compromise.

Related resources from NHI Mgmt Group

• How should financial institutions balance DORA compliance with customer authentication experience?
• Why do SMS and email one-time passcodes create governance risk?
• How should financial institutions implement strong customer authentication for open banking without creating avoidable user friction?
• When does biometric authentication become a better control than passwords or one-time codes for customer transactions?