Device Spread: When One Account Shows Up on Too Many Devices

Most multi-account detection asks one question: how many accounts has this device created? Device spread asks the mirror image: how many devices has this account been on? The first catches one person pretending to be many. The second catches many people, or one attacker, behind one login.

They are different problems with different fixes, and teams that only watch the first miss the second entirely. This post explains what Prynt’s deviceSpread signal measures, what it tends to reveal, and how to turn it into rules without locking out people who simply own a laptop and a phone.

What deviceSpread measures

Every identification that carries a linkedId, your id for the account, contributes to that account’s device history. At identify time, Prynt counts the distinct devices (visitorIds) that have identified with that same linkedId in the past 24 hours. That number is distinctDevices. When it is greater than five, the signal is marked detected, the risk score rises, and the decision includes the reason code DEVICE_SPREAD.

In the server-side event, it lives in the behavioral risk block:

"risk": {
  "signals": {
    "deviceSpread": { "distinctDevices": 7, "detected": true },
    "multiAccount": { "distinctAccounts30d": 1, "windowDays": 30, "detected": false },
    "impossibleTravel": { "distinctCountries": 2, "detected": true }
  },
  "reasons": ["deviceSpread", "impossibleTravel"]
}

Two prerequisites follow from that definition:

1. The account must be linked on the events that count. Pass linkedId to identify() at login, or link it afterwards with PUT /v1/events/{requestId}. The spread for the current request is computed only when that identification carries the linkedId, so pass it directly at login. See why linking linkedId matters.
2. It is a paid-plan signal. The behavioral risk signals (velocity, account sharing, multi-account, device spread, impossible travel) are computed as part of the Smart Signals included from Pro upward, for identifications made with extendedResult: true in Prynt.load() (the mobile SDKs request it by default). See pricing.

Multi-accounting vs device spread

	Multi-accounting	Device spread
Shape	One device, many accounts	One account, many devices
Field	accountsOnDevice, multiAccount, accountSharing	deviceSpread.distinctDevices
Window	30 days (multiAccount), 24 h (accountSharing)	24 hours
Typical abuse	Trial farming, promo abuse, fake accounts	Credential resale, seat sharing, takeover
Reason code	MULTI_ACCOUNT, ACCOUNT_SHARING	DEVICE_SPREAD

What a spreading account usually means

Credential resale and sharing

A paid account whose login is sold or posted publicly gets used by dozens of strangers. Each one is a new device. Spread climbs fast and stays high, often with many countries or networks involved. This is the pattern behind streaming account sharing and shared “premium” logins for AI tools and learning platforms.

Seat sharing in B2B SaaS

A team buys one seat and five people use it. The devices are fewer and more stable than resale: the same handful of laptops every day, often from one office network. Spread here is a revenue question more than a security one, and the right response is usually a nudge toward more seats rather than a block. The seat sharing guide covers that conversation.

Account takeover

After a breach or a credential-stuffing run, an account may be accessed from several attacker devices in quick succession, checking value, changing settings, draining balances. Spread rises sharply over hours, often alongside IMPOSSIBLE_TRAVEL and network signals like RESIDENTIAL_PROXY. The difference from resale is the timing: a previously stable account suddenly spreading is more alarming than one that has always been shared.

Legitimate spread

Plenty of honest accounts touch several devices: a phone, a work laptop, a home laptop, a tablet, a second browser. A QA engineer testing your app across browsers can hit six visitors in an hour. That is why the built-in threshold is above five, and why spread alone should rarely block.

Writing rules on it

The console rules engine exposes deviceSpread as a numeric field, so you can set your own thresholds by moment. A few patterns that work:

• Login step-up: deviceSpread gte 4 → challenge. Ask for a second factor rather than refusing the login.
• Hard stop: deviceSpread gt 10 → block, for products where no legitimate account gets anywhere near that. For finer control by action (payouts, email changes), apply the threshold in your own handler, as in the code below.
• Review tag: deviceSpread gte 4 → tag to build a review queue without changing user experience while you learn what is normal.

Rules evaluate by priority, and a block always wins over an earlier challenge. Combine spread with other fields where you can: high spread plus vpn or a country outside your market is far more telling than spread alone.

In your own code, the same check is a few lines:

const event = await prynt.getEvent(requestId);
const spread = event.risk?.signals?.deviceSpread?.distinctDevices ?? 0;
const travel = event.risk?.signals?.impossibleTravel?.detected;

if (spread > 8 || (spread > 5 && travel)) return requireReauth();
if (spread > 5) flagForReview(event.linkedId);

Acting on it well

Device spread points to a policy question as often as a fraud question, so pick responses by context:

1. Consumer subscriptions: cap concurrent devices or sessions, and offer a family or multi-seat plan when spread is persistent but stable.
2. B2B SaaS: surface seat usage to the account admin and offer additional seats. Do not lock out a paying customer over it.
3. Financial and high-value accounts: treat sudden spread as takeover until proven otherwise. Require re-authentication, notify the owner through a known channel, and hold sensitive changes.

The credential sharing guide covers how to tell resale from household sharing with more examples.

Make it measurable

Before writing blocking rules, tag spreading accounts for two weeks and look at the distribution of distinctDevices across your user base. Most products have a long tail of power users at three or four devices and a small cluster far beyond that. Set thresholds just past the tail, and label confirmed outcomes through POST /v1/outcomes so accounts and devices you confirmed bad are recognized as known abusers when they return. Field definitions are in the docs.