A SIM swap moves a subscriber’s number onto a SIM the attacker controls. The change is legitimate as far as the network is concerned, which is why it defeats every downstream service that trusts the phone number as proof of identity.
Stage 1 (harden verification) lives mostly in the care, retail, and self-service channels: no swap on knowledge-based answers alone, a customer-set PIN or passkey, notification to the old SIM before the change, and a cooling-off period for high-risk changes.
Stage 2 (monitor identity-change events) and Stage 3 (watch post-swap activity) live in the subscriber identity and AAA layer, which sees the profile change, the first authentication from the new SIM, and every session that follows it.
Regulators now require the first stage in some markets, and the other two are how an operator shows its process actually works. In the US, the Federal Communications Commission (FCC) adopted SIM swap and port-out rules in November 2023 that require secure customer authentication before a SIM change and immediate customer notification when one is requested.
A customer calls the contact center on a Tuesday afternoon. Their phone was stolen, they say, and they have a replacement SIM (subscriber identity module) in hand. They know the account holder’s name, date of birth, and the last four digits of the payment card, which is everything the agent’s script asks for. The agent completes the swap in under four minutes. Eleven minutes later, a bank in another country sends a one-time passcode to that number, and the person who receives it is not the customer.
A SIM swap fraud prevention playbook for operators covers three stages: hardening identity verification at the point of the swap request, monitoring identity-change events for anomalies such as unusual frequency, timing, or channel, and watching post-swap activity closely for the first signs of account takeover.
Almost everything written about SIM swap fraud is addressed to that customer: lock your account, add a PIN, stop using SMS codes. This article is for the operator. It lays out the three-stage playbook for the fraud, risk, and network security teams who have to build the detection and prevention controls. It is specific about which of those controls live in the customer-care process and which live in the AAA (authentication, authorization, and accounting) and subscriber identity layer.
Why SIM swap fraud is such a high-value attack
The common mistake is to size SIM swap fraud by the telecom loss: one handset, one account, one month of unpaid usage. The real loss is downstream, at the bank, the exchange, the email provider, and the payroll system that all send a one-time passcode to the phone number on file.
That is what makes the attack worth a fraudster’s time. Once the number rings on their device, every service that uses SMS for two-factor authentication or password reset is open to them. They work through the victim’s accounts fast, often before the victim has noticed that their own phone has lost service. NIST SP 800-63B, the US National Institute of Standards and Technology’s digital identity guideline, has classified out-of-band authentication over the public telephone network, which includes SMS codes, as a restricted authenticator since 2017, because the channel can be redirected by an attacker who compromises the subscriber account instead of the device.
Operators are rarely the party that loses the money, but they are the party whose process was defeated, and increasingly the party regulators hold responsible. The FCC’s Report and Order on SIM swap and port-out fraud requires wireless providers to authenticate customers securely before a SIM change or a port-out (moving the number to another carrier) and to notify them immediately when such a request is made. Similar expectations are arriving in other markets. The playbook below is built to satisfy them, and to catch what the paperwork alone will not.
Playbook Stage 1: Harden identity verification at the swap request
The SIM swap request that defeats you will look legitimate. The attacker has the victim’s name, address, date of birth, and often the last four digits of a card, all bought or phished in advance. Any verification step that relies on knowing facts about the customer is a step the attacker has already prepared for.
Hardening the request means moving from what the customer knows to what the customer controls. Four controls hold up in practice: a customer-set account PIN or passphrase that an agent never reads back; a push confirmation or callback to the device currently holding the SIM, sent before the change is made; in-person ID checks with document capture for retail swaps; and a mandatory delay on swaps for accounts flagged as high value or recently changed. Each of these gives the real subscriber a chance to say no before the number moves.
One practical caveat: confirmation to the existing SIM only works if it is sent before the swap, and it cannot work at all for a customer whose phone is lost or stolen. That case needs a slower, document-based fallback, and the fallback is where attackers will go next.
Two operational details decide whether Stage 1 works. First, the insider path. SIM swap fraud is frequently carried out by, or through, retail and call-center staff who have been bribed or socially engineered, which is why the FCC order also requires safeguards on employee access. Per-agent swap limits, dual authorization for out-of-policy swaps, and a complete audit trail of who changed which subscriber profile matter as much as the customer-facing checks. Second, every verification step you add is a step that legitimate customers with a lost phone must also pass, so care and fraud teams need to design the flow together.
Playbook Stage 2: Monitor identity-change events for anomalies
Stage 1 reduces the attack surface. It does not close it, because a determined attacker will eventually find the agent, the channel, or the account where the process is weakest. Stage 2 assumes some swaps will get through and asks a different question: which of today’s identity changes look wrong?
An identity-change event is any modification that rebinds a subscriber’s number to a new credential: a new ICCID (the SIM’s serial number) and IMSI (the identity the network authenticates), a new eSIM (embedded SIM) profile, a number port, or a change to the contact details that receive security notifications. Each one should be logged with the channel, the agent or API client, the time, and the verification method used. Then the stream can be watched for the patterns fraud produces.
The patterns worth alerting on include:
- A cluster of swaps from one store or agent in a short window, which is the usual signature of an insider or a compromised agent login.
- Swaps completed outside the subscriber’s usual channel or at an unusual hour.
- A contact-detail change followed within hours by a SIM change, which is the attacker disabling the notification before making the move.
- Repeat swaps on the same account inside a month.
- A swap on an account that has been dormant, or on one that carries a high-value flag from the bank partnership team.
None of these is proof on its own. Together, scored against the operator’s own baseline, they identify the small set of changes a fraud analyst should review while the number can still be pulled back.
Playbook Stage 3: Watch post-swap activity
The most valuable minutes in the whole playbook are the ones immediately after a swap completes. That is when the attacker is most active and easiest to tell apart from a real customer who has just replaced a lost phone.
The network sees the difference first. The new SIM attaches from a device with a different IMEI (the handset identifier), often from a different city or country from the subscriber’s last known location. The Wi-Fi calling registration arrives from an unfamiliar network. There is a burst of inbound SMS, mostly one-time passcodes, with little or no outbound activity, and data usage that does not resemble the subscriber’s history. When the AAA server authorizes that first data session or authenticates the Wi-Fi calling registration, and then records the accounting that follows, it holds the session attributes the access network forwards, which is what it needs to score the session against the profile that existed before the change.
Detection has to be paired with an automated response, because a human review queue is too slow for an attack that can complete in under an hour. Practical responses include placing the account in an elevated-risk state for 24 to 72 hours after any swap, during which further changes require additional verification; using Change of Authorization (CoA) to restrict the new session to a limited service profile until the customer confirms through a channel the attacker does not control; and exposing a SIM swap check to partner banks, for example through the GSMA Open Gateway SIM Swap API (defined in the CAMARA project), so that they can treat one-time passcodes sent to a recently swapped number as untrusted.
Ask any AAA vendor three questions against this table: which identity-change events can you see, what do you score on the first authentication after a change, and how do you restrict a flagged session while it is still running?
Building SIM swap protection into AAA infrastructure
The Stage 1 controls belong in the care and customer relationship management (CRM) workflow and are mostly a matter of policy and process design. Stages 2 and 3 need a system that sees both halves of the picture: the change to the subscriber profile and the sessions that follow it. In a mobile network, that is the subscriber identity and AAA layer. It integrates with the Home Subscriber Server (HSS) over the 3GPP Diameter SWx interface and with the packet gateway over S6b. It authenticates the new SIM with EAP-AKA or EAP-AKA’, the SIM-based Extensible Authentication Protocol (EAP) methods. And it receives the RADIUS (Remote Authentication Dial-In User Service, RFC 2866) or Diameter (RFC 6733) accounting that carries the device, location, and usage attributes described above.
That is why the playbook is framed as AAA infrastructure and not as a fraud tool bolted on beside the network. If the AAA platform already analyzes authentication and accounting in real time, the SIM swap use case is a set of detection rules and response policies on data the platform holds, not a new integration project. Alepo AAA Server is built this way. The Alepo AI Agent for AAA reads RADIUS, Diameter, and TACACS+ (Terminal Access Controller Access-Control System Plus) logs as they are written and runs anomaly detection on unauthorized access patterns, which is where the first session after an identity change stands out. It can trigger security information and event management (SIEM) alerts or firewall rules directly. The same layer supports mid-session control through CoA, so a session flagged after a swap can be restricted without waiting for a ticket to be worked.
The platform also has to stay up under the load this creates. Post-swap scoring adds work to the authentication path at the moment a fraud ring may be generating unusual traffic, so it belongs on infrastructure designed for that. Alepo AAA Server is engineered for 99.999% availability, with N+1 and N+N redundancy and real-time database replication, so post-swap scoring can run in the authentication path without turning a fraud spike into an availability incident.
Your SIM swap fraud prevention playbook
If your current defense is a security question and a well-meaning agent, you are protected against a careless attacker and exposed to a prepared one. A working SIM swap fraud prevention playbook has three parts, each of which covers the gap the previous one leaves: verification that depends on what the customer controls, monitoring that scores every identity-change event against the operator’s own baseline, and post-swap detection with an automated response fast enough to matter inside the first hour.
Write it down, assign an owner to each stage, test it with a red-team swap request against your own care channel, and review the alerts it produces every quarter. Regulators will ask to see the document. Subscribers will only ever notice that the passcode went to the right phone.
Want to see what the first hour after a fraudulent SIM swap looks like on a live authentication graph?
Bring your own scenario. We will change the profile on a test subscriber, then authenticate a new SIM from a new device and location. You will see how the Alepo AI Agent for AAA surfaces the anomalous first session and raises the SIEM alert, and how a restricted policy is applied to that one session by CoA with other subscribers still authenticating on the same graph.
Not ready for a call? Read the AAA Server datasheet and put the identity and security layer in front of your fraud and network teams first.
Frequently asked questions
Q1. How do operators prevent SIM swap fraud?
Through a three-stage playbook: hardening identity verification at the point of the swap request so it depends on what the customer controls, monitoring every identity-change event for anomalies against the operator’s own baseline, and watching post-swap activity closely with an automated response that restricts the new session until the customer confirms.
Q2. What is SIM swap fraud and how does it work?
An attacker persuades or bribes an operator’s care, retail, or self-service channel into moving a victim’s phone number onto a SIM the attacker controls. Calls and SMS then route to the attacker’s device, which lets them intercept one-time passcodes and take over bank, email, and other accounts that trust the phone number.
Q3. How does AAA infrastructure play a role in SIM swap fraud prevention?
The AAA and subscriber identity layer sees the profile change and every session that follows it. That is where the first authentication from a new SIM is checked against the previous device and location, where anomalous access patterns are scored, and where a flagged session can be restricted by Change of Authorization.
Q4. What verification hardening prevents SIM swap fraud?
Controls that depend on what the customer holds, not what they know: a customer-set account PIN or passkey that agents cannot read back, confirmation to the existing SIM before the change, document capture for in-store swaps, and a mandatory delay on high-risk accounts. Per-agent swap limits and dual authorization address the insider path.
Q5. How do I detect anomalies in subscriber identity-change events?
Log every ICCID, IMSI, eSIM, port, and contact-detail change with its channel, agent, time, and verification method, then alert on clusters of swaps from one agent or store, off-hours changes, a notification-detail change followed by a swap, repeat swaps within a month, and swaps on dormant or high-value accounts.
Q6. What post-swap monitoring should operators implement?
Score the first authentication after a swap for a new IMEI, a new location, Wi-Fi calling from an unfamiliar network, and an inbound SMS burst with no outbound activity. Hold the account in an elevated-risk state for 24 to 72 hours, restrict the session by CoA until the customer confirms, and expose a SIM swap check to partner banks, for example through the GSMA Open Gateway SIM Swap API.
Q7. Why is SIM swap fraud such a high-value attack for fraudsters?
Because the phone number is the recovery key for many other accounts. Once it rings on the attacker’s device, every service that uses SMS for two-factor authentication or password reset is exposed, and the downstream financial loss is far larger than the telecom account itself.
Q8. How do I build a SIM swap fraud prevention playbook?
Document the three stages, assign an owner to each, implement the identity-change logging and post-swap scoring in the AAA and subscriber identity layer, define the automated response for a flagged session, test the process with a red-team swap request against your own care channel, and review the alerts it produces every quarter.
