SIM swap: chain of attack and controls

A SIM swap moves a victim’s phone number to a SIM card the attacker controls. From that moment, every call and text message to the number goes to the attacker, including one-time codes and recovery links. The attack does not touch your servers or break any cryptography. It exploits the fact that your system treats possession of a phone number as possession of a device, and phone numbers can be reassigned by people outside your control.

Threat models often list SIM swap as a single line with a single mitigation: stop using SMS. That is directionally right but operationally useless for the many services that cannot drop phone-delivered codes tomorrow. A better approach is to treat it as a chain with several links, and to place controls at each link your system can observe.

The chain of attack

Reconnaissance comes first. The attacker needs the victim’s number and enough personal data to pass the carrier’s checks: name, address, date of birth, sometimes the last digits of an identity number. Breach dumps and social media supply most of it. Next comes the swap itself, done by social engineering a store or call-centre employee, by abusing an online portal with weak authentication, or by bribing an insider. The victim notices only that their phone has lost signal, often at night. The attacker then starts recovery flows on every account they can link to the number.

Controls, link by link

At the recon link your options are limited, but you can avoid making things worse. Do not reveal partial phone numbers or enrolment status on login pages, and do not let support confirm personal details to callers. At the swap link you have no direct control, but some carriers and aggregators expose signals indicating that a number’s SIM changed recently; where available, query them before sending a recovery code and treat a recent change as a strong risk factor. Treat the signal’s absence as unknown, not as safe.

At the reset link, which is entirely yours, the strongest control is to stop letting a phone number alone recover an account. Require a second, independent proof: a passkey, a TOTP code, a recovery code, or confirmation through a verified email address. Where that is not possible, delay. A recovery that completes only after a twenty-four-hour hold, with notifications to every other channel, turns a six-minute attack into one the victim has a day to interrupt.

• Never allow phone number changes and recovery in the same session without a hold.
• Notify email and any registered device when a reset starts, not only when it completes.
• After recovery via phone, downgrade the session: no new payees, no contact changes, no credential removal until the hold expires.
• Offer users a way to lock their phone factor so it cannot be used for recovery at all.

A Pinecrest incident, reconstructed

The following timeline is an illustrative example built for this course. On 2026-09-18 at 23:41 local time, patient Joaquín Marrero’s phone loses service. At 23:45 a password reset for his portal account is requested from a new device. The OTP is delivered to +1 555-0187, now on the attacker’s SIM. At 23:47 the attacker sets a new password and tries to change the email address. Pinecrest’s policy at the time allowed this instantly; the attacker read lab results and requested a prescription refill to a new pharmacy. Joaquín discovered it the next morning from the pharmacy’s confirmation call.

After the review, Pinecrest made three changes. Email changes now require the old email to confirm or a forty-eight-hour hold. Phone-based recovery places the session in a reduced mode for twenty-four hours. And recovery attempts trigger an email to the existing address immediately, with a one-click cancel. Rerunning the same timeline against the new policy, the attacker gets a session that can read but not change anything, and Joaquín receives a cancel link at 23:45.

Severity and residual risk

Using the rubric from chapter 6, an unmitigated SIM-swap path to full account control is critical for any service holding health or financial data. With a second independent factor required for recovery, the residual risk drops to medium: the attacker gets nothing without also compromising email or a device. With only delays and notifications, the residual is high, because a victim who is asleep or travelling may miss the window. Record both numbers in the model, so the gap between them is a visible, owned decision.

Finally, rehearse the scenario. Pick a test account, simulate a swap by moving its number to a lab SIM, and walk the recovery flow end to end. Teams are often surprised by which notification never arrived.

Simulate the chain

The simulator runs the SIM-swap chain from this chapter and three sibling attacks. Start with every defense off, then enable number-change confirmation alone: the attack ends at recovery. Turn it off and enable step-up instead: the attacker gets in but cannot move money. Rate limiting does nothing here, because the attacker needs exactly one code.