SIM swap
The transfer of a phone line to a SIM card someone else controls. What it is, how it differs from phishing a code, how the attack runs, and what is left for the organization that depends on that number.
What SIM swapping is
SIM swapping is the takeover of a person's phone line by a third party, who gets the carrier to transfer the number to a SIM under their control. From that moment on, the calls and messages for that line, including one-time codes, arrive at the attacker's device.
There's no intrusion into any system of the organization. Nor is the victim deceived, at least not in the decisive step. What gets breached is a third party's identity verification process: the phone carrier's.
That makes SIM swapping an awkward case. The affected organization had no part in the control that failed, but it's the one that loses.
What gets stolen isn't the phone or the account. It's the line, and with it everything the number vouches for: the OTP codes that arrive by SMS and the validations a service performs by calling or texting that number.
It's not phishing a code, and the difference matters
The two routes end up in the same place — an attacker holding the code — but they're stopped with different controls.
- Phishing a code — the attacker convinces the holder to hand over the OTP they just received. The code passes through the person, and the defense targets the person: education, interface cues, retry limits.
- SIM swapping — the attacker doesn't ask the holder for anything. They convince the carrier, and the code stops reaching the holder. The defense can't rely on the user, because the user is never involved.
That gives the organization the most useful signal: the holder of a hijacked line usually loses service before finding out anything is wrong. The loss of signal precedes the access attempt.
How the attack runs, step by step
The sequence is short and the exploitation window is brief, which explains why it almost always happens outside business hours.
- Gather the owner's data. Name, ID number, address, date of birth and the line's number. They come from accumulated leaks, from social networks or from a prior phishing aimed at filling in exactly those fields.
- Choose the carrier's channel. Physical store, phone support, digital channel or a co-opted employee. The four have different processes and the attacker tries the one that verifies least.
- Request a SIM replacement or a port-out. The usual pretext is a lost phone or a device change. What's presented as proof of identity is the set of data from step 1.
- Pass the carrier's verification. It's the step that decides the whole attack, and it takes place entirely outside the organization that will later suffer the fraud.
- The line activates on the attacker's device. The owner's phone loses service. That's the first sign, and it's usually read as a network failure.
- Trigger account recovery on the services that depend on the number. Bank, email, wallet, social networks. Each one sends its recovery code to the line, which no longer belongs to the victim.
- Receive the codes and operate. With the email taken, the attacker also gains the recovery path for everything else. The incident turns into an account takeover across several services at once.
Step 4 is the only one that matters, and it's not controlled by the organization that loses the money. That asymmetry is the defining feature of this fraud.
The control that decides is outside your organization
It's worth saying plainly because it changes the planning: no measure a bank, a wallet or a platform takes prevents a carrier from handing a line to the wrong person.
What is under the organization's control is the dependency. The useful question isn't how to avoid a SIM swap, but what stops working when one happens. If the answer includes the second factor and account recovery, the phone number became the master key without anyone deciding it explicitly.
There are two variants of the same problem that are usually forgotten:
- Porting to another carrier — the number moves with the person, and the porting process has its own verification, different from the SIM replacement one.
- Number recycling — a line that's been canceled gets reassigned after a period. The new owner inherits the recovery path of the accounts the previous one never updated, without any attack having taken place.
SMS stops being a factor when someone else controls the line
An authentication factor is worth the property it assumes. The SMS OTP assumes that whoever holds the number is the owner. It's an assumption about a third party's records, not a cryptographic proof.
- SMS OTP — falls completely with a SIM swap. It's also the factor most exposed to phishing, because it's a code the person can read and dictate.
- In-app OTP (TOTP) — the secret lives on the device, not on the line. A SIM swap doesn't reach it. It can still be dictated under deception.
- Passkey and FIDO2 credential — the private key is on the device and doesn't leave it. Neither a SIM swap nor a fake page obtains it.
- Biometrics with presence verification — doesn't depend on a delivery channel. It's the factor that most clearly doesn't travel over the phone network.
None of this makes SMS unusable. It's still the lowest-friction factor and the only one available to a significant part of the region's population. What it shouldn't be is the only thing between an attacker and a sensitive operation, or the recovery path when everything else fails.
Where it shows up in an identity journey
SIM swapping doesn't attack sign-up. It attacks the moments when the phone number counts as proof of identity.
- SMS second factor — the code reaches the attacker's SIM and the possession factor is fulfilled in their favor.
- Access recovery — the "I forgot my password" flows that send a link or a code to the registered number.
- Transaction confirmation — the authorizations a bank validates with a message to the declared phone.
In all three cases the organization is delegating a segment of its authentication to a third party: the mobile carrier, which manages who controls the line through its own processes and its own support channels.
Who it affects and what it costs
SIM swapping targets accounts of known value, so the target is usually chosen before step 1.
- Financial services and digital wallets — transfers and balance draining, with the peculiarity that they arrive with a correctly validated second factor.
- Crypto assets — the case where the operation is irreversible and the attacker's incentive is at its highest.
- Telecommunications — the carrier faces the claim over a process of its own, and in several countries in the region the regulatory exposure over verification at signup and line replacement.
- Retail and gaming — recovery of accounts with a balance or with stored payment methods.
The operational cost has a characteristic shape: the organization receives a claim over an operation its records show as legitimate and correctly authenticated. Reconstructing what happened requires signals that authentication alone doesn't keep.
What controls stop it
The list splits in two, and the more decisive half isn't sold by any identity provider.
On the phone carrier's side, and the regulator's.
- Reinforced verification for SIM replacement and porting — physical presence, biometrics or additional factors before moving a number.
- Waiting period after a SIM change — a deliberate delay before the line receives messages from financial services. It breaks the attack window, which is short by design.
- Port-out lock at the owner's request — available in some markets, almost unknown among users.
- Internal control over store and channel staff — step 2 is often not deception but a co-opted employee.
On the side of the organization that depends on the number.
- Querying line-change signals — there are services that report whether a SIM was replaced or ported in recent days. They're bought from telecom data aggregators, not from identity providers, and their coverage varies a lot by country and carrier.
- Factors that don't depend on the line — TOTP, passkeys or biometrics with presence verification.
- Identity re-verification on account recovery — regaining access requires proving again who the person is, not just receiving a code. It's the control that closes step 6.
- Cooling-off period after a change of factor or contact details — a delay before enabling sensitive operations after a change.
- Notification to the previous channel, not the new one — notifying the change to the email and number that were registered before. It seems like a detail and it's one of the few notices the victim may get to see in time.
- Step-up on the sensitive operation — asking for presence again at the transfer, not only at login.
- Device and session signals — new device, atypical behavior, accelerated recovery sequence.
A team that wants to cover this fraud in full needs at least one telecom data provider and a conversation with the carriers in its market. Neither is solved by an authentication vendor.
How VU approaches it
VU works on the dependency, which is what the organization does control.
Authenticate supports seven factors: face, TOTP, SMS OTP, email OTP, magic link, password and identity document. The fact that the SMS OTP is in the catalog is information, not a disclaimer: the choice of factor belongs to the organization, and this page exists so it's made knowing what happens when the line changes hands.
Biometric re-verification on account recovery is the piece that closes step 6. If getting back in requires proving presence with Verify, holding the number is no longer enough. Liveness detection is certified by iBeta at Level 2 of its testing program, which applies the methodology of the ISO/IEC 30107-3 standard.
On subsequent behavior, Protect against fraud evaluates device and session signals, which is what allows a recovery followed by a transfer to be looked at with a different criterion.
Frequently asked questions
It's the transfer of a person's phone number to a SIM card controlled by a third party, done without their consent. Once completed, the calls and messages for that line reach the attacker, including the one-time codes many services send by SMS to confirm identity or authorize transactions. The original holder loses service on their own device.
In who gets deceived. In phishing a code, the holder receives the message and hands it over. In SIM swapping, the deception happens at the mobile carrier and the holder never sees the code, because it stops reaching them. That's why controls focused on warning the user don't cover this case.
No. SIM swapping is a method and an account takeover is the outcome: control of someone else's account. Hijacking a line is one of the routes that leads to that outcome, alongside phishing and credential stuffing. Naming them separately helps, because each route gets cut off in a different place.
Through loss of service. The phone stops having network signal even though the device works, because the line was activated on another SIM. The problem is that this symptom gets confused with a network failure, and that the attack is usually carried out at night or on weekends, when the carrier isn't attending and the delay in reacting plays in the attacker's favor. Any unexpected loss of service that coincides with password-change or login notifications deserves to be treated as an incident, not as an annoyance.
The attack, no, because the control that fails is the phone carrier's. The dependency, yes. An organization can stop using the number as the sole second factor, can require identity re-verification to recover an account instead of accepting a code, can query an aggregator on whether that line was replaced in recent days, and can impose a cooling-off period before enabling sensitive operations after a change of factor. None of these measures prevents the swap. All of them reduce what the swap achieves.
Cloning copies the data of a SIM card to operate a duplicate, and it's a technical attack against the card. SIM swapping doesn't touch the card: it convinces the carrier to transfer the number to a new SIM through its normal replacement or porting process. That's why SIM swapping is far more frequent. It requires no technical capability; it requires the owner's data and a support channel that verifies little.