Your customer's number got a new owner, and your OTP let them in. Here is how to stop it.

A customer's phone loses signal on a Friday evening. They assume it is the network and go to bed.

By morning, someone has reset their password, signed in on a new phone, added a beneficiary and emptied the account. Every step asked for a one-time code. Every code was sent to the customer's registered number, and every code was entered correctly.

Your logs show nothing wrong. The number was right. The code was right. The person was not. Overnight, the number had been moved to a SIM card in somebody else's hand.

That is the uncomfortable truth about phone verification. A code sent by SMS proves that someone holds the SIM right now. It has never proved who that someone is.

What it costs you

• The money. A takeover drains an account that passed onboarding honestly, so there is real balance and real limits to take.

• The argument. Your customer says they never approved anything. Your records say the right code came from the right number. Both statements are true, and you are the one who has to settle it.

• The trust. The customer did nothing wrong. They did not share a PIN or click a link. Telling them the system worked as designed is not an answer they will accept.

How a number changes hands

There are two common routes, and neither needs the customer to make a mistake.

SIM swap. Replacing a SIM is a normal service: phones get lost, stolen and damaged. The GSMA describes the abuse as a fraudster who manipulates the operator's customer service process (opens in a new tab) by asking for a SIM replacement or a number port, so that SMS arrives on a device they own. In its 2019 guidance for the mobile money industry (opens in a new tab), the GSMA notes that a successful swap lets the fraudster receive the authentication messages, calls and one-time passwords a financial provider sends to the victim.

Regulators have tightened the process. In Nigeria, the Communications Commission's SIM replacement policy (opens in a new tab) requires the subscriber to present a NIN and requires that NIN to be verified by NIMC. That raises the bar. It does not remove the risk, because the control sits with the operator and its agents, not with you.

Recycled numbers. Numbers are not owned for life. Under the Nigerian Communications Commission's Quality of Service Business Rules (August 2024) (opens in a new tab), a line may be deactivated after six months without a revenue generating event, and the subscriber may lose the number if that continues for another six months. The Commission's subscriber registration business rules (July 2025) (opens in a new tab) classify an account as inactive after 365 consecutive days without such an event, at which point the NIN is delinked and the line is churned. The number can then go to a new subscriber.

So a customer who travelled, changed networks or simply stopped topping up may still have their old number on your records. The person who answers it today is a stranger, and your password reset will happily text them a code. We checked the Nigerian rules for this article. Periods and processes differ by country, so check your own regulator's.

What a phone code proves, and what it does not

It proves three useful things:

• The number exists and can receive messages.

• The person in front of your app can read those messages at this moment.

• The contact detail you are about to store is not a typo or an invention.

It does not prove:

• That this is the person who registered the number, or the person you verified at onboarding.

• That the SIM is the same one that received your last code.

• That the code was not read aloud to a caller or typed into a fake page.

This is not a fringe view. The US standards body NIST, in SP 800-63B-4 (opens in a new tab), classes one-time codes sent over the phone network as a restricted authenticator (section 3.1.3.3). It says a verifier should consider risk indicators such as a device swap, a SIM change or number porting before sending one, and it states that out-of-band authentication is not phishing-resistant. NIST's rules bind US federal systems, not your business, but the reasoning travels well.

None of this means you should stop sending codes. It means you should stop treating a correct code as proof of identity.

What to pair it with

• A face check for the actions that hurt. You already hold the strongest answer to "is this the same person?": the face you verified at onboarding. For a password reset, a new device, a new beneficiary or a large payout, ask for a live selfie and compare it with that face. A SIM can change hands in an afternoon. A face cannot.

• Device and behaviour signals. A code entered from a phone you have never seen, in a new location, minutes after a password reset, is a different event from the same code entered on the customer's usual phone. Our article on what device and IP signals can and cannot tell you covers the limits.

• Step up instead of blocking. Most people on a new phone are simply people with a new phone. Do not lock them out. Ask for more proof only when the risk is real, as we describe in stepping up to stop account takeover.

• Treat old numbers with care. If an account has been quiet for months, the number on file may no longer belong to your customer. Do not let it unlock the account by itself.

What Toden does, and what it does not

We would rather be exact than impressive, so here is each piece with its limit.

• Phone verification. Toden sends a one-time code by SMS and checks it, inside a workflow or through a server API. Codes last five minutes, and no more than five can be sent to one number in an hour. Each check also reports the number's country, whether it is valid, its line type (such as mobile, fixed_line or voip) and a virtual flag that is true only for a known VoIP range.

• Number reuse. In a workflow, phone.matchedVerifications counts how many other verifications in your organisation proved the same number. It is a soft signal. Families share phones.

• Face re-authentication. A ready-made workflow takes a liveness selfie and matches it against the customer's stored biometric template, or against a reference photo you supply. You create a session for a named customer and receive the result on a webhook.

• Device Intelligence. On by default in workflows. It reports findings such as shared and recovered devices, emulators, rooted phones and repeated attempts, each of which you can set to approve, review or decline.

• Account activity. Send a login, password reset, new beneficiary or device change to Toden's activity endpoint and it answers allow, review or block from the device, IP, location and history it holds. See sending events for real-time risk scoring.

The limits.

• Toden's phone signals do not name the carrier, and they do not tell you whether a SIM was swapped or a number reassigned recently. If you need that, it has to come from a mobile operator or a service connected to one.

• A review decision does not start a face check for you. Your app decides what to do with it, and creating the re-authentication session is your call.

• These controls lower the odds of a takeover. They do not make one impossible, and they do not replace your own duty to investigate and report.

Questions to ask any provider

• When you say "phone verified", what exactly was proved, and for how long is it true?

• Can you tell me if the SIM or the number changed hands recently? If not, do you say so plainly?

• Can I ask for a face check on a password reset or a new device, against the face from onboarding?

• Do you tell me the line type, so I can treat a virtual number differently?

• Can I challenge a risky login instead of blocking every customer who buys a new phone?

This article is general guidance and not legal advice for your situation. The rules on authentication, SIM registration and fraud liability differ by country, so check them with whoever owns compliance at your company.

Want a second proof behind every code? Open a Toden workspace (opens in a new tab) or read how Toden approaches fraud prevention.