Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
Most teams already know SMS codes are weak authentication factors. They still leave SMS as the account recovery path, and that's where SIM swapping rears its head. The attack moves a victim's phone number to a SIM the attacker controls, so the calls, texts, and one-time codes intended for that person arrive on the attacker's device instead.
Calling your carrier helps individuals after the fact but the damage has already been done. If you build an app, the fix for SIM swapping is to stop treating SMS codes as identity. Remove SMS as a recovery path first, then as a login factor, and replace it with phishing-resistant methods like passkeys, email magic links, or device biometrics.
At a glance
SIM swapping moves a victim's phone number to an attacker-controlled SIM, so the attacker receives their calls and texts.
The attack intercepts SMS one-time codes, which lets an attacker bypass SMS-based MFA and take over accounts.
Carrier-side controls protect the individuals who enable them, not your users as a group, so the durable defense for SIM swapping has to sit at the authentication layer.
Passwordless and phishing-resistant methods like passkeys and email magic links remove the SMS dependency the attack exploits.
What is SIM swapping?
SIM swapping is an attack that moves a victim's phone number to a SIM card the attacker controls. The attacker doesn't break into a phone or a network. They instead persuade the carrier to reassign the number, and from that moment every call and text intended for the victim arrives on the attacker's device.
The phone matters only as a delivery channel. Password reset links, account recovery codes, and one-time passcodes all route to whoever holds the number, which turns a single carrier decision into access across dozens of unrelated accounts.
The attack works because of an assumption authentication design has relied on for years: a phone number reliably identifies a person. This is a dangerous assumption. In reality, a phone number identifies a billing relationship with a carrier, and that relationship transfers to anyone persuasive enough on a phone call.
The attack is also called a SIM swap scam or a SIM swap attack, and occasionally SIM hijacking or port-out fraud. The mechanics are the same in each case: control the number, then collect what's sent to it.
How does a SIM swap attack work?
An attacker gathers enough personal detail to pass a carrier's identity check, contacts the carrier while impersonating the victim, has the number ported to a SIM they control, and then intercepts everything sent to it.
The reconnaissance step rarely involves anything exotic. Names, birthdates, addresses, and the last four digits of a payment card circulate in breach dumps and are often enough to begin the attack. Where they're not enough, a phishing message aimed at the victim fills the gaps.
Once recon is complete, the attacker calls the carrier (or walks into a retail store) and asks to move the number to a new SIM. Sometimes the request succeeds through social engineering alone. Sometimes it succeeds because an insider processes it. The FBI's Internet Crime Complaint Center describes the same sequence: once the SIM is swapped, calls and texts divert to the criminal's device, which lets them send password reset and account recovery requests to the victim's other accounts and use the intercepted codes to log in.
The victim's phone loses service at the moment of the port, which is the one visible signal that anything has happened. By then, the attacker is already midway through their account takeover attempts.
Why is SIM swapping so dangerous for your users?
SIM swapping is dangerous because it defeats SMS-based MFA and phone-based account recovery at the same time, and turns one intercepted code into a full account takeover.
The damage comes from the authentication decisions built on top of the phone number. If your login flow sends a one-time code by SMS, an attacker holding the number receives it. If your account recovery flow lets a user prove ownership by receiving a text, an attacker holding the number can reset the password outright and lock the real user out.
Recovery is usually the weaker of the two, and it's where most defenses fail. Teams harden the login path with an authenticator app or a passkey, then leave account recovery as a plain phone-number check. That gap lets the attacker skip the front door entirely and walk in through the side.
The exposure compounds across accounts. A phone number used to recover credentials for an email inbox reveals everything that the inbox contains. Account takeover prevention has to start with the factors themselves, not with detecting the takeover after it's already happened.
In December 2024, CISA published its Mobile Communications Best Practice Guidance, directing organizations not to use SMS as a second factor for authentication, and pointing to FIDO authentication and passkeys instead.
Which authentication methods resist SIM swapping?
Not every factor is equally exposed once an attacker holds the phone number. The table below breaks down which methods still hold up.
Authentication method | SIM swap resistant | Why |
|---|---|---|
SMS one-time code | No | Delivered to the phone number the attacker now controls |
Authenticator app (TOTP) | Yes | Generated on device, not sent over the mobile network |
Push notification | Mostly | Tied to an app instance, though exposed to fatigue attacks |
Email magic links | Mostly | Tied to email inbox ownership, though using SMS as a recovery path for email inboxes leave them open to compromise as well |
Passkeys / FIDO2 | Yes | Bound to the device and origin, nothing to intercept |
Biometrics (device) | Yes | Verified on the device, not tied to the phone number |
How does passwordless authentication stop SIM swapping?
Passwordless authentication verifies a user without a password, using methods such as passkeys, device biometrics, magic links, and authenticator apps. Instead of recalling and typing a secret, the user proves possession of a registered device.
While SMS OTPs are also technically “passwordless”, the codes are still shared secrets that can be phished (via SIM swapping) or coerced from users. More phishing-resistant passwordless methods, including Descope's passkey and magic links options, send nothing to a phone number, so there's nothing for the attacker to catch.
Passwordless methods also remove the two most attacked factors–passwords and SMS codes–while reducing friction at sign-in. Credential stuffing has nothing to stuff, because there's no reusable password to replay from a breach dump. SIM swapping has nothing to intercept. Phishing pages can't harvest a passkey, because the credential is bound to the origin it was created on and won't release to a lookalike domain.
Adoption stats back up the preference for phishing-resistant passwordless methods. Descope's State of Customer Identity 2025 report found that 45% of organizations have already deployed passkeys in one or more apps, and another 27% plan to within two years.
How does biometric authentication protect against SIM swapping?
Biometric authentication verifies a user with a physical characteristic such as a fingerprint or a face scan, checked on the device itself. Device biometrics, if implemented thoughtfully, never transmit biometric data. The scan unlocks a private key stored in the device's secure hardware, and it’s that private key paired with your app’s public key that authenticates users (not their fingerprints).
That design is what makes biometrics resistant to SIM swapping. Nothing is tied to the phone number, and nothing crosses the mobile network.
Using biometric authentication needs thoughtful design of fallback or recovery options. There are still users with devices that are not WebAuthn-compatible, which is the protocol that runs passkeys. If developers end up putting SMS codes as the fallback for those users, they remain vulnerable to SIM swapping.
How do you choose phishing-resistant MFA?
Phishing-resistant MFA uses factors that can't be relayed to an attacker (or they at least make it much harder for the attacker to access credentials).
SMS fails the phishing-resistant test multiple times. SMS OTP codes can be intercepted through a SIM swap, and they can also be phished directly (e.g. a user being socially engineered to share the code with the attacker or typing it into a phishing lookalike page). Authenticator app codes are better, because they never traverse the mobile network, but they remain relayable through social engineering.
When evaluating an authentication stack that resists SIM swapping, some criteria to consider are:
First-class support for methods like passkeys and biometrics
Breadth and depth of authentication methods in general (to offer alternatives and fallbacks)
The ability to change auth methods and logic without an application redeploy or custom code
Flexibility in handling recovery flows
How can you protect your users from SIM swapping?
You can't control your users' carriers, but you can control what your application accepts as proof of identity. Here are some tactics that reduce / remove reliance on phone numbers as identities and that provide defense-in-depth:
Remove SMS one-time codes as a primary login factor.
Remove the phone number as an account recovery path. This is where SMS most often survives a modernization effort, and it's the path attackers prefer.
Adopt passkeys as a primary auth method. A passkey is bound to the device and the origin, so there's no code in transit for anyone to intercept.
Offer device biometrics where hardware supports it. Verification happens on the device and never touches the mobile network.
Add adaptive authentication checks. A takeover attempt usually arrives from a new device in a new location within minutes of a password reset, and adaptive MFA can require a stronger factor exactly there while staying out of the way otherwise.
Add silent network authentication (SNA) where your user base makes it worthwhile. SNA verifies the phone number against the carrier's live records at the network layer, so a fresh SIM swap can be detected before a recovery code is sent.
If you can't remove SMS immediately, demote it. Keep it as a last-resort fallback behind stronger methods, and require re-verification through another channel before it can change account settings.
How are regulations phasing out SMS as an authentication factor?
Regulators have shifted from tolerating SMS-based MFA to actively discouraging it, and in some markets to banning it outright.
In its December 2024 Mobile Communications Best Practice Guidance, CISA states plainly: “Do not use SMS as a second factor for authentication.” The same guidance directs readers toward FIDO authentication and names passkeys as an acceptable alternative.
The Central Bank of the UAE's Notice 2025/3057 banned SMS and email one-time passwords as standalone authentication for licensed financial institutions from March 2026, and shifted liability for 3D Secure fraud involving SMS OTP onto those institutions from July 2025, ahead of the ban.
In New York, NYDFS Part 500 requires multi-factor authentication across covered financial services entities, with a stronger definition of what qualifies following the 2023 amendment. SMS is not banned outright, but the guidance around it is narrowing, and the safer read for a covered entity is to move toward phishing-resistant factors ahead of the next revision.
In the EU, DORA requires financial entities to protect authentication with strong, documented, testable controls. It doesn't prohibit a specific factor, but every SMS auth deployment is still something you have to justify in an audit.
The pattern is consistent: SMS is being demoted from acceptable factor to residual, and in some jurisdictions to prohibited. Applications built to allow authentication factor changes without custom engineering work absorb these transitions cheaply. Applications built around an overreliance on SMS authentication absorb them expensively or risk being out of compliance.
What are the most common mistakes when defending against SIM swapping?
Keeping SMS as a primary factor by using wide coverage as rationale (i.e. “every phone number receives texts”). Coverage is exactly what the attacker is exploiting as well.
Leaving the phone number as a recovery path. This is the most common residue of a partial modernization effort, and the path attackers reach for first.
Treating SIM swapping solely as a carrier problem. Carrier-side controls like port-out PINs help the individuals who enable them, but you can't enable them for your users, and you shouldn't build a security model that assumes they did.
Rolling out passkeys without a considered fallback. If the fallback is SMS, the attacker simply requests it. CISA's guidance flags the related failure directly: enrolling a user in authenticator-based MFA doesn't automatically unenroll SMS, which leaves it in place as “a weak, exploitable fallback mechanism” long after it should have been retired.
Not watching for takeover signals. A recovery request from an unrecognized device, in a new location, minutes after a failed login, is the shape of a SIM swapping attack in progress, and it's also the moment a step-up authentication challenge is worth the friction.
How does Descope help protect against SIM swapping?
Descope is a customer and agentic identity platform that treats phishing-resistant methods as first-class: passkeys, biometrics, and magic links are configured as primary factors, so there's no code in transit for a SIM swap to intercept.
Where SMS has to stay for a transition period, adaptive MFA governs when it's used, and risk signals like impossible traveler and new-device detection can require a stronger factor for a recovery attempt from an unfamiliar device while a routine login stays untouched. Descope Flows, Descope’s visual workflow builder, lets you make changes like moving SMS from primary factor to last-resort fallback as a tweak to the login journey rather than a change to your codebase.
Branch, a home and auto insurance provider serving more than 12,000 independent agents, augmented its existing authentication with Descope passkeys as a phishing-resistant primary method. The rollout reached 25% passkey adoption, exceeding Branch's internal goals, and cut authentication-related support tickets in half. Read the Branch case study.
Start with a Free Forever account to build the flow yourself, or book time with the team to talk through a migration off SMS.
