SMS OTP bans are forcing a reset in banking authentication

At a glance

What this is: This guide maps how financial regulators are restricting or removing SMS OTP in banking and shows that the common direction is toward phishing-resistant, device-bound authentication.

Why it matters: IAM, IAM governance, and fraud teams need to treat SMS OTP exit plans as an authentication redesign problem because the control failure is structural, not regional.

By the numbers:

• More than 25 regulators worldwide have now moved toward phishing-resistant authentication.
• The State Bank of Vietnam has reported a roughly 50% drop in fraudulent transactions since rollout.

👉 Read IDlayr's regulator-by-regulator guide to the global SMS OTP ban

Context

SMS OTP is a shared-secret factor delivered over an external channel, which means the bank does not control the path, the interception risk, or the device trust context. In banking, that makes it fragile against SIM swap, SS7 abuse, smishing, and adversary-in-the-middle attacks, especially where fraud and authentication are now tightly linked.

The regulatory shift is not uniform, but the direction is consistent: remove SMS OTP from high-risk flows, restrict it as a factor, or replace it with device-bound, cryptographic, or biometric alternatives. For identity programmes, this is a human IAM and fraud-control issue with direct implications for assurance level, channel trust, and account recovery design.

Key questions

Q: How should banks phase out SMS OTP without breaking customer access?

A: Banks should phase out SMS OTP by starting with the highest-risk journeys, then replacing fallback paths before disabling the legacy factor. That means login, payments, beneficiary changes, and account recovery all need stronger authenticator options, clear exception handling, and customer migration paths that do not rely on the same weak channel being retired.

Q: Why does SMS OTP create more risk in banking than many teams assume?

A: SMS OTP creates more risk because it is delivered over a channel the bank does not control and can be intercepted, relayed, or redirected. In practice, that makes the control vulnerable to SIM swap, phishing, and social engineering at the exact moment the user is trying to prove possession.

Q: What do security teams get wrong about replacing OTP with stronger authentication?

A: Teams often focus on login and forget the surrounding lifecycle. If account recovery, device reset, or beneficiary change still depends on SMS, the programme keeps a weak path that attackers can use to re-enter the account even after the primary login control is improved.

Q: Who is accountable when SMS OTP fraud losses rise after a regulatory deadline?

A: Accountability usually shifts toward the institution when regulators have made stronger authentication mandatory or explicitly expected. Where the bank has not migrated off an interceptable factor in time, it is hard to argue that fraud losses were outside its control or governance scope.

Technical breakdown

Why SMS OTP fails as a possession factor

SMS OTP is often treated as possession because the message reaches a registered phone number, but that is a weak proxy for device possession. The delivery path crosses carrier infrastructure, can be redirected through SIM swap or port-out fraud, and is vulnerable to phishing that relays the code in real time. In authentication terms, the factor is transient, replayable within the time window, and not bound to the transaction or device. That is why regulators increasingly prefer factors that are cryptographically bound to the device or session.

Practical implication: treat SMS OTP as a transitional control for low-risk flows, not as a durable second factor for high-value banking actions.

Device binding and phishing-resistant authentication

Device binding changes the assurance model by tying the authenticator to a specific device, app instance, or secure hardware element rather than to a reusable code. Phishing-resistant methods such as passkeys, device-bound tokens, and cryptographic approvals reduce the value of intercepted credentials because the authentication event cannot be cleanly replayed elsewhere. In regulated banking, this matters because the control must survive both social engineering and channel compromise. The real question is not whether an OTP exists, but whether the authenticator can be stolen, relayed, or reused outside the intended device context.

Practical implication: prioritise authenticators that are cryptographically bound to the device or transaction for login, payments, and account changes.

Risk-based authentication and step-up design

Many regulators are not banning every use of SMS OTP. Instead, they are narrowing where it may appear, such as low-risk verification or mobile-number ownership checks, while demanding stronger controls for transfers, login, and account maintenance. That creates a risk-based architecture problem: the assurance level must vary by action, not by channel convenience. Strong programmes separate authentication from transaction authorisation, use dynamic linking where required, and apply stronger factors when the account risk or transaction value rises.

Practical implication: map each banking journey to an assurance tier and remove SMS OTP from the flows where transaction risk is highest.

Threat narrative

Attacker objective: The attacker’s objective is to impersonate the customer well enough to approve high-risk banking activity and move money or alter account controls.

1. Entry begins when the attacker gains the ability to intercept or relay an SMS OTP through SIM swap, smishing, or a phishing proxy.
2. Escalation occurs when the captured code is used to satisfy a bank login or transaction challenge before it expires.
3. Impact follows when the attacker authorises payments, changes account settings, or takes over the account in a way the bank can no longer distinguish from legitimate use.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SMS OTP is a channel-trust problem, not a factor-count problem. The industry often describes the issue as a missing second factor, but the real weakness is that the factor travels through infrastructure the bank does not control. That makes interception, relay, and replay the default failure modes rather than edge cases. Practitioners should treat this as a trust-boundary redesign problem, not a preference for one authentication method over another.

Phishing-resistant authentication is becoming the practical floor for regulated banking. The regulatory pattern across the UAE, Singapore, Malaysia, the Philippines, and Vietnam shows that banks are being pushed toward cryptographic or device-bound assurance for the actions that matter most. This aligns with the spirit of NIST SP 800-63 Digital Identity Guidelines and NIST Cybersecurity Framework 2.0, where stronger authenticator assurance is paired with risk-aware control design. Practitioners should expect legacy OTP to be narrowed into residual use cases.

Account recovery is now part of the authentication attack surface. Once banks remove SMS OTP from login and transaction approval, the recovery journey becomes the new place where weak trust assumptions can re-enter the programme. If recovery still depends on SMS, reusable email links, or low-assurance callbacks, the strongest login control is undermined at the edge. The implication is that identity assurance has to be consistent across onboarding, step-up, recovery, and account change events.

Regulatory fragmentation creates a single operational requirement: design for the strictest market first. A bank operating across multiple jurisdictions cannot maintain one SMS OTP model per country without creating policy drift, inconsistent customer journeys, and control exceptions. The market signal is clear: institutions should build a common phishing-resistant baseline and then apply local exceptions only where the regulator explicitly permits them. Practitioners should align global IAM policy to the highest-assurance jurisdiction they serve.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Forward-looking control design in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs helps teams translate governance intent into revocation and offboarding practice.

What this signals

Phishing-resistant authentication will keep moving from best practice to default expectation. Banking teams should assume that SMS OTP will survive only in narrow residual workflows, while login and payment approval shift toward device-bound assurance and stronger recovery controls. The operational challenge is no longer whether to modernise, but how to do it without creating a weak fallback path.

Identity programmes need a recovery-first design lens. Once the primary factor becomes stronger, the weakest surviving path often becomes account reset, device replacement, or exception handling. For practitioners, that means policy, help desk process, and fraud operations now sit inside the authentication control plane rather than outside it.

Governance teams should treat fraud and IAM as one operating model. When regulators tie liability to authentication failure, the security question becomes whether the control can withstand interception, relay, and social engineering across the entire identity lifecycle. That makes lifecycle governance, not just login hardening, the deciding factor in programme resilience.

For practitioners

• Inventory every SMS OTP dependency Map where SMS OTP is used for login, transaction approval, account changes, and recovery. Separate low-risk verification from high-risk authorisation so migration decisions are based on control purpose, not channel habit.
• Prioritise phishing-resistant factors for high-risk flows Move first on card payments, beneficiary changes, first-time device use, and other actions where interception risk creates direct fraud exposure. Device-bound authenticators and cryptographic approvals should become the default for these journeys.
• Redesign recovery before disabling OTP Replace SMS-based fallback paths with stronger identity proofing, step-up methods, or device-bound recovery workflows. The weakest recovery control will define the actual assurance level of the programme.
• Align policy to the strictest regulator Create a single global control baseline that meets the toughest market requirement, then document local exceptions explicitly. This reduces fragmentation when regulators move on different timelines but in the same direction.

Key takeaways

• SMS OTP is being removed or restricted because it fails against interception, relay, and device compromise, not because regulators prefer cosmetic change.
• The strongest regulatory pressure now points toward device-bound, phishing-resistant authentication for high-risk banking actions and account recovery.
• Banks that treat OTP retirement as a lifecycle and governance problem, not just a login change, will have fewer exceptions and less fraud exposure.

Key terms

• Phishing-resistant authentication: Authentication that cannot be easily relayed, replayed, or phished from one device or session to another. In practice, it relies on cryptographic binding or device-backed approval rather than reusable secrets delivered through a vulnerable channel.
• Device binding: A control that ties an authenticator or approval step to a specific device or app instance. It reduces the value of intercepted credentials because the proof of possession is anchored to hardware, software, or secure enclave context rather than a transferable code.
• Strong customer authentication: A higher-assurance authentication model that requires multiple factors and, in some regimes, transaction-specific protection. It is designed to reduce fraud in banking by making login and approval harder to intercept, replay, or social engineer.
• Account recovery: The process used to regain access after a password reset, device loss, or authenticator failure. It often becomes the weakest point in an identity programme if it relies on lower-assurance channels such as SMS or email.

What's in the full article

IDlayr's full article covers the regulatory detail this post intentionally leaves for the source:

• Primary-source summaries for each regulator, including the exact instruments and deadlines.
• Market-by-market differences between outright bans, restricted use, and expanded factor options.
• The specific replacement controls banks are using, including app-based approvals, biometrics, and device binding.
• Cross-border implications for institutions that need one policy baseline across multiple jurisdictions.

👉 The full IDlayr guide breaks down each regulator's deadline, scope, and primary-source basis.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.