What is a SIM swapping attack?

A SIM swapping attack, sometimes called SIM hijacking or SIM jacking, is a form of account takeover in which an attacker convinces a mobile carrier to transfer a victim's phone number to a SIM card the attacker controls. Once the swap completes, calls and text messages intended for the victim arrive on the attacker's device. Any account that uses the victim's phone number for authentication, especially via SMS-based one-time codes, becomes reachable.

A close variant is port-out fraud, in which the attacker moves the number to a different carrier rather than to a new SIM on the same one. The end result is the same.

This guide explains how SIM swapping works, why SMS-based multi-factor authentication is no longer considered secure on its own, and what developers building authentication and account recovery flows can do to protect their users.

How a SIM swap attack works

A SIM swap attack typically unfolds in three stages.

1. ‍Reconnaissance. The attacker collects information about the target. Names, dates of birth, addresses, account numbers, and recent transactions are routinely available from data breaches, public records, social media, and phishing. For high-value targets, attackers may also bribe or coerce carrier employees.‍
2. Carrier social engineering. Armed with that information, the attacker contacts the victim's mobile carrier and impersonates the victim, claiming a lost or damaged phone and requesting that service be transferred to a new SIM. Variations include walking into a retail store, calling support, or initiating a port to a different carrier. The attacker's goal is to pass whatever identity check the carrier performs.‍
3. Account takeover. Once the number is on the attacker's device, the victim's phone loses service and stops receiving calls or texts. The attacker then triggers password resets and SMS-based MFA challenges on the victim's email, banking, social media, and cryptocurrency accounts, intercepting every code the carrier delivers. From there, the attacker drains funds, takes over identities, or pivots to higher-value targets.

The most public examples involve cryptocurrency theft and high-profile account takeovers, but the attack scales down too. Anyone whose phone number is reused across consumer accounts is potentially exposed.

Why the phone number is the weak link

The fundamental problem is that the security of every account that relies on a phone number depends on the carrier's identity-verification process, not on the application. Carriers operate at retail scale, with thousands of customer-service agents handling millions of legitimate SIM swap and port requests every year. Bad actors target this workflow specifically because it is the softest path to account takeover.

Two structural problems compound the issue:

• Carrier authentication is uneven. Identity checks vary by channel, by store, and sometimes by individual agent. Knowledge-based questions, the last four digits of a Social Security number, or recent call history are not effective against an attacker who has done their homework.
• The SS7 protocol is exploitable. Even without a SIM swap, attackers with access to telecom signaling networks can intercept SMS and voice calls. This vector is more sophisticated than a SIM swap but produces a similar outcome.

The US Federal Communications Commission adopted new rules in November 2023, which began rolling into effect in 2024, requiring wireless carriers to authenticate customers more rigorously before processing SIM changes and port-outs, to notify customers of these requests, and to offer account locks. The rules raise the bar but do not eliminate the underlying problem, because carriers still have wide discretion in how they authenticate.

Where SMS-based MFA falls short

When an application sends a one-time code by SMS as a second factor, the security of that factor inherits all of the weaknesses above. If the attacker controls the number, they receive the code. The application has no way to distinguish.

Beyond SIM swapping, SMS as an authentication channel has several other documented weaknesses:

• No phishing resistance. Codes can be entered into any login page, including a fake one. An attacker who proxies the real login page can capture both the password and the code in real time.
• No binding to a specific device. SMS is delivered to whatever SIM is currently associated with the number, not to a specific phone the user enrolled.
• Recovery loops. Many applications use SMS for password recovery as well as MFA, which means a successful SIM swap can unlock the account even if the user has a strong password.
• Telephony-network interception. Beyond SS7, SMS is unencrypted in transit, can be cached at intermediaries, and is occasionally exposed by lawful-intercept and routing infrastructure.

NIST recognized these issues years ago. In its Digital Identity Guidelines (SP 800-63B), NIST classifies authentication using the public switched telephone network, including SMS one-time codes, as a "restricted" authenticator. Restricted authenticators can still be used, but applications relying on them are expected to assess and accept the additional risk, offer alternatives, inform users of the risk, and maintain a migration plan toward stronger options.

In practice, that means SMS is acceptable as a backstop but should not be the strongest factor protecting an account.

What developers can do

Most of the protections that matter sit in the application layer. Carriers will keep getting better, but a well-built authentication system should not depend on them.

Offer phishing-resistant authentication

The strongest factors are based on public-key cryptography and bound to a specific device. They are not affected by SIM swaps because they do not involve a phone number at all.

• Passkeys and WebAuthn. Passkeys are FIDO2 credentials backed by the user's device or a synced credential store. They resist phishing because the credential is bound to the relying party's domain and never leaves the device in usable form. For most consumer products, passkeys should be the default factor.
• Hardware security keys. YubiKeys and similar FIDO2 keys offer the same cryptographic guarantees as passkeys with an explicit physical device. They are appropriate for high-assurance contexts and admin accounts.
• Platform authenticators. Touch ID, Face ID, and Windows Hello can satisfy the WebAuthn user-verification requirement without a separate device.

Use TOTP as the SMS replacement

If passkeys are not yet feasible for your audience, time-based one-time passwords from an authenticator app are a substantial upgrade over SMS. The seed never leaves the user's device, the codes are not transmitted over the carrier network, and a SIM swap does not affect them. TOTP is not phishing-resistant on its own, but it is not vulnerable to SIM swaps.

Treat phone numbers as recovery, not as a primary factor

If you must collect a phone number, use it for fraud signals and as one of several recovery options, not as the only path back into an account. Account recovery is where SIM swaps cause the most damage in practice, because users often have a strong password and a passkey but a weak fallback path that defeats both.

Handle phone-number changes as authenticator binding

When a user changes their phone number, treat the change with the same scrutiny as enrolling a new factor. Require step-up authentication using a stronger factor, send a notification to the previous number and to the user's email, and apply a delay before the new number can be used for sensitive actions. NIST guidelines explicitly recommend this pattern.

Watch for SIM-swap signals

Several signals correlate with SIM swap activity and should raise the bar for authentication:

• Recent SIM changes or carrier ports (carrier APIs and fraud data providers expose these signals)
• New device fingerprints
• Geographic anomalies between the request origin and the user's history
• Rapid sequences of password reset, MFA enrollment changes, or contact-info updates
• Authentication from networks associated with prior fraud

When these signals fire, require a stronger factor, delay the action, or notify the user out of band before completing it.

Notify users of sensitive changes

Send a notification any time an authenticator is added, removed, or changed; any time the email or phone number on file is updated; and any time a new device signs in. Send these notifications to multiple channels where possible. Notifications do not stop the attack, but they dramatically shorten the window in which an attacker can operate undetected.

Require step-up auth for sensitive actions

Login is one moment, but account takeovers play out over many actions. High-impact operations like changing the recovery email, withdrawing funds, exporting data, or disabling MFA should require fresh authentication with the strongest factor the user has enrolled, not just a valid session.

What to tell users

Even with the right architecture, users should understand the threat. A short note in the security settings can recommend that they:

• Add a port-freeze or account PIN with their carrier (the major US carriers now support this)
• Avoid using their primary mobile number in public profiles or as a recovery contact across many sites
• Move to passkeys or an authenticator app where the option is available
• Treat unexpected loss of cell service as a possible attack and contact the carrier immediately

The bigger picture

The direction of travel is clear. NIST has formally restricted SMS-based authentication. The FCC has imposed baseline carrier rules. Major platforms have rolled out passkeys broadly, and adoption has accelerated through 2024 and 2025. SMS-based MFA is not yet gone, and probably will not be for a while, but it is no longer a defensible default for new applications.

For developers building new authentication flows, the right move is to design from the start around phishing-resistant factors, treat the phone number as a fragile recovery channel rather than a trusted identifier, and watch for the carrier-level signals that precede a SIM swap. The user does not need to know any of this is happening. They only need to know their account is still theirs in the morning.