Should I screen a phone number when a customer changes it, not just at sign-up?

Yes. Changing the phone number on an existing account is how an attacker converts a compromised password into durable control, because every later step in the reset path then looks legitimate. Screening the incoming number for carrier, number type and active status before accepting it as a contact method costs a single lookup and applies the same check you already run at onboarding to a higher-risk event.

What makes an incoming phone number risky during account recovery?

Non-fixed VoIP numbers arriving on long-standing accounts, toll-free or voicemail numbers presented as personal contact numbers, numbers that are inactive on the carrier network, and country changes unsupported by the rest of the account. Any one of these is weak evidence alone. The combination of a disposable number with other simultaneous profile changes is what justifies holding the change for verification.

Does Telebase detect SIM swaps on account recovery?

SIM swap detection is launching and is not yet available in GB, DE, NL or FR, where the API currently returns UNKNOWN. Carrier, country, number type and active status are live today and support screening a number presented during a change or recovery flow. Request early access at telebase.io/contact-us to be notified when SIM swap goes live.

Account takeover

Screening the number change: the recovery flow nobody instruments

Most teams screen a phone number once, at sign-up, and never look at it again. The higher-risk moment comes later, when someone changes the number on an existing account or recovers access to one, because that is where an attacker turns a stolen password into durable control. Running the same carrier, number type and active status check against the incoming number costs one lookup and gives a risk engine something concrete to decide on.

Why the attack moved here

Login has been getting harder for several years. Passkeys, hardware keys and device binding all raise the cost of a straightforward credential attack, and the firms with the most to lose have adopted them first. Recovery has not hardened at the same rate, because recovery exists precisely to help people who have lost their second factor, and every control added there locks out genuine customers.

So the attack moves. Rather than defeat the second factor, an attacker changes it: update the phone number on the account, wait out any cooling-off period, then use the ordinary reset path. From the system's point of view every subsequent step is legitimate. This is the same destination as SIM swap reached by a different route, and it needs the same suspicion.

The three moments worth a lookup

A number is added or changed on an existing account

Screen the incoming number before you accept it as a contact method, not after. This is the highest-value single check on the list, because it is the step the attacker needs and the step almost nobody instruments.

Account recovery is initiated

Screen whatever number the recovery flow is about to trust, whether that is the number on file or a new one being presented. If the number on file has gone inactive since you captured it, that is worth knowing before you route a code to it.

A high-value action follows a recent change

The number change and the withdrawal are rarely the same session. Carrying a "contact details changed recently" flag into the payout decision is what connects them, and it is a change to your rules rather than a new integration.

What a risky incoming number looks like

nonFixedVoip on an aged account. A customer of six years replacing a mobile number with a non-fixed VoIP line is unusual. Cheap, disposable and instantly obtainable is exactly what an attacker wants, and exactly what a long-standing customer rarely switches to. Screening this is standard number type detection.
tollFree or voicemail. These are almost never a genuine personal contact number and are a strong candidate for an automatic hold.
Inactive at the moment of change. A number that is not reachable on the network being set as the recovery destination makes no sense for a real customer.
Country change without any supporting context. A number in a country unconnected to the rest of the account, arriving at the same time as other profile edits, is a cluster worth reviewing rather than a single flag.

The pattern that matters is the combination. A VoIP number by itself is weak evidence, because plenty of legitimate people use VoIP. A VoIP number arriving on a dormant high-balance account minutes after a password reset from a new device is not really about the number at all: the number is the piece that makes the rest legible.

A starting rule set

Thresholds below are a starting point for a team that has nothing here yet, not a tuned model. Anyone claiming to know the right numbers for your book without seeing it is guessing. Our guide to building a risk score from telecom signals covers weighting them properly.

Incoming number is tollFree or voicemail: hold the change, require a stronger verification step.
Incoming number is nonFixedVoip: allow the change, flag the account, and hold withdrawals for a defined cooling-off period.
Incoming number is inactive: reject it as a contact method, since it cannot receive anything anyway.
Incoming number is a mobile on a major carrier in the expected country: proceed, and record the values so you have a baseline for next time.

That last line matters more than it looks. Recording carrier and line type at the point of change is what lets you compare later, and gives the account a history rather than a single stale snapshot.

Example call

Request

GET https://api.telebase.io/lookup?phone=%2B447700900000
Authorization: Bearer tb_live_xxxxxxxxxxxxxxxxxxxxxxxx

Response, 200 OK

{
  "phoneNumber": "+447700900000",
  "active": true,
  "carrier": "EE",
  "country": "GB",
  "numberType": "mobile",
  "simSwap": "UNKNOWN",  // launching
  "simSwapAt": null,
  "_meta": { "activeSource": "LINE_STATUS" }
}

One call, synchronous, inside the request that processes the change. If you already screen at sign-up, this is the same integration pointed at a second event.

What this check does not do

It does not prove the person making the change is the account holder. It tells you whether the number they are presenting behaves like a real customer's number.
It does not replace step-up verification. It tells you when to demand it, which is the harder question.
It does not detect a SIM swap on the existing number. That signal is launching and returns UNKNOWN in GB, DE, NL and FR today.

Used well, it belongs alongside device and behavioural signals rather than instead of them. Our page on protecting OTP and SMS 2FA flows covers the surrounding controls.

Request early access