From
Ideem— device-bound passkeys and A2A payment authentication for banks, fintechs, and payment platforms.
TL;DR: One-time passwords delivered by SMS or email defined a generation of multi-factor authentication. NIST has now formally classified SMS and PSTN OTP as a restricted authenticator under SP 800-63B Revision 4, and 2025-2026 has seen a documented surge in adversary-in-the-middle phishing kits that bypass both SMS and email codes against banking targets in real time. The path forward is phishing-resistant, device-bound credentials that take the OTP out of the attacker's reach entirely. Here is what changed, what it means for financial institutions, and what a practical migration looks like.
When SMS and email one-time passwords entered the financial services mainstream, they solved a real problem. Static passwords were leaking at scale, credential stuffing was easy, and the industry needed a second factor that customers already had access to without buying a new device. A six-digit code delivered to a phone number on file checked a lot of boxes: it was something the user had, it was relatively cheap to deploy, and it raised the bar for opportunistic attackers.
For years that bar held. Account takeover rates dropped where MFA was deployed. Compliance teams could point to OTP as a legitimate possession factor. Customers grumbled about the friction, but they tolerated it.
Two things have changed since then. First, regulators and standards bodies have updated their guidance. Second, attackers have updated their tooling. The intersection of those two changes is why financial services authentication is moving on.
NIST's Digital Identity Guidelines (SP 800-63B) are not themselves a regulation, but they shape how regulators around the world think about authentication assurance. The latest revision, SP 800-63B-4, formally creates a category called restricted authenticators and places SMS and PSTN-based OTP in it. As of publication, OTP delivered over the public switched telephone network is the only authenticator type in that category.
Restricted carries a specific meaning. Organizations can still use SMS OTP, but they have to acknowledge its weaknesses, offer subscribers an alternative, mitigate known risks like SIM swap, number porting, device theft, and interception, and maintain a migration plan to a non-restricted method. NIST also explicitly notes that the restricted status may be adjusted further over time as the threat landscape evolves.
This is a directional signal. NIST initially proposed deprecating SMS OTP entirely, then walked it back to restricted because too many organizations depend on it and have no immediate alternative. The intent is unmistakable: SMS OTP is on a glide path out of high-assurance use, not a pedestal it sits on.
Email OTP receives similar treatment in the broader 800-63B-4 ecosystem. Email accounts are routinely compromised through credential stuffing and phishing, which makes them an unreliable channel for delivering an authentication secret. If the attacker controls the inbox, they control the OTP.
The bigger shift is what attackers can now do. Through 2025 and into 2026, the adversary-in-the-middle (AiTM) phishing kit has gone from a specialist tool to a phishing-as-a-service commodity. Microsoft, Proofpoint, and Sekoia have all published detailed analyses of the ecosystem.
Sekoia's January through April 2025 study identified eleven major AiTM kits in active use. Microsoft's Q1 2026 email threat report describes Tycoon2FA as one of the most widespread platforms in the category, and Microsoft's Digital Crimes Unit, working with Europol and industry partners, executed a coordinated takedown of parts of Tycoon2FA's infrastructure in early March 2026. The takedown was meaningful, but the broader ecosystem of kits has continued to operate.
The mechanics matter for any institution still leaning on OTP. An AiTM kit puts a reverse proxy between the customer and the real banking site. The customer enters their password, the proxy passes it through, the real site sends the SMS or email OTP to the customer, the customer enters the OTP into the proxy, the proxy passes it through, and the real site issues a session cookie. The attacker steals the cookie and replays it. The OTP did its job exactly as designed; it was just intercepted in the middle.
Microsoft Threat Intelligence has documented multi-stage AiTM and business email compromise campaigns targeting banking and financial services organizations specifically. The customer never sees a wrong padlock, a wrong domain, or anything that triggers their training. From their perspective, they logged in. This is what not phishing-resistant looks like in practice, and it is exactly the language NIST uses to describe OTP authenticators.
Email OTP gets less attention in the headlines but raises overlapping problems. Email is asynchronous, slow, and frequently caught by spam filters. More importantly, the security of an email OTP is bounded by the security of the email account. If the customer reuses passwords, has not enrolled MFA on their email, or has been targeted by a phish that compromised their inbox, the OTP arrives in the attacker's hands.
For high-value banking actions like wire initiation, account recovery, or beneficiary changes, that bound is too low. The factor of possession is supposed to mean the user holds something the attacker does not. If both can read the inbox, the factor has collapsed.
The good news is that the industry has converged on what the next layer looks like. NIST 800-63B-4 explicitly integrates FIDO passkeys, both device-bound and syncable, into the AAL2 and AAL3 requirements. Phishing-resistant authentication means the protocol itself prevents disclosure of the authentication secret to an impostor verifier, without depending on the user noticing anything.
Three properties make passkeys phishing-resistant in a way OTP can never be. The credential is bound to the relying party's origin, so it will not be presented to a lookalike domain even if the user is fooled into visiting one. The private key never leaves the authenticator, so there is no shared secret to intercept and replay. And the authentication ceremony requires a user gesture on the authenticator itself, which prevents silent server-side impersonation.
For financial services, the stronger variant is the device-bound passkey. A device-bound passkey lives on a specific device and does not sync across the customer's iCloud Keychain or Google Password Manager. This matters when a bank needs to know that the credential it is talking to today is the same credential it talked to yesterday. Sync makes the user experience smoother. Device binding makes the assurance stronger. Ideem builds device-bound passkeys for financial institutions specifically because the assurance question is the one that matters at the regulator's table.
No financial institution rips out SMS OTP overnight. The shift is staged, and the staging is what differentiates a successful migration from a stalled one.
A workable sequence looks like this. Stand up phishing-resistant authentication as an opt-in for engaged customers first. Move high-value actions like wire initiation, beneficiary additions, account recovery, and password resets to the stronger factor before moving session-level login. Track the proportion of authenticated sessions that still rely on OTP and set a quarter-by-quarter glide path downward. Treat SMS OTP as a fallback for legacy customers, not a default for new ones, and document the migration plan so audit and risk teams have something to point to.
The regulatory tailwinds help here. The Reserve Bank of India's direction on alternative authentication factors, the UAE Central Bank's OTP directive, the Bangko Sentral ng Pilipinas' Circular 1213, the European Banking Authority's PSD3 work, and NIST's own guidance all point in the same direction: phishing-resistant authentication is becoming the table-stakes posture, and OTP is becoming the legacy channel.
It is easy to read the OTP retirement story as a compliance burden. The institutions moving first are framing it differently. Phishing-resistant authentication reduces fraud losses, reduces support volume around password resets and lockout calls, reduces SMS delivery costs, and gives customers a faster login. Each of those is a measurable outcome that lives outside the security org and matters to operators and CFOs.
The institutions that hold OTP as the default for the next three years will be the institutions paying for that decision through fraud, support, and eventually regulatory pressure. The institutions that move now will be the ones with the cleaner story to tell when the next update lands. OTP did its job. It is time to retire it well.
NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management
NIST 800-63 Digital Identity Guidelines FAQ
Microsoft Security: Email threat landscape Q1 2026 trends and insights
Microsoft Security: Defending against evolving identity attack techniques
Proofpoint: The Evolving Threat of AiTM Phishing Attacks
Sekoia.io: Global analysis of Adversary-in-the-Middle phishing threats
Most orgs running OTP-based MFA have 3–4 exploitable gaps they don’t know about. Our Authentication Assessment takes 2 minutes and shows you exactly where you stand — plus a phased migration roadmap.
Take the Assessment →Built by Ideem
Device-bound passkeys and A2A payment authentication. One SDK. No OTPs, no redirects.
Our 2-minute assessment scores your authentication setup and shows you exactly where the improvements are.
See Your Score →