How can security teams detect SIM swap fraud before sending a verification code?

What signals should be checked before a code is sent?

The safest detection point is before the one-time code leaves your system. Teams should combine telecom-change indicators with account and device telemetry, because sim swap fraud often appears first as a mismatch between the user’s usual behaviour and the current recovery attempt. Recent SIM change events, carrier port activity, sudden signal loss, and a new device or location during recovery are the highest-value pre-send checks.

One useful way to structure this is to separate hard indicators from softer risk signals. A recent SIM change or port-out event is stronger evidence than a vague anomaly, but weaker signals still matter when they cluster around an urgent recovery request. That is why MFA Fatigue and Bypass Guide and Account Takeover Prevention Guide both emphasise looking for recovery abuse, session risk, and unusual context before granting step-up access.

Teams should also treat failed recovery attempts as a signal, not just a support issue. When an attacker is probing a reset flow, the account may already be under active attack, so the decision is not merely whether the code can be delivered, but whether the delivery path itself is still trustworthy.

How do teams distinguish a real user from a SIM swap attempt?

The practical test is whether the current request fits the account’s normal risk pattern. A legitimate user may travel or change devices, but a sim swap attempt often combines multiple anomalies: a recent number change, a fresh device, an unfamiliar network, and a recovery request that arrives after the mobile line has gone quiet. The more of those signals that appear together, the less appropriate SMS becomes as the delivery channel.

This is why recovery design matters as much as detection logic. If SMS is still the default path for high-risk approval, the control is too dependent on the same phone number that the attacker may already have captured. Better designs use a separate trusted channel, a stronger authenticator, or a manual review step when telecom or behavioural risk is elevated. Workforce Identity Security Guide and Passwordless and Passkeys Guide both reinforce that recovery paths need to be more robust than the factor being protected.

Another useful distinction is between signal and proof. A SIM change event is not absolute confirmation of fraud, but it is enough to raise the assurance bar before a code is sent. In practice, that means using risk checks to decide whether to allow the code, require an alternative factor, or route the request for review.

What should happen when the checks look suspicious?

When the pre-send signals are suspicious, the right response is to slow the flow and reduce blast radius. Do not let a potentially hijacked phone number continue to serve as the easiest path into account recovery, especially for password resets, payout changes, or other high-impact actions. A brief delay, a different channel, or a manual callback can be the difference between blocking takeover and confirming it for the attacker.

That decision becomes more important if the account has already shown signs of compromise. If the same user has repeated failed recovery attempts, new-device activity, or a recent loss of mobile service, the team should treat the case as a potential takeover in progress rather than a simple authentication failure. Fraud Prevention Guide for Digital Businesses and Fraud and Cyber Convergence Guide are useful because they frame these checks as shared fraud and security signals, not isolated support events.

Teams should also preserve evidence from the same window used for the decision, including the timing of the SIM change, delivery failures, device fingerprint, geolocation, and any support contacts. That record is what allows later investigation to answer whether the code was withheld correctly, or whether the account was already being manipulated elsewhere.

Risk and Threat Considerations

SIM swap fraud is dangerous because it attacks the delivery path, not just the code itself. If an attacker can move a phone number to a new SIM, SMS-based recovery can become a takeover enabler, especially when the organisation uses mobile number ownership as a proxy for trust.

Failure mechanism: The attacker induces or benefits from a number port or SIM change, then intercepts the verification code or recovery flow before the legitimate user can respond. If the system does not check telecom-change signals first, it may hand the attacker the very code needed to complete account access.

Impact: Account recovery, password reset, and high-risk approval flows can be converted into account takeover. That can lead to session theft, payment redirection, data exposure, and loss of control over downstream security settings.

Practitioner Guidance

What to prioritise: Put the highest scrutiny on recovery and reset flows, not just login. Those are the moments when a SIM swap is most likely to pay off for an attacker, because the code delivery path is itself the trust decision.

What to verify: Confirm that your pre-send logic actually uses recent SIM change data, device change data, and failed recovery history together. A single risk signal is useful; a combined decision rule is much stronger than treating each signal in isolation.

Decision rule: If the phone number has changed recently, the device is new, or the line has just lost service, do not rely on SMS as the sole factor. Step up to a separate channel or a manual exception path before any verification code is issued.

Practitioner takeaway: The control is not “can we send a code”, it is “is the delivery channel still trustworthy enough to grant access”. Treat SIM change telemetry as a gate on recovery, not as a post-incident clue.

Related resources from NHI Mgmt Group

• What do security teams get wrong about SNA and SIM swap fraud?
• How do security teams detect repository confusion attacks before malicious code spreads?
• How should security teams detect indicators of compromise in CI/CD pipelines before malicious code reaches production?
• How should security teams detect compromised open-source maintainer accounts before malicious code lands in a package?