For twenty years, a six-digit code sent by text message was how the world proved identity online. That period is ending, and not because the industry decided to move on. Regulators decided for it.
The United Arab Emirates set the hardest deadline: licensed financial institutions had to be off SMS and email OTP by 31 March 2026. The Philippines followed on 30 June 2026 for high-risk transactions. India’s new authentication rules took effect on 1 April 2026, though they work differently from what most coverage suggests. In the United States, NIST now classifies delivery over the telephone network as a restricted authenticator.
Most coverage of this shift stops at the headline. The more useful question for anyone running a regulated service is different: once SMS OTP is gone, where does the fraud actually go?
Deepfakes are becoming more sophisticated, increasing the risk of fraud and identity manipulation in digital environments. Download our 10-step guide to learn how to detect threats early and protect your organization with proven best practices.
Where SMS OTP stands in 2026
The picture is not one global ban. It is a set of jurisdiction-specific rules moving in the same direction at different speeds.
| Jurisdiction | Instrument | Status as of 31 August 2026 | What it requires |
|---|---|---|---|
| UAE | CBUAE Notice CBUAE/FCMCP/2025/3057 | Deadline passed 31 March 2026 | Removal of SMS and email OTP as an authentication mechanism for licensed financial institutions, in favour of in-app approval, soft tokens, passkeys and biometric verification. Liability for 3D Secure fraud sat with the institution from July 2025, ahead of the deadline |
| Philippines | BSP Circular No. 1213 (2025), implementing Section 6 of the Anti-Financial Account Scamming Act (RA 12010) | Deadline passed 30 June 2026 | Transition away from interceptable mechanisms (SMS and email OTP) for high-risk transactions and critical account changes. OTP retains one permitted use: confirming ownership of a registered mobile number. The BSP confirmed in January 2026 that it would not extend the date |
| India | RBI (Authentication Mechanisms for Digital Payment Transactions) Directions, 2025 | In force since 1 April 2026. Cross-border CNP obligations from 1 October 2026 | Two independent factors for domestic digital payments. For transactions other than card-present, at least one factor must be dynamically generated per transaction or capable of being proven, such as a biometric. Does not discontinue SMS OTP |
| Vietnam | SBV Decision 2345/QĐ-NHNN | In force since 1 July 2024 | Biometric verification, matched against the chip ID card or the national population database, for first-time mobile banking use, new devices, and transfers above defined thresholds |
| Singapore | MAS and ABS joint announcement, 9 July 2024 | Completed (industry measure, not a statutory ban) | Major retail banks stopped using OTP for account login for customers with an activated digital token, over a three-month transition |
| European Union | PSD2 Strong Customer Authentication (EBA RTS). PSD3 and PSR agreed politically on 27 November 2025, adoption and application pending | SCA long-standing; successor framework not yet applicable | Two independent factors from separate categories, with dynamic linking for payment transactions. The PSR is expected to tighten SCA and fraud-liability rules, with application widely expected in 2027–2028 |
| United States | NIST SP 800-63B-4, published July 2025 (superseded the previous revision on 1 August 2025 | Applies to federal agencies; de facto benchmark elsewhere | Use of the PSTN, meaning SMS and voice, to deliver out-of-band secrets is a restricted authenticator. Continued use requires a documented risk assessment, availability of a non-restricted alternative, meaningful notice to users, and a migration plan |
Three details in that table are routinely misreported and worth stating plainly.
India did not ban SMS OTP. The RBI Directions widen the set of acceptable factors and raise the baseline. The framework states that it “does not call for discontinuation of SMS based OTP”. What it ends is the assumption that SMS OTP alone satisfies the requirement. It is also more flexible than commonly reported: the second factor can be dynamically generated or capable of being proven, which is where biometrics enter.
PSD2 never treated SMS OTP as sufficient on its own either. SMS OTP is a single possession factor. Under Strong Customer Authentication it always needed a second, independent factor. The change is not the rule, it is the tolerance for weak implementations of it.
Vietnam has been running the biometric version of this for two years. Decision 2345 did not restrict the OTP channel so much as add a verification step above it, matched against national identity records. It is the closest existing precedent for what the rest of this article argues.
Hong Kong, Malaysia, Saudi Arabia and Indonesia are at various stages of supervisory guidance or consultation. The direction of travel is consistent even where a formal mandate has not landed.
What is actually replacing SMS OTP
This is where a lot of commentary gets loose, so it is worth being precise.
The dominant replacements for SMS OTP in transactional authentication are passkeys and FIDO2 credentials, software tokens inside the bank’s own app, and in-app push approval. All three share the same underlying property: a private key is generated on the user’s device, never leaves it, and signs a challenge. Nothing interceptable travels over a network the attacker can reach.
Biometrics appear in that architecture, but not in the role most people assume. When a customer approves a payment with a face or fingerprint on their banking app, in the majority of deployments that biometric is not being matched against a server. It is unlocking a private key held locally on the device. The biometric is a local gesture. The cryptography is what the bank actually verifies.
This distinction matters because it is the difference between authentication and verification, two operations that are frequently collapsed into one word. [internal link: authentication vs verification] Authentication answers “is this the same device and credential we enrolled?” Verification answers “is this the right human being?”
NIST separates them at the level of document structure. SP 800-63A governs enrolment and identity proofing. SP 800-63B governs authentication and authenticator management. They are different volumes because they are different problems.
The consequence: risk moves, it does not disappear
A device-bound credential is a strong answer to one question. It proves that a specific device, holding a specific key, approved a specific transaction. That is a meaningful improvement over a code that can be phished, intercepted over SS7, or redirected through a SIM swap. [internal link: SIM swap and telecom fraud]
What it does not prove is which human was holding the device.
Every hardware-rooted or device-bound scheme contains a moment where a key gets bound to an identity. That moment is enrolment. The cryptographic strength of everything downstream is inherited from the quality of the identity check performed at that point. A credential that cannot be phished is not an improvement if it was issued to the wrong person. It is a durable, unphishable credential in the hands of a fraudster.
This is the practical consequence of the SMS OTP phase-out that most migration plans underweight. When the authentication layer hardens, attackers do not stop. They move to the three moments where the device cannot answer on its own behalf:
- Enrollment. Opening the account and binding the first credential. This is where synthetic identities and mule networks enter the system.
- Account recovery. The customer has lost the phone. There is no key, no device, no secure element.
- Device re-binding and high-risk step-up. Adding a new device, or authorising a transaction that exceeds the risk threshold the credential alone can carry.
Regulators have started to name these moments explicitly. The CBUAE requires step-up authentication for a defined set of sensitive actions, including changing security settings, updating personal data and requesting a new card, and it does not accept a fresh SMS as that step-up. The BSP extends its rule beyond login to critical account changes. The pattern is the same in both: the moments where identity has to be re-established are exactly the moments the old fallback covered.
Account recovery is the blind spot
Of those three, recovery is the least discussed and the most exposed.
Recovery is a recognised design problem in large passkey deployments, not a vendor talking point — the FIDO Alliance publishes guidance on it precisely because the industry has not settled it. The credential is device-bound by design, which is what makes it strong, and what makes losing the device a problem the credential cannot solve on its own.
At that moment the institution has nothing cryptographic to work with. It has a person claiming to be an existing customer. Historically, the answer was a knowledge-based question, a call centre agent, or an SMS to the registered number. NIST SP 800-63A-4 states that knowledge-based verification must not be used for identity verification. The SMS route is the one being decommissioned. Call centre verification remains a heavily targeted social engineering surface in retail banking.
What remains is the ability to verify that a live, real person matches the identity that was originally enrolled. That is biometric identity verification, performed against the enrolment record, not a local unlock gesture. [internal link: identity verification hub]
Regulators have recognised this. The CBUAE’s own framing of acceptable replacements includes biometric verification alongside cryptographic methods, with Emirates Face Recognition — the UAE’s national face verification service — cited in supervisory communication and industry guidance as one of the routes institutions are expected to use. Vietnam went further, and earlier: Decision 2345 requires the biometric sample to match the national identity record, which is verification against an authoritative source, not a device unlock. The regulators that moved first did not point exclusively at cryptographic tokens.
What this requires from the verification layer
If verification is carrying the load at enrolment and recovery, it has to withstand the attacks that target those specific moments. Four requirements follow.
Presentation attack detection. Printed photographs, screen replays, 3D masks and silicone artefacts are the baseline attack set at enrolment. ISO/IEC 30107-3 is the standard that defines how resistance to these is measured, and independent evaluation against it is what separates a claim from a result.
Injection attack resistance. A growing share of remote identity fraud never presents anything to a camera. The attacker bypasses the capture device entirely and injects synthetic video, increasingly generated, directly into the application stream. Detecting a convincing deepfake in a frame is a different technical problem from detecting that the frame never came from the camera at all. Both need covering.
Control of the capture process, with as little friction as possible. Recovery and enrolment already carry friction, so a verification step that asks the user to blink, turn or follow a moving target adds abandonment at exactly the wrong moment. But the answer is not simply to analyse an image that has already been captured, because that is precisely the case injection attacks are built for. What matters is that the system controls and protects the capture itself, and does it in a single, fast interaction the user does not have to be taught.
On-device processing. Capture and liveness analysis performed on the handset itself reduce the surface an attacker can reach, keep biometric data from transiting unnecessarily, and work under the connectivity conditions that exist outside well-served urban markets. This matters for reach as much as for security. A verification method that only functions on a recent flagship handset with good bandwidth excludes a large share of the population that regulators are simultaneously trying to bring into the formal financial system.
Where Identy.io fits
Identy.io builds the verification layer, not the authentication layer. The SDK performs contactless fingerprint and facial capture with liveness detection, processed on the device itself, and feeds identity proofing at enrolment, recovery and re-binding. [internal link: biometric authentication hub]
On independent evaluation, Identy.io’s Face SDK v6.3.0 was tested by iBeta, a NIST/NVLAP-accredited laboratory, under ISO/IEC 30107-3 at PAD Level 2, with an attack presentation classification error rate of zero across 1,500 attack attempts. In the 2025 Remote Identity Validation Rally run by the DHS Science and Technology Directorate at the Maryland Test Facility, Identy.io reported zero attack acceptance in the Active PAD evaluation, which assesses the complete capture process with real users rather than previously acquired samples. Results in both cases reflect performance under the specific attack sets and conditions defined by those evaluations, which is the only basis on which any vendor claim in this field should be read.
The technology is designed to run on standard consumer hardware rather than dedicated capture devices, which is what allows the same verification standard to be applied across markets with very different device profiles and network conditions.
Practical checklist for institutions migrating off SMS OTP
If you are planning or auditing a migration, these are the questions worth putting on the table:
- Which regulator, which instrument, which date applies to each market you operate in? The rules are not harmonised and a global policy will over- or under-comply somewhere.
- Does your migration plan cover enrolment and recovery, or only the login and transaction approval steps?
- What happens when a customer loses their device? Trace that path end to end and identify who or what makes the identity decision.
- Has your presentation attack detection been evaluated independently against ISO/IEC 30107-3, and at which level?
- Can you distinguish a spoofed presentation from an injected video stream? These are separate defences.
- Does your verification work for customers on entry-level devices and constrained connections, or does it quietly exclude them?
Frequently asked questions
Is SMS OTP banned worldwide?
No. Two markets have gone furthest: the UAE, where licensed financial institutions had to be off SMS and email OTP by 31 March 2026, and the Philippines, where BSP-supervised institutions had to stop using it for high-risk transactions and critical account changes by 30 June 2026. Elsewhere it is restricted, deprecated or supplemented rather than prohibited. In the United States, NIST SP 800-63B-4 classifies delivery over the telephone network as a restricted authenticator, which permits continued use subject to a documented risk assessment, an available alternative, user notification and a migration plan.
Did the RBI ban SMS OTP in India?
No. The Directions in force since 1 April 2026 require two independent factors for domestic digital payments. For transactions other than card-present ones, at least one factor must be dynamically generated for that transaction or capable of being proven, such as a biometric. The framework states that it does not call for discontinuation of SMS-based OTP. It raises the baseline rather than removing the method.
Does biometrics replace SMS OTP?
Not directly. In most deployments SMS OTP is replaced by passkeys, software tokens or in-app push approval, where a biometric unlocks a private key held on the device. Biometrics replace SMS OTP in a different place: at enrolment, account recovery and device re-binding, where identity has to be established rather than a credential re-used. Vietnam’s Decision 2345 is the clearest regulatory example of biometrics used in that second sense.
Why is account recovery the weak point?
Because device-bound credentials are strong precisely because they are bound to a device. When the device is lost, there is no key to check. The institution has to establish identity from scratch, and the traditional fallbacks — knowledge-based questions and SMS to a registered number — are the ones regulators are removing.
What is a restricted authenticator under NIST?
A method that remains permitted but requires additional scrutiny. Under SP 800-63B-4, use of the PSTN, meaning SMS and voice, to deliver out-of-band secrets is restricted. Organisations relying on it must assess and accept the risk, ensure a non-restricted alternative is available to subscribers, give users meaningful notice of the limitation, and maintain a migration plan.
Has the UAE deadline passed?
Yes. Implementation rolled out from July 2025 and the compliance date was 31 March 2026. The liability shift for 3D Secure fraud applied before that date, from July 2025.
What changes in the EU with PSD3 and PSR?
The Strong Customer Authentication requirement itself is not new. What changes is the instrument and the strictness: the PSR is a directly applicable regulation rather than a directive, and it tightens SCA, fraud monitoring and liability. Political agreement was reached on 27 November 2025; adoption and the application date are still pending, with application widely expected in 2027–2028. Institutions should track the EBA’s technical standards rather than the headline text.
Get a tailored demo of our contactless biometric platform and see how it fits your specific use case.
Get a tailored demo of our contactless biometric platform and see how it fits your specific use case.
References
- Central Bank of the UAE. Notice CBUAE/FCMCP/2025/3057, Consumer Protection Standards — phase-out of SMS and email one-time passwords for licensed financial institutions. Issued 2025; compliance date 31 March 2026. centralbank.ae
- Reserve Bank of India. Reserve Bank of India (Authentication Mechanisms for Digital Payment Transactions) Directions, 2025. Issued 25 September 2025, effective 1 April 2026; cross-border card-not-present obligations from 1 October 2026. Accompanying press release, 25 September 2025. rbi.org.in
- Bangko Sentral ng Pilipinas. Circular No. 1213, Series of 2025, implementing Section 6 of the Anti-Financial Account Scamming Act (Republic Act No. 12010). Compliance date 30 June 2026. bsp.gov.ph
- Monetary Authority of Singapore and The Association of Banks in Singapore. Banks in Singapore to Strengthen Resilience Against Phishing Scams. Media release, 9 July 2024. https://www.mas.gov.sg/news/media-releases/2024/banks-in-singapore-to-strengthen-resilience-against-phishing-scams
- State Bank of Vietnam. Decision No. 2345/QĐ-NHNN on safety and security solutions in online payments and bank card payments. Effective 1 July 2024. sbv.gov.vn
- National Institute of Standards and Technology. SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management. July 2025. https://doi.org/10.6028/NIST.SP.800-63B-4 — see the restricted authenticator provisions at https://pages.nist.gov/800-63-4/sp800-63b/authenticators/
- National Institute of Standards and Technology. SP 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment. July 2025. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63A-4.pdf
- European Banking Authority. Regulatory Technical Standards on Strong Customer Authentication and common and secure communication under PSD2. eba.europa.eu
- Council of the EU and European Parliament. Provisional political agreement on the Payment Services Directive (PSD3) and Payment Services Regulation (PSR), 27 November 2025.
- ISO/IEC 30107-3:2023. Information technology — Biometric presentation attack detection — Part 3: Testing and reporting. iso.org
- U.S. Department of Homeland Security, Science and Technology Directorate. Remote Identity Validation Rally (RIVR). dhs.gov
- Identy.io. Identy.io Facial Biometric Technology Receives NIST ISO 30107-3 Level 2 PAD Certification with Perfect Score. 4 November 2025.
- Identy.io. Identy.io achieves zero attack acceptance in DHS RIVR face liveness evaluation. March 2026.
- iBeta Quality Assurance. Public list of ISO/IEC 30107-3 PAD confirmation letters (IDENTY Identy.io Face SDK 6.3.0, Level 2, 6 October 2025). ibeta.com
