Whoever controls a phone number controls every account that trusts it, and criminals can take that control without ever touching the victim's handset. SIM swap fraud moves a victim's number onto a SIM or eSIM the criminal holds; port-out fraud moves it to a different mobile operator. Port out fraud and SIM swaps end the same way: the attacker receives the SMS codes, calls and reset links meant for the victim. This guide goes deeper than the MFA view: how a SIM swap attack works at the operator, the US FCC rules, carrier account protections, SIM swap detection and the CAMARA SIM Swap API, and how banks, crypto platforms, SaaS providers and enterprise teams detect, respond and move off SMS. For the wider picture see the MFA Fatigue and Bypass Guide. It is written for fraud, identity and security teams, at concept level for defenders.
Key takeaways
- The attack happens at the operator, not on the phone. A SIM swap or port-out is an account change at the mobile operator, so handset security does nothing to stop it.
- The phone number is a restricted authenticator. NIST SP 800-63B-4 says verifiers SHOULD consider device swap, SIM change and number porting before sending a code.
- US operators now have explicit duties. FCC 23-95 requires secure authentication before SIM changes and port-outs, immediate notice to the customer, a free account lock, staff training and three years of records.
- A SIM swap check is cheap and fast. The CAMARA SIM Swap API answers "has this number's SIM changed in the last N hours?" with one boolean, so checking before every SMS code is practical.
- Detection buys time; removing SMS removes the risk. For high-value accounts the durable fix is passkeys or other phishing-resistant methods for sign-in and recovery.
How SIM swap and port-out fraud work
A mobile number (the MSISDN) is linked in the operator's systems to a subscriber identity on a SIM (the IMSI). A SIM swap, also called SIM hijacking or SIM jacking, re-points the number to a new SIM card or eSIM profile. Operators do this legitimately every day for lost and upgraded phones, and the process is built to be quick for a customer who may have no working phone, which is what makes it attractive. MITRE ATT&CK records the technique as T1451 SIM Card Swap in the Mobile matrix, under Initial Access, with LAPSUS$ and Scattered Spider as procedure examples.
The FBI's public service announcement I-020822-PSA describes three routes into the operator:
- Social engineering: the criminal impersonates the victim to a store or call centre agent, using personal data from breaches, phishing or social media, and claims a lost or broken phone.
- Insider threat: the criminal bribes an operator employee to carry out the change.
- Phishing of operator staff: employees are tricked into installing malware that gives the criminal access to the systems that perform swaps.
Two further routes follow the same logic: taking over the victim's online operator account where self-service SIM or eSIM activation is allowed, and abusing authorised third-party retailers, whose calls the FBI asks operators to authenticate. Once the change completes, the victim's phone loses service and the criminal receives their calls and SMS codes. That is why a SIM swapping attack is usually the middle of a fraud, not the end.
SIM swap, port-out and eSIM swap compared
| Variant | What changes | Who performs it | What the victim notices | Main carrier control |
|---|---|---|---|---|
| SIM swap (SIM card swap) | Number moved to a new physical SIM | The victim's own operator | No service; possibly an operator notice | Strong authentication before SIM change; account lock |
| Port-out fraud (number porting fraud, port out scam) | Number moved to a different operator | The gaining operator requests it; the losing operator releases it | No service; port-out notice if sent | Number port out protection: transfer PIN, port freeze |
| eSIM swap | New eSIM profile activated on another device | The victim's operator, via app, online account or store | No service | As SIM swap, plus strong authentication on self-service activation |
| Mobile network operator fraud by insiders | Any of the above, by a bribed or compromised employee | Operator staff | As above | Least privilege on swap tools, monitoring |
eSIM fraud: the FCC notes that "An eSIM card cannot be stolen without stealing the phone", but the account-level swap remains: whoever can persuade the operator, or sign in to the customer's operator account, can provision a profile to their own device. The FCC rules define a SIM as "a physical or virtual card", so they read across to eSIM changes.
What the number unlocks, and why criminals pay for it
A swapped number is the key to accounts that use the phone for sign-in codes, password reset or transaction approval. The usual sequence is password resets on email and financial accounts, contact and recovery changes, then drained balances, moved cryptocurrency or new credit. The FBI advises people not to post details of cryptocurrency holdings online, because such posts help criminals pick targets. IC3 recorded 1,075 SIM swap complaints with US$48.8 million in losses in 2023, 982 with US$26.0 million in 2024 and 971 with US$17.4 million in 2025. These are IC3 complaints only, so treat them as a floor.
For the broader takeover picture see the Account Takeover Prevention Guide.
Carrier protections and the FCC SIM swap rules
The FCC's Report and Order FCC 23-95 (WC Docket No. 21-341), adopted on 15 November 2023, amended the CPNI and number portability rules at 47 CFR 64.2010 and 52.37 for wireless providers and resellers, prepaid and postpaid. The rules took effect on 8 January 2024, with some information-collection provisions held back pending Office of Management and Budget (OMB) review; compliance was tied to the later of six months or OMB completion, so confirm the current compliance status with the FCC before quoting a date.
| Requirement | What FCC 23-95 says | What it means in practice |
|---|---|---|
| Secure authentication | Methods "reasonably designed to confirm a customer's identity" before a SIM change or port-out; readily available biographical, account, recent payment and call detail information do not qualify | Date of birth or billing address alone is no longer enough. SMS is not banned but encouraged only within MFA. Methods reviewed at least annually |
| Failed attempts | Procedures for failed SIM change authentication "reasonably designed to prevent unauthorized access" | Lock-out or escalation; methods left to the operator |
| Customer notification | Immediate notice before a SIM change or port-out is carried out, by a method reasonably designed to reach the customer | Email, app push or call: a text to the swapped number reaches the criminal |
| Account lock | Free, customer-elected lock against SIM changes and port-outs; high-risk customers may be locked proactively with notice | The "port freeze" or "SIM lock" customers should switch on |
| Staff and CPNI | Training for staff handling SIM change and port requests; inbound-contact staff cannot see CPNI until the customer is authenticated | Limits what a social engineer or bribed agent can see |
| Records | Three years: SIM change requests (successful, failed, fraudulent), time to remediate, complaints, authentication measures | Operators can measure their fraud rate; the FCC can request it |
| Victim support | Easy fraud reporting, prompt investigation and free documentation of the fraud on request | Evidence for banks and police |
The FCC declined to mandate specific methods, NIST conformance, redress or operator liability, and compliance is not a safe harbour.
SIM swap protection for customers: PINs, transfer PINs and locks
- Carrier account PIN: a passcode required for account changes, recommended by ATT&CK mitigation M1011 and the FTC. It stops casual impersonation, not a bribed insider.
- Number transfer PIN: some operators issue a one-time PIN, available only after signing in, that must accompany a port-out request, so porting requires control of the account.
- Port freeze or account lock (number port protection): the FCC-mandated lock blocking SIM changes and port-outs until removed. The strongest customer-side control.
- SIM PIN on the handset: stops a stolen physical SIM working in another phone, but does nothing against a swap at the operator.
United Kingdom: porting uses a Porting Authorisation Code (PAC) that customers can request by text under Ofcom General Condition C7. In a 2018 letter Ofcom told providers they may add authentication checks to text requests and withhold PACs from numbers flagged as a fraud risk.
SIM swap detection for relying businesses
Operator controls reduce SIM swaps but do not tell a bank or app that one has happened; that is the job of sim swap detection on the relying side. NIST SP 800-63B-4 Sec. 3.1.3.3 says "Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior)" before using the phone network, and SP 800-63A-4 Sec. 3.2 lists "SIM swap detection" among the fraud checks identity proofing services SHOULD run: "Confirm that the phone number used in the identity proofing process has not been recently ported to a new user or device".
The CAMARA SIM Swap API (a SIM swap detection API)
The CAMARA project, which publishes open operator network API definitions, maintains the SIM Swap API in its Number Insights sub-project; the latest public release at the time of writing is r3.3 (Fall25), with sim-swap v2.1.0 and sim-swap-subscriptions v0.3.0. Any event that associates the number with a new SIM counts: a replacement card, a port keeping the number, an extra SIM on the number or a new subscription.
| Operation | Input | Output | Typical use |
|---|---|---|---|
| POST /check | phoneNumber; maxAge in hours (1 to 2400, default 240) | swapped: true or false | Real time SIM swap detection before sending an OTP, approving a payee or resetting a password |
| POST /retrieve-date | phoneNumber | latestSimChange timestamp, or null with a monitoredPeriod in days | Risk scoring that weights how recent the change was |
| sim-swap-subscriptions | Event subscription (early v0.x release) | SIM swap event notifications | Proactive holds on high-value customers |
Implementation details: access uses OAuth scopes sim-swap:check and sim-swap:retrieve-date, and three-legged tokens are mandatory where personal data is processed and users can opt in or out (the number then comes from the token, not the request). Operators may reject a maxAge beyond their legal retention with 400 OUT_OF_RANGE, and a null date with a monitoredPeriod means no swap in that window. Coverage depends on which operators expose the API in each market, so design the sim swap check for "no answer" as well as yes and no.
Signals beyond the API
| Signal | Source | What it suggests | Caveat |
|---|---|---|---|
| Recent SIM change or port | Operator API or messaging provider | Number may be on a criminal's device | Upgrades and lost phones look the same |
| Operator or line type change | Number lookup | Number ported or became virtual | Customers do switch operators |
| Number tenure on the account | Your records | Recently changed number is less trustworthy | New customers always have short tenure |
| New device with SMS reset | Device binding, app telemetry | Reset from a device never seen before | Combine with the SIM signal |
| SIM change on a managed phone | MDM or EMM (ATT&CK M1012) | A staff member's SIM changed | Enrolled devices only |
Decision guidance: acting on a SIM swap risk signal
A positive check is a sim swap risk signal, not proof of fraud. Decide in advance what each action does with it.
| Action being protected | Suggested sim swap check window | If swapped |
|---|---|---|
| Routine sign-in with SMS as second factor | 24 to 72 hours | Require a non-SMS factor or device-bound credential; otherwise limit the session to low-risk actions |
| Password or MFA reset via SMS | 7 days or more | Do not complete by SMS; move to stronger recovery or verified support |
| Phone number or email change | 7 days or more | Require an existing strong factor; notify all old channels; apply a cooling-off period |
| New payee, withdrawal or crypto transfer | 7 to 14 days | Hold for review or out-of-band confirmation through a channel not tied to the number |
These windows are starting points to tune against your own false positive data, within the operator's retention limit.
- Small organisations: without operator API access, stop SMS being the only recovery route, notify email and app on every number change, and hold high-value actions for a day after one.
- Large consumer businesses: check at every SMS send and high-risk change, log the result with the event and feed it to the fraud model rather than hard-blocking; track false positives by operator and market.
- Workforce: SMS should not be a sign-in or recovery method for administrators, finance approvers or help-desk staff at all.
Moving off SMS OTP
SP 800-63B-4 requires a service using the phone network for authentication to offer at least one non-restricted alternative, give meaningful notice of the risk, cover it in the risk assessment and keep a migration plan. Changing the registered number counts as binding a new authenticator, so it needs the same assurance as enrolling one.
- Remove SMS from recovery first: SMS recovery lets one swap reset every other factor. Use a second passkey, recovery codes or identity verification instead. See the Account Recovery and Help Desk Security Guide.
- Offer passkeys and in-app approval: both are bound to a site or registered device and do not move with the number. See the Passwordless and Passkeys Guide.
- Retire SMS per segment: staff and high-balance customers first, then everyone with an alternative enrolled, keeping SMS as a notification channel only.
Where identity fits
Phone numbers creep into shared and machine access: a team mobile receiving codes for a shared admin account, SMS on a cloud root or domain registrar account, or a virtual number an automation uses to "receive the code". Nobody is watching for a lost signal on these. Replace shared SMS factors with hardware keys held by named people, and give automations their own workload credentials. See the Phishing-Resistant MFA Guide.
How to implement: a phased rollout
- Map phone dependence (weeks 1 to 2): list every flow that sends a code or trusts the number (sign-in, recovery, payee approval, contact change, support verification) and count SMS-only users.
- Add notifications and cooling-off (weeks 2 to 4): notify email and app on every number change and SMS reset; hold payouts and contact changes for a set period afterwards.
- Run the SIM swap check in report-only mode: log results at each SMS send and high-risk change without acting, and measure how often it fires and how many fired cases prove fraudulent.
- Enforce on the riskiest actions first: recovery, number change and withdrawals; keep sign-in in monitor mode until false positives are understood. Brief support agents at the same time.
- Remove SMS for staff and high-value customers: phishing-resistant methods for privileged staff, passkeys for customers on a dated plan.
- Roll back safely: every rule can return to report-only, with a manual override through verified support. If the API is unavailable, fall back to your previous risk rules rather than failing open on high-risk actions.
Detection, response and recovery
What to monitor
- Swap then reset: SMS-based password or MFA reset within hours of a positive SIM swap check, the clearest sign of SIM swapping in progress.
- Change cascade: email, phone and recovery options changed in one session, followed by a payee or withdrawal.
- Support contacts: callers asking to change the number or bypass MFA soon after a swap signal; at operators, repeated failed SIM change authentications on one account.
Responding to a suspected SIM swap
- Contain: freeze outbound payments, revoke sessions and tokens, and disable SMS as a factor until the number is recovered.
- Reach the customer another way: email, in-app messaging or a verified alternative number, never the swapped number.
- Recover the number: the customer asks the operator to restore it and turn on the account lock; US operators must give free documentation of the fraud on request.
- Restore with strong factors: reset the password, remove attacker-added methods, payees and devices, re-enrol with passkeys or an authenticator app.
- Report: the FBI asks US victims to report to IC3 and their local field office; label the case for your fraud models.
Metrics that show it is working
| Metric | Target direction | Why it matters |
|---|---|---|
| SMS sends and high-risk changes preceded by a SIM swap check | Towards 100% where coverage exists | Shows the control is in the path |
| Confirmed SIM swap takeovers per 100,000 active accounts | Falling | The outcome measure |
| Users and staff whose only second factor is SMS | Falling | Measures exposure |
| High-value accounts with SMS-based recovery | Zero | Closes the most damaging path |
| Median time from swap signal to account containment | Minutes, not hours | Losses happen quickly after the swap |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-63B-4 | Sec. 3.1.3.3 (PSTN), restricted authenticators | Risk indicators before SMS, number change as authenticator binding, alternatives and migration plan |
| NIST SP 800-63A-4 | Sec. 3.2 CSP fraud management | SIM swap detection and phone tenure checks during identity proofing |
| MITRE ATT&CK (Mobile) | T1451 SIM Card Swap; M1011, M1012; DET0658 | Threat modelling, carrier PIN guidance, SIM change monitoring on managed devices |
| FCC 23-95 | 47 CFR 64.2010 and 52.37 as amended | US operator obligations for SIM changes and port-outs |
| NIST SP 800-53 Rev. 5 | IA-2, IA-5, IA-12, IR-4 | Authentication, authenticator management, identity proofing, incident handling |
| ISO/IEC 27001:2022 Annex A | 5.17 Authentication information; 8.5 Secure authentication | Issuing, changing and recovering authenticators |
Common failure patterns
- Sending the "your number changed" alert by SMS: the notice lands on the criminal's device. Notify every other channel.
- Checking at sign-in but not at recovery: the SIM swap check runs on login, while the password reset flow still trusts any SMS code.
- Support agents as the override: a caller who fails the swap check is let through after reading back breached personal details. Data exposed through support channels, as in the Coinbase insider breach, is what impersonators use.
- Treating a negative check as clearance: no swap does not mean the session is genuine; the code may still have been phished.
- Passkey enrolled, SMS left on: users add a strong method but keep SMS as a fallback, so the swap path stays open.
Practitioner checklist
- Inventory every flow that sends SMS or voice codes or trusts a phone number, including support verification.
- Run a SIM swap check before each SMS code, recovery, number change and high-value transaction where operator coverage exists.
- Define response by action: step up on sign-in, refuse SMS recovery, hold payouts after a recent swap.
- Treat a phone number change as binding a new authenticator and notify every other registered channel.
- Remove SMS from recovery for high-value customers and from sign-in and recovery for administrators and help-desk staff.
- Offer passkeys or app-based approval to every customer currently on SMS, with a migration plan.
- Ask high-risk staff to enable their operator's account lock and PIN, and monitor SIM changes on managed devices.
- Train support agents that a swap signal cannot be overridden by knowledge questions.
Standards and references
- Federal Register (FCC): Protecting Consumers From SIM-Swap and Port-Out Fraud
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-63A-4 Identity Proofing and Enrollment
- CAMARA Project: SimSwap API repository
- FBI IC3: Criminals Increasing SIM Swap Schemes to Steal Millions of Dollars from US Public
- MITRE ATT&CK: T1451 SIM Card Swap
- FBI IC3: 2025 Internet Crime Report
- FTC: SIM Swap Scams: How to Protect Yourself
Related NHI Mgmt Group resources: MFA Fatigue and Bypass Guide · Account Takeover Prevention Guide · Account Recovery and Help Desk Security Guide · Passwordless and Passkeys Guide · Customer IAM (CIAM) Guide