Securing user accounts used to feel simple. Add a second factor, send a code to someone’s phone, done. For years, SMS one-time passwords were good enough — they were easy to implement, worked on any phone, and required no app installs. The problem is that the threat landscape has moved well past what SMS was designed to handle.
Today, attackers don’t need to crack passwords or run brute-force attacks. They go after the SMS code itself. And the uncomfortable truth is that SMS was never built with security in mind. It’s a telecommunications protocol from the 1970s carrying sensitive authentication codes in 2025. The gap between what SMS can offer and what attackers can do has grown wide enough that several major standards bodies have formally deprecated it.
This isn’t just a theoretical concern. SIM swapping, SS7 exploits, and real-time phishing proxies are all active threats used in financial fraud, corporate breaches, and ransomware campaigns today. Let’s look at exactly how these attacks work, and what actually holds up against them.
How Attackers Exploit SMS OTPs
SIM Swapping
SIM swapping is exactly what it sounds like: the attacker convinces your mobile carrier to transfer your phone number to a SIM card they control. They don’t need to know your PIN or have physical access to your phone — they just need enough personal information to impersonate you to a customer service representative.
This information is often gathered through social engineering, data breaches, or OSINT (open-source intelligence). Once the transfer goes through, your phone loses service and every call, text, and SMS OTP you receive routes to the attacker’s device. From there, they can request password resets and take over accounts within minutes.
Carriers have implemented some safeguards, but social engineering attacks against customer service staff remain effective, and the damage from a successful SIM swap can be severe.
Adversary-in-the-Middle (AitM) Phishing
Standard phishing steals your password by getting you to type it into a fake login page. AitM attacks go further — they steal your active session even after you’ve entered a valid OTP.
Tools like Evilginx2 and Modlishka act as reverse proxies. The victim visits what looks like a real login page, but all traffic is being relayed through the attacker’s server. When the legitimate site sends an SMS OTP, the victim types it into the fake page, the attacker’s proxy forwards it to the real site, the login succeeds, and the attacker captures the resulting session cookie. The OTP did its job — it just authenticated the attacker.
This attack works in real time and leaves the victim completely unaware that anything went wrong. SMS OTPs offer no protection here because the attacker never had to intercept anything — the victim handed the code over voluntarily.
SS7 Protocol Exploits
SS7 (Signaling System 7) is the protocol used to route calls and messages across the global telephone network. It was designed in 1975 with an implicit trust model — the assumption that only authorized telecom operators would ever have access to it. That assumption no longer holds.
Attackers can purchase SS7 access through certain channels, which lets them silently intercept and reroute SMS messages to any phone number in the world. The victim has no way of knowing this is happening. Their phone still shows full signal and normal operation, but incoming SMS messages are being copied or redirected to the attacker.
This isn’t a theoretical vulnerability — it’s been demonstrated repeatedly by security researchers and has been used in targeted attacks against bank customers in multiple countries.
SMS Interception via Mobile Malware
On Android devices, apps can request permission to read incoming SMS messages. Malicious apps — often disguised as utilities, games, or tools on unofficial app stores — can silently forward OTP codes to a remote server the moment they arrive.
Banking trojans that target SMS codes have been a consistent problem for years. The attacker doesn’t need to intercept anything in transit; they just wait for the code to land on the infected device and read it from there.
What the Standards Say
The security community has been raising concerns about SMS OTPs for years, and regulators have started to act on it.
NIST SP 800-63B — the U.S. federal standard for digital identity — formally deprecated SMS as a secure authentication method. NIST specifically cited the risks of SIM swapping and SS7 interception as reasons why SMS-based out-of-band authentication can no longer be recommended for sensitive applications.
PSD2 (and the upcoming PSD3) — the European payment services directives — require Strong Customer Authentication (SCA) for financial transactions. The requirements around dynamic linking and cryptographic approval favor app-based authentication over static SMS codes, and regulators have been pushing financial institutions to move away from SMS for high-risk actions.
Major tech companies are also accelerating the shift. Microsoft has been pushing users toward its Authenticator app and away from SMS MFA for several years. Google added Passkey support across its platforms. X (formerly Twitter) removed SMS 2FA for non-paying users, effectively forcing many users to adopt app-based alternatives.
Stronger Alternatives That Actually Work
The goal isn’t just to replace SMS — it’s to use authentication that’s resistant to the attacks that SMS is vulnerable to. Here’s what that looks like in practice.
Passkeys (FIDO2 / WebAuthn)
Passkeys are the most robust option available today. They’re built on the FIDO2 and WebAuthn standards and replace both passwords and OTPs with a cryptographic key pair. One key lives on the server; the other is stored securely on your device and never transmitted.
When you authenticate, your device signs a challenge from the server using the private key, and you confirm with a biometric (Face ID, Touch ID, Windows Hello) or device PIN. The critical detail: passkeys are cryptographically bound to the specific domain they were created for. A passkey for bank.example.com will not authenticate on a phishing site, even if that site looks identical. This makes them completely immune to AitM phishing.
Passkeys work on iPhones, Android phones, Macs, Windows PCs, and major browsers. Adoption is expanding quickly, with Google, Apple, Microsoft, GitHub, and many financial services supporting them.
Hardware Security Keys
Physical security keys — like YubiKeys or Google Titan keys — operate on the same FIDO2 principles as passkeys. The private key never leaves the hardware token, and authentication requires physically tapping or plugging in the device.
Because there’s no code to intercept or phish, hardware keys effectively neutralize SMS-style attacks, phishing, and credential stuffing. They’re the preferred option for high-value accounts, privileged admin access, and anyone who needs strong guarantees regardless of what device they’re using.
TOTP Authenticator Apps
Time-based one-time passwords (TOTP) generated by apps like Google Authenticator, Aegis (Android), or Raivo (iOS) are a meaningful upgrade over SMS. The codes are generated locally on your device using a shared secret, with no cellular network involved.
This eliminates the SIM swapping and SS7 risks entirely. The weakness is that TOTP codes can still be phished — if an attacker’s fake login page captures your code in real time, they can use it before it expires. But TOTP is significantly more secure than SMS and is a practical intermediate step for organizations that aren’t ready to deploy passkeys yet.
Push Notifications with Number Matching
Enterprise identity providers like Duo Security and Microsoft Entra use push notifications sent to a registered mobile app. The original problem with push-based MFA was “MFA fatigue” — attackers would spam approval requests until an exhausted user tapped “Approve” without thinking.
Number matching addresses this directly. When a login is attempted, a 2-digit number appears on the login screen. The user must type that specific number into their mobile app to approve the request. This confirms the user is actively looking at the login screen and not just approving a random notification, which stops fatigue-based attacks.
How to Move Away from SMS
Deprecating SMS authentication takes planning, especially if you have a large user base that expects to receive a code via text.
Step 1: Audit what you have. Identify every system, application, VPN, and password recovery flow that currently uses SMS. You can’t replace what you haven’t mapped.
Step 2: Roll out alternatives first. Add TOTP app support, passkey enrollment, and hardware key options before removing SMS. Give users time to switch on their own terms.
Step 3: Communicate clearly. Users will push back if the change feels arbitrary. Explain why SMS is being phased out in plain language — it’s about protecting their accounts, not just an internal IT decision.
Step 4: Phase out SMS gradually. Start by requiring stronger MFA for privileged accounts — administrators, executives, anyone with elevated access. Then extend the requirement to high-risk actions like password resets and large financial transfers. Finally, set a hard cutoff date for general users.
The Bottom Line
SMS OTPs aren’t just weakening — they’re actively exploited. The attacks are documented, the tooling is available, and the real-world damage is measurable. Standards bodies have deprecated SMS, major tech companies are migrating away from it, and attackers have optimized their techniques to exploit it at scale.
Switching to passkeys, hardware tokens, or even TOTP apps isn’t a minor upgrade — it’s closing a door that’s been left open for years. The transition takes effort, but the alternative is continuing to rely on an authentication method that sophisticated attackers treat as a solved problem.
