Beyond SMS OTP: SIM Swaps, OTP-Stealing Apps and Stolen Sessions

SMS OTP is no longer an adequate second factor for digital banking, and replacing it with a stronger login factor is only half the fix. It fails three ways. The phone number gets moved to an attacker's SIM. The customer's device gets compromised and the OTP is read where it lands. Or the attacker skips login entirely by stealing an already-authenticated session. Stronger authenticators close the first two. Only session controls close the third.

What the regulators and standards bodies say

FIU-Nepal has documented the problem. The FIU-Nepal Strategic Analysis Report 2024 on Cyber-Enabled Frauds states that "the ease of mobile SIM clone fraud has also created vulnerability in payment systems." It notes that the mobile number is used for OTP and two-factor authentication, and that if mobile service providers are tricked into providing an existing number to fraudsters, they "can easily access the account of customers." The same report describes malicious apps, disguised as legitimate ones, that give fraudsters control of the device and access to "messages/OTPs received prior to and after the installation." Fraud by tricking victims into sharing OTPs ranked among the most reported cyber-enabled fraud typologies.

NIST has restricted SMS. NIST SP 800-63B-4, finalized in July 2025, classes out-of-band authentication over the public switched telephone network as a restricted authenticator (Sec. 3.1.3.3). Under Sec. 3.2.9, a credential service provider using a restricted authenticator must:

• Offer subscribers at least one alternative authenticator that is not restricted
• Give subscribers meaningful notice of the restricted authenticator's security risks
• Address the additional risks in its risk assessment
• Develop a migration plan for the possibility that the restricted authenticator will not be acceptable in the future

Sec. 3.1.3.3 also says verifiers should consider risk indicators such as "device swap, SIM change, number porting, other abnormal behavior" before relying on the phone network.

Neither OTP nor out-of-band is phishing-resistant. 800-63B-4 says so plainly for both. At AAL2, verifiers "SHALL offer at least one phishing-resistant authentication option." At AAL3, phishing resistance is required.

The third failure: the session

A customer who authenticates strongly and then has their session token copied is still compromised. Malware that copies browser session data lets an attacker reuse a live session without ever seeing a login prompt. 800-63B-4 notes that "hijacking attacks on the session following an authentication event can have similar security impacts" to attacks on authentication itself.

Its session management rules (Sec. 5) are the counter:

• Session continuity is based on possession of a session secret, which must be unavailable to intermediaries
• Bearer session secrets should not be persistent, and should not be stored in insecure locations such as HTML5 Local Storage
• Cookies and "remember my browser" features "SHALL NOT be used instead of authentication"
• Proof-of-possession techniques "mitigate the risk of theft of session secrets"
• Overall and inactivity timeouts limit how long a stolen session stays useful

The failure mode: strong login, weak session

Name the failure mode strong login, weak session. A bank migrates customers to app-based or hardware-backed authentication and declares the problem solved. The session that follows is a long-lived bearer token with no device binding and no step-up for high-risk actions. The attacker never fights the new authenticator. They take the session it produced.

Authentication proves who logged in. Session controls decide whether that proof still means anything ten minutes later.

An illustrative scenario

This is a composite built from the typologies FIU-Nepal describes, not a reported incident. A small business owner's number is moved to a new SIM after a social-engineering call to the carrier. The owner's phone loses signal. Within the hour, password resets and OTP-confirmed transfers run from a device the bank has never seen. The bank's controls checked the OTP and found it correct. Nothing checked whether the SIM had just changed, or whether the device was new.

The migration path

Ordered steps for digital banking and AppSec leads:

1. Inventory every flow that sends an SMS OTP. Login, transfer confirmation, beneficiary addition, password reset, device enrollment. Reset and enrollment flows are often the weakest and the least reviewed.
2. Offer a non-restricted authenticator to every customer. App-based cryptographic authenticators or hardware-backed keys. 800-63B-4 Sec. 3.2.9 expects this whenever a restricted authenticator stays in use.
3. Make the strongest factor mandatory where loss is largest. Beneficiary addition, limit increases and high-value transfers should require the phishing-resistant option, not accept SMS as an alternative.
4. Treat device and SIM change as risk signals. Where carrier data is available, check for recent SIM change or porting before trusting an SMS OTP. On a new device, apply the enhanced measures FIU-Nepal recommends: cooling-off periods, transaction limits and limits on the number of devices.
5. Bind sessions to the device. Use proof-of-possession where the platform supports it. Keep bearer tokens short-lived and out of insecure storage.
6. Step up inside the session. Re-authenticate before sensitive actions, regardless of how recently the user logged in.
7. Write the migration plan down. Sec. 3.2.9 asks for one. It is also the document an auditor or regulator will ask to see.

What to test

A VAPT engagement or internal review of a digital banking stack should cover, at a defensive level:

• Whether password reset and device enrollment can be completed with SMS OTP alone
• Whether session tokens survive logout, password change or device change
• Whether session secrets are stored client-side in locations readable by scripts
• Whether high-value actions re-check authentication or rely on the original login
• Whether fraud monitoring flags transactions from a newly enrolled device shortly after a SIM or number change

FIU-Nepal's report also documents how mule accounts are validated before funds move. Detection of that pattern is covered in The "Re. 1 Ping". For why training customers to spot phishing won't substitute for these controls, see The 2% Result.