TL;DR: Regulators in the UAE, Singapore, Malaysia, the Philippines, India, the EU, the United States, Vietnam, and Saudi Arabia are moving banking away from SMS one-time passwords toward phishing-resistant, device-bound authentication, according to IDlayr. The practical consequence is that identity teams must plan for jurisdiction-specific decommissioning of interceptable factors, not treat SMS OTP as a stable second factor.
At a glance
What this is: This is a regulator-by-regulator briefing showing that SMS OTP is being restricted, phased out, or narrowed across major banking markets.
Why it matters: It matters because IAM, fraud, and digital identity teams must replace interceptable authentication methods with controls that survive SIM swap, phishing, and account takeover risk.
By the numbers:
- More than 25 regulators worldwide have now moved toward phishing-resistant authentication.
- The United Arab Emirates requires all licensed financial institutions to eliminate SMS- and email-based OTPs by 31 March 2026.
- The Reserve Bank of India says its 2025 directions do not call for discontinuation of SMS based OTP.
- Vietnam’s State Bank has reported a roughly 50% drop in fraudulent transactions since its biometric rollout.
👉 Read IDlayr's regulator-by-regulator guide to SMS OTP restrictions
Context
SMS OTP is a weakly controlled possession factor because the authentication secret travels over a channel the issuing institution does not control. The article’s central point is that regulators are no longer treating that weakness as theoretical, especially where banking fraud, SIM swap, phishing, and adversary-in-the-middle attacks are in scope.
For IAM and digital identity teams, the issue is not whether OTP still exists anywhere. It is whether the organisation can support jurisdiction-specific transitions to device-bound, phishing-resistant authentication while preserving user experience, transaction integrity, and auditability across regulated markets.
Key questions
Q: How should security teams phase out SMS OTP without breaking customer access?
A: Start with a jurisdiction map, then migrate the highest-risk flows first. Replace SMS OTP with device-bound or app-mediated factors, but keep recovery, device replacement, and support escalation in scope. If those fallback paths still use SMS OTP, the organisation has not really exited the risk, it has only moved it behind a different screen.
Q: Why do regulators view SMS OTP as insufficient for banking authentication?
A: Because the code is not truly bound to the user’s trusted device or session. It can be intercepted through SIM swap, phishing, SS7 abuse, and relay attacks, which makes it a weak possession factor when the transaction itself is high value or high risk.
Q: What operational failures happen when SMS OTP is removed too late?
A: Teams end up running a patchwork of exceptions, customer workarounds, and emergency support paths that are hard to audit and easy to abuse. The common failure is not login outage. It is uncontrolled fallback, where the weakest path becomes the de facto standard for edge cases.
Q: Who is accountable when a bank keeps SMS OTP after regulators restrict it?
A: Accountability sits with the institution’s control owners, risk leaders, and compliance function, because the article makes clear that some regulators also shift liability for fraud linked to weak authentication. The practical question is whether the remaining exception is documented, time-bound, and defensible under the applicable market rule.
Technical breakdown
Why SMS OTP fails as a possession factor
SMS OTP depends on a shared secret delivered through a telecom path, not on a cryptographic binding between the user, device, and authenticator. That makes it vulnerable to SIM swap, SS7 interception, smishing, and adversary-in-the-middle attacks that relay the code before the bank can establish trust. In regulator terms, the problem is not just user error. The factor itself has weak channel assurance and poor resistance to credential relay.
Practical implication: treat SMS OTP as a transitional control, not a target state for high-risk banking flows.
Phishing-resistant authentication and device binding
The article points toward a familiar regulatory preference: move authentication proof away from interceptable shared secrets and toward device-bound or cryptographic methods. That includes app-based approvals, passkeys, biometrics, and token-based possession factors that are harder to reuse outside the authorised device. This is consistent with the broader direction of phishing-resistant authentication in identity standards and banking supervision.
Practical implication: prioritise migration paths that bind the authenticator to a device or cryptographic key rather than a phone number.
Regulatory change creates identity lifecycle work
Authentication policy changes are not just a security architecture issue. They create lifecycle work across enrolment, recovery, device replacement, exception handling, and customer offboarding. If teams do not govern those transitions, they simply shift fraud from one weak factor to another, or create dead zones where legitimate users cannot reauthenticate after device loss or number portability.
Practical implication: map every market’s auth rule to enrolment, recovery, and fallback processes before the deadline arrives.
Threat narrative
Attacker objective: The attacker aims to impersonate the customer long enough to authorise transactions, alter account settings, or take over the banking session.
- Entry occurs when an attacker uses smishing, SIM swap, or adversary-in-the-middle phishing to obtain the one-time code sent by SMS.
- Escalation follows when that code is replayed against banking login or transaction approval flows that still trust the intercepted message as possession proof.
- Impact is account takeover, fraudulent transfer authorisation, or unauthorized account changes before the institution can distinguish the attacker from the legitimate user.
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.
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
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 no longer a stable possession factor for regulated banking. The regulatory pattern in the article is not a regional anomaly. It is a coordinated recognition that phone-number-based authentication cannot reliably prove the user controls the intended device or the intended session. For IAM programmes, that means SMS OTP is being demoted from trusted second factor to transitional exception.
Channel trust, not code strength, is the real failure mode. Six digits are not the issue. The issue is that the code crosses infrastructure the bank does not control, which gives SIM swap, SS7 abuse, phishing, and relay attacks a place to intervene. The control gap is structural, so treating OTP as a stronger password is the wrong model.
Authentication policy is becoming a jurisdictional governance problem. The article shows different regulatory postures, from outright phase-out to restricted use and conditional acceptance. That means global IAM teams need market-specific control mapping, not one universal mobile-auth standard. The practitioner conclusion is that authentication architecture now has to be operated like a compliance matrix.
Identity assurance is shifting from user-entered secrets to device-bound proof. Across the markets surveyed, the direction of travel is toward cryptographic or app-mediated verification, often with biometric or device binding on top. That aligns with NIST SP 800-63 Digital Identity Guidelines and NIST Cybersecurity Framework 2.0 thinking, where the strength of the authenticator matters as much as the act of authentication itself. Practitioners should plan for a zero-standing-trust posture toward SMS OTP.
Regulator-led deprecation is forcing lifecycle redesign, not just factor replacement. The article implies that replacement authentication only works if enrolment, recovery, fallback, and exception handling are redesigned together. Without that, users will route around the new control, and fraud teams will inherit the same risk under a different label. The conclusion is simple: the control plane and the lifecycle plane have to move together.
From our research:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- That lifecycle gap becomes more visible when authentication policy changes, so review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside this market guide.
What this signals
Identity teams should treat SMS OTP deprecation as a control migration programme, not a point fix. The real work is in recovery, exception handling, and market-by-market policy mapping, because those are the places where weak authentication tends to survive. Pair the migration with guidance from NIST Cybersecurity Framework 2.0 so ownership, risk, and control testing stay aligned.
Phishing-resistant authentication is becoming the baseline for regulated access, not an enhancement. Organisations that keep phone-number-based verification in high-risk flows will increasingly carry a compliance and fraud gap at the same time. For identity programmes that also govern service accounts and workload credentials, the lesson is the same: assurance has to match the risk, not the legacy channel.
Device binding is the named concept to watch here: authentication only becomes materially stronger when the factor is tied to a specific device or cryptographic key rather than a text message. That shift also changes the lifecycle burden, because enrolment, recovery, and offboarding now have to be managed as part of the identity programme, not treated as support tickets.
For practitioners
- Inventory every SMS OTP dependency by market Map login, transaction approval, account recovery, and change-of-details flows to the exact jurisdictions that still permit SMS OTP, restrict it, or mandate removal. Use the result to set migration priorities by deadline and regulatory exposure.
- Replace number-based trust with device-bound authentication Prioritise app-based approval, passkeys, hardware-backed tokens, or biometric methods where the regulator accepts them. The design goal is to bind authentication to a device or cryptographic key rather than a mobile number.
- Redesign recovery and fallback paths now Build device-loss, number-porting, and customer-support recovery flows that do not fall back to interceptable SMS OTP. Test those flows under fraud pressure, because attackers often target recovery after the primary factor is removed.
- Align policy exceptions to audit evidence Document every residual SMS OTP exception with business justification, expiry date, compensating control, and review owner. That creates a defensible control record when regulators ask why a weaker factor still exists.
Key takeaways
- SMS OTP is being pushed out of regulated banking because the delivery channel, not the code length, creates the trust gap.
- The regulatory evidence is broad enough that global IAM teams should plan for market-specific retirement schedules rather than one universal policy.
- The practical replacement is not simply a new factor. It is a redesign of authentication, recovery, and exception governance around device-bound proof.
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 CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B | The article centers on authenticator strength and phishing resistance. |
| NIST CSF 2.0 | PR.AC-1 | Authentication strength and access control are the core governance issue. |
| NIST SP 800-53 Rev 5 | IA-2 | Identity verification and authenticator management apply directly to SMS OTP replacement. |
| NIST Zero Trust (SP 800-207) | Zero Trust assumptions are challenged by interceptable second factors. |
Replace SMS OTP with stronger authenticators and document compensating controls under IA-2 and IA-5.
Key terms
- Phishing-resistant authentication: Authentication that cannot be easily replayed, intercepted, or phished through a simple code relay. In practice, it uses cryptographic or device-bound proof instead of a shared secret that travels over an untrusted channel, making it materially harder for an attacker to impersonate the user during login or transaction approval.
- Device binding: A control that ties an authentication factor to a specific registered device rather than to a phone number or generic message channel. It reduces relay and interception risk, but only if enrolment, recovery, and device replacement are governed carefully across the identity lifecycle.
- Interceptable authenticator: An authenticator whose proof can be captured or reused before it reaches the intended verifier. SMS OTP is the common example in banking, because the code can be exposed through telecom abuse, social engineering, or device compromise, which weakens its assurance value at higher risk levels.
What's in the full article
IDlayr's full article covers the jurisdiction-by-jurisdiction operational detail this post intentionally leaves at the policy level:
- The exact regulator instruments and deadlines that banks need for country-specific remediation planning.
- The distinction between outright bans, conditional restriction, and narrow exceptions for OTP use in different markets.
- The primary-source documents and links that compliance teams can use to verify each jurisdictional requirement.
- The practical market comparison that helps teams decide which authentication flows to replace first.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security 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.
Published by the NHIMG editorial team on 2026-06-05.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org