SMS OTPs depend on possession of a mobile number, which can be compromised through SIM swapping, phishing, or social engineering. They also add user friction because customers must move between devices, wait for delivery, and type a code. That combination makes them both easier to attack and harder to use than more modern authentication methods.
Why SMS OTPs Raise Fraud Risk in Banking
SMS one-time passwords are vulnerable because they inherit the security weaknesses of the phone number itself. A bank may be verifying a code, but the attacker’s real target is often the mobile account or messaging channel, not the customer’s device. That makes fraud possible through SIM swap abuse, message interception, phishing relay, and social engineering of support or telecom processes.
Once the attacker can receive the code, SMS OTP stops being a meaningful second factor and becomes a delivery mechanism for account takeover. In practice, the risk is not just stolen credentials, but stolen access continuity: the attacker can often complete login, password reset, or transaction approval flows that assume possession of the phone number proves legitimacy.
- Okta Breach shows how stolen authentication material can expose downstream access paths.
- MailChimp Breach illustrates how social engineering can convert human trust into credential exposure.
- OWASP Non-Human Identity Top 10 is useful background on why possession-based secrets and short-lived codes need strong lifecycle control.
Why SMS OTPs Frustrate Customers
The customer-friction problem is structural, not cosmetic. SMS OTPs add extra steps at the exact moment users want a transaction to finish: they must switch apps or devices, wait for carrier delivery, deal with delays or failed messages, and manually transcribe a code before the session expires. Even when the process works, it interrupts flow and increases abandonment.
That friction also creates accessibility and reliability problems. Travelling customers, users with poor coverage, international roaming, and people who change numbers or lose access to a SIM can all be locked out or forced into recovery channels. The result is more support calls, more fallback authentication, and a higher chance that the bank’s most common “security control” becomes the bottleneck customers notice most.
- NIST Cybersecurity Framework 2.0 supports balancing protection with usability in control design.
- OWASP Cheat Sheet Series is a practical reference for authentication and session handling patterns that reduce avoidable user burden.
- NIST Privacy Framework is relevant where phone numbers and messaging channels become part of the customer data and trust boundary.
What Banks Should Do Instead
SMS OTP should be treated as a legacy fallback, not a preferred default, especially for account recovery, high-value transfers, and step-up authentication. Stronger options such as app-based authenticators, phishing-resistant methods, and device-bound approval flows reduce both takeover risk and user annoyance because they avoid dependence on telecom infrastructure and manual code entry.
What to prioritise: Replace SMS first in the flows where the business impact of compromise is highest, then keep only a tightly governed fallback path for exceptional cases. If SMS must remain, add layered monitoring for number-change events, recovery attempts, and anomalous login behaviour so the channel is not trusted in isolation.
What practitioners underestimate: The real cost is not just fraud or not just friction, but the interaction between the two. A control that is easy to socially engineer and annoying to use tends to be overused by the business and undertrusted by security teams, which is usually the sign that migration pressure is justified.
Practitioner takeaway: If a factor can be redirected by the telecom layer and slows every legitimate login, it is usually too weak for primary banking authentication unless it is only a constrained fallback.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | SMS OTP is an access control factor tied to account recovery and login assurance. |
| Recommendation — Restrict SMS OTP to low-risk fallback flows and remove it from high-value access paths. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | Authentication choice directly affects identity assurance and user access risk. |
| PR.AT-01 — Awareness and Training | Phishing and social engineering are core abuse paths for SMS OTP theft. | |
| PR.DS-01 — Data-at-Rest Protection | Phone numbers and OTP-related data become sensitive identity inputs in banking flows. | |
| Recommendation — Prefer stronger authentication methods that raise assurance without adding avoidable friction. Train users and support staff to recognise OTP relay and number-swap abuse. Minimise retention and exposure of phone-number data used for authentication. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secret Rotation and Lifecycle | One-time codes and possession-based factors need short-lived, tightly governed lifecycles. |
| NHI-08 — Weak Secrets and Credential Exposure | SMS OTP is vulnerable when attackers can intercept or redirect the code channel. | |
| NHI-10 — Third-Party and Supply-Chain Risk | SMS delivery depends on external telecom infrastructure outside the bank's direct control. | |
| Recommendation — Use short-lived, tightly governed authenticators and reduce dependence on reusable phone-based trust. Eliminate authentication paths that can be hijacked through exposed or redirected delivery channels. Treat telecom delivery as an external dependency and avoid relying on it for high-risk approvals. | ||
Related resources from NHI Mgmt Group
- Why do passwords and SMS one-time passcodes create risk in remote authentication flows?
- Why do traditional passwords and one time passcodes create ongoing fraud risk?
- Why do weak authentication methods create fraud risk in digital banking?
- Why do reused passwords still create account takeover risk in digital banking?
