Phone Verification vs Device Limits for Stopping Fake Signups

Phone verification is the default answer to fake signups because it feels like proof of personhood: a real person, a real phone, a code they had to read. For years it worked reasonably well. Today it is expensive, attackable, and often weaker than it looks, while a device-level limit can do much of the same job with no visible step at all.

This is a comparison of the two approaches, and a case for using them together, with phone verification as a step-up rather than a gate.

What phone verification actually proves

An SMS one-time password proves that, at the moment of signup, the person could read messages sent to that number. It does not prove the number belongs to them for long, that it is a mobile line in a particular country, or that it has not been used for twenty other accounts on other services.

Its strength depends on how hard numbers are to get. That is the weak point.

Where phone verification breaks down

Virtual and rented numbers

Online services rent numbers for receiving a single verification code, priced to be trivial for anyone farming accounts. Some numbers are VoIP, which carrier lookup can identify; others are real SIMs in physical SIM banks, which look like ordinary mobile lines. Blocking VoIP numbers catches the cheapest tier and also catches legitimate users of internet telephony.

SMS pumping

SMS pumping, also called artificially inflated traffic, turns your verification form into a revenue source for someone else. Attackers submit premium-rate or attacker-controlled numbers, often in bulk through bots, and share in the termination fees. You pay for messages nobody intended to verify. Rate limits, country allowlists and bot detection all help; the SMS pumping guide covers defenses in detail. The structural problem remains: an endpoint that sends paid messages on request is a target.

Cost and conversion

Every code you send costs money, and that cost scales with traffic you do not control. Prices vary widely by destination country, so check your own provider’s rates rather than trusting any blog’s number, including this one.

The conversion cost is less visible. Each verification step loses some legitimate users: delivery delays, international numbers, people who do not want to give a phone number to a product they are only trying. For a self-serve product competing on ease of trial, that friction lands precisely on the users you most want.

Shared and recycled numbers

Carriers recycle numbers. Families share them. A strict “one account per phone number” rule eventually refuses a real customer whose number used to belong to someone else.

What a device limit proves

A device limit asks a different question: how many accounts already exist on this browser or phone? The browser identifies the device on the signup page; your server verifies the event with a secret key and reads accountsOnDevice, which lists every account you attached to that device. If the count meets your limit, the signup is refused or downgraded.

It has a different set of properties:

	SMS verification	Device limit
Visible to the user	Yes, a code to enter	No
Cost per signup	A message fee, varies by country	An identification, part of a plan quota
Abuse it invites	SMS pumping	None comparable
Beaten by	Rented numbers, SIM banks	New devices, device farms, emulators
Works without a phone number	No	Yes
Catches automation	No	Yes, with bot and tampering signals

Neither is unbeatable. A person with a stack of phones defeats a device limit; a person with a SIM bank defeats phone verification. The difference is that a device limit costs legitimate users nothing, and the attacks that beat it, such as device farms, carry their own signals: emulators, rooted phones, virtual machines, proxies. The device-based signup limits post covers how to set the number.

Use phone verification as a step-up

The strongest pattern combines them. Run the device check on every signup, and send an SMS only when the device check says the signup is risky. The shared policy module in Prynt’s integration recipes has a verify action for exactly this: create the account, but hold back the trial or credits until an extra step.

import { PryntServer } from '@prynt/node';
const prynt = new PryntServer({ secretKey: process.env.PRYNT_SECRET_KEY! });

async function signupVerdict(requestId: string | undefined) {
  if (!requestId) return 'verify';                     // unidentified: ask for the phone
  let event;
  try {
    event = await prynt.getEvent(requestId);
  } catch {
    return 'verify';                                   // lookup failed: fall back to the SMS step
  }
  if (event.decision === 'block') return 'block';      // bots, tampering, burned devices
  const others = event.accountsOnDevice.count;
  if (others >= 3) return 'block';                     // clearly farming
  if (others >= 1 || event.decision === 'challenge') return 'verify';
  return 'allow';                                      // most signups: no code, no friction
}

Then:

• allow: create the account and start the trial immediately.
• verify: create the account, ask for a phone number, and unlock the trial after the code. Check the number against previously verified numbers in your own system, normalized to E.164.
• block: refuse, with a short message and a support contact.

Because the SMS step is reserved for a minority of signups, the message bill and the conversion loss shrink to that minority. And because the verify branch sits behind bot detection, scripted SMS pumping through your signup form has a much harder time reaching the send call at all. Keep a rate limit on the send endpoint regardless; the rate limiting by device post shows how to key it on visitorId rather than IP.

When phone verification should stay mandatory

Some products need a phone number for their own sake: two-factor login, delivery coordination, or messaging features. Some regulated flows require stronger identity verification than either method provides. In those cases keep the phone step, and use device signals to decide who gets additional checks on top, such as manual review or document verification.

A practical rollout

1. Add identification and the server-side lookup to signup, and log the verdict without acting on it.
2. Compare how many current SMS verifications go to devices that would have been allow. That is the friction you can remove.
3. Move SMS behind the verify branch, and watch signup completion and the SMS bill.
4. Tighten the device limit using the flagged accounts you reviewed.

The goal is not to remove phone verification. It is to stop charging every honest user, and paying every SMS fee, for a check only a few signups need. The signup funnel guide covers the conversion side, and the pricing page shows what identifications cost on each plan.