A phone number is not a person

The argument

A lot of apps treat a phone number as the person. Type your number, get a six-digit code, you're in. No password to forget, no email to check. For a delivery app, a field crew app or a loyalty program, it feels like the friendliest sign-in there is.

The trouble is that phone numbers don't belong to people. They're leased, and they get handed on. When someone cancels a line or stops paying, the carrier eventually gives that number to somebody new. This is routine enough that the FCC runs a Reassigned Numbers Database so callers can check whether a number may have changed hands, and its rules require carriers to wait at least 45 days after a permanent disconnection before reassigning a number. Forty-five days is not long.

A text code proves someone holds the phone number today. It says nothing about who held it last year. If the code is the only thing standing between a stranger and an account, the account belongs to whoever has the number.

Reassignment is the quiet version of the problem. The loud version is a SIM swap, where someone talks a carrier into moving your number to their phone on purpose. The defenses below help with both, because both come down to the same mistake: trusting the number more than it deserves.

Two people, one number

Picture both sides of it. These are composites.

Dana used your app for two years, then switched carriers and got a new number. She forgot to update it in the app. Months later she reinstalls on a new phone, types her old number out of habit, and waits for a code that goes to someone else. As far as your app is concerned, Dana doesn't exist anymore.

Marcus got a new phone plan in the spring. His number used to be Dana's. One day he gets a code from an app he's never used, and out of curiosity he types it in. He's now looking at Dana's order history, her saved addresses, maybe the last four digits of her card, maybe her loyalty balance.

Neither of them did anything wrong. Your sign-in did.

Keep a second way to know who someone is

The fix doesn't require throwing away text codes. It requires not letting them stand alone.

Collect a second identifier early. An email address, confirmed once, gives you a way to reach the real person when the number fails. A passkey on their device is better still, because it can't be reassigned.

Ask again after a long gap. If an account hasn't been used for months and someone signs in by text code on a new device, treat it as a new situation. Ask for the email code too, or show only limited information until they confirm.

Ask now and then whether the number is still theirs. A light prompt once or twice a year ("Is this still your number?") catches the people who switched and forgot, while they can still sign in to fix it.

Make changing a number a deliberate step. When a user changes their number, confirm it from the old number or the email on file. Tell them, through the other channel, that it changed.

Show less by default. Saved addresses, payment details, order history and documents don't all need to appear the moment a code is entered. Put the sensitive parts behind one more check.

For apps used by working people, the same logic applies to staff. When someone leaves a job and their work phone number goes back to the carrier, the next holder of that number shouldn't be able to sign into your field app and see today's jobs.

Recovery that doesn't become a back door

Every fix above creates a recovery case: the person who lost their number and their email, or who never set one up. Those cases land with support, and support is a common weak spot, because a friendly agent wants to help.

Write the recovery script down. Decide what proves identity for your app: a past order number and delivery postcode, a photo ID check for high-value accounts, a confirmation sent to an address on file. Decide what support may not do, such as changing a phone number on a call based on a name and date of birth. Give agents permission to say no, and a way to escalate.

For accounts that hold real value, consider a short waiting period on recovery: the change is requested today, a notice goes to every contact on file, and it takes effect after a delay unless someone objects. It's a small inconvenience for the real owner and a large one for anyone pretending.

Log every recovery and every number change. If the same account changes number twice in a week, someone should look.

When text codes alone are fine

Not every app needs all of this. If your app holds nothing anyone would want, like a parking timer or a store-hours lookup with no saved data, text-code sign-in alone may be a perfectly fair trade for convenience.

The question to ask is what a stranger could do or see if they got in. If the answer includes money, addresses, documents, health details, other people's information or the ability to place orders, a phone number on its own isn't enough.

Put this into practice

Open your app on a fresh device and sign in with only a text code. Write down everything you can see and do on the first screen and one tap deep. Then ask: would I be comfortable if the next owner of this number saw all of that? If not, start with a confirmed email and a check after long inactivity.

While you're there, look at the texts your app sends: order updates, delivery windows, appointment reminders. Each of those goes to whoever holds the number now. If a message includes an address or a name, it's leaking to the next owner too, and sending texts to people who never agreed to them is the very problem the FCC's database exists to reduce.

We build mobile applications for people who sign in on the move, and that includes making recovery safe. If your app's front door is a phone number, talk to us.

Related work: WorkStep.