How to detect account sharing?

Account sharing detection is the practice of identifying when one login is used by several people, by counting how many distinct device identities sit behind a single account over time. It is the mirror image of multi-accounting: there, one person hides behind many accounts; here, many people hide behind one. For subscription and SaaS businesses, the second one quietly drains revenue, because every extra person on a shared login is a seat or a plan that was never bought.

Account sharing is the case teams most often get wrong, because the honest answer is uncomfortable: the same evidence that flags a sharer also describes a real customer with a phone, a laptop, and a work machine. This guide explains what account sharing detection actually is, how it works, the signals that reveal it, and how to act on it without punishing the people paying you.

Key takeaways

• Account sharing detection counts the distinct device identities behind one login over time, rather than trusting the login itself. Too many separate devices on one account is the core signal.
• It is not the same as password sharing in the password-manager sense, and it is not account takeover. Those are different problems with different fixes.
• The hard part is false positives: one real person legitimately uses several devices and browsers, so the device count is a signal, not a verdict.
• The right response is rarely a block. It is a prompt to upgrade, a session limit, or a re-authentication, decided by your own rules on top of the score.

What is account sharing?

Account sharing is when one set of login credentials is used by more than one person. On subscription platforms it ranges from a family passing around one streaming login, to a team using a single paid seat instead of buying more (the SaaS seat-sharing case), to credentials resold to strangers. The common thread is that the platform charges for one user and serves several.

It is worth separating it from three things it gets confused with, because each has a different fix:

• Not password-manager sharing. "Password sharing" often means sending a password to a colleague securely. That is a deliberate, sanctioned act with a password manager. Account sharing detection is the opposite concern: noticing when one paid login is being used by people who were never meant to have it.
• Not account takeover. In account takeover, an attacker uses credentials the real owner did not authorize. In account sharing, the owner usually handed the login out on purpose. The signals overlap, but the intent and the response differ.
• Not just the streaming-password-crackdown story. The consumer headlines are about one large platform enforcing household rules. The same mechanics apply to any subscription or SaaS product, usually framed as protecting revenue rather than policing households.

This guide is about the subscription and SaaS case: detecting that one login serves many, so you can decide what to do about it.

How account sharing detection works

Account sharing detection works by giving each session a stable identity, then counting how many distinct identities accumulate on a single account over time. The login alone cannot tell you this, because everyone signs in with the same credentials. What separates the users is the device and the connection behind each session. Academic work on the problem in 2024 reached the same conclusion: the most reliable signal is the set of distinct devices behind a login, not anything in the credentials themselves.

The mechanic is the inverse of multi-accounting. There, you link many accounts back to one device to prove a single person is behind them. Here, you link many devices to one account to prove several people are behind it. Both rely on the same foundation: a persistent device identifier that survives a cleared cookie and a rotated IP, so a returning session is recognized as the same machine and a genuinely new machine stands out.

Tie that identifier to the account in your system, watch the count of distinct devices grow, and a shape appears. One account touched by two or three stable devices over months looks like a household or a person with a few gadgets. One account touched by a dozen unrelated devices in a week looks like a login that has been handed around.

The signals that reveal account sharing

No single signal proves sharing. The picture comes from reading several together and weighing how far the account drifts from single-user behavior. These are the ones that do the work:

Signal	What it indicates	Strength
Distinct device count	Many separate device identities on one account over time, surviving cleared cookies and rotated IPs	High
Impossible travel	The same account logging in from locations too far apart to travel between in the elapsed time	High
Geographic spread	Logins clustered in places no single household or person would span	Medium
Anonymity tools	VPN, proxy, or anti-detect browser used to mask out-of-household or resold access	Medium
Sequential bursts	A login passed between devices in turns, never overlapping, which session caps miss	Medium

The strongest single signal is the distinct device count, because it reflects the real machines behind the login rather than anything the users can edit. Impossible travel is the next, since two logins on different continents only minutes apart cannot come from one traveling person, and so is plain simultaneous use, two or more devices active on the same account at the same time in different places. Anonymity signals confirm the picture: a VPN, an anonymous proxy, or an anti-detect browser, plus an OS mismatch or a timezone mismatch between what the connection claims and what the device reports, all point to out-of-household or resold access. These signals are weighed together rather than acted on one row at a time, since any one of them in isolation describes plenty of ordinary users.

How aggressive any of these looks depends on the time window you measure over, which is itself a tuning decision. A short window tolerates a real user switching from a phone to a laptop and back, but lets slow, take-turns sharing slip through; a longer window catches the sharing that takes turns over days, at the cost of flagging more legitimate multi-device use. There is no universal threshold, only the one that fits how your own customers actually behave.

Why a concurrent session limit misses it

The usual first instinct is a concurrent session limit: cap how many sessions can be active at once. It helps, but it only sees sharing that overlaps in time. The most common kind does not.

A family or a team passing one login around tends to take turns. One person watches in the evening, another the next morning; one colleague uses the seat on Monday, another on Tuesday. At no single moment are two sessions live, so a concurrent cap sees nothing wrong. Identity-based detection catches it because it counts distinct devices over time, not sessions at one instant. That is the gap a session limit leaves open, and it is where most real sharing lives.

The hard part: not punishing real users

Here is the uncomfortable part most write-ups skip. The same evidence that flags a sharer also describes a normal customer. One real person routinely uses a phone, a personal laptop, and a work machine, and may add a tablet and a smart TV. Each is a distinct device. A high device count is suspicious, but it is not proof.

It gets subtler. A device identifier is read in the browser, so the same person using two different browsers on one laptop can register as two devices, because the browser fingerprinting signals differ between them. A household behind one shared home IP can look tighter than it is, and a single traveler on a VPN can look like impossible travel. None of these is a sharer.

The honest conclusion is that account sharing detection produces a signal, not a verdict. The device count, the travel, the anonymity tools, raise or lower confidence, but the threshold for action is a business decision, and the safest responses are reversible. This is exactly why a system that returns the reasons behind a score beats one that returns a yes-or-no: you can see whether an account tripped on five devices in one city or twelve across three continents, and treat them differently.

What to do when you find account sharing

Because the evidence is probabilistic and your customers are paying you, blocking is rarely the right first move. The responses that work treat sharing as a revenue and a security question rather than a punishment:

1. Prompt an upgrade. When an account shows a sharing pattern, offer more seats or a family plan. The goal is to convert the sharers into paying users, not to lock anyone out.
2. Limit concurrent sessions. Cap simultaneous logins on accounts that drift past a threshold, which nudges heavy sharing without touching ordinary use.
3. Re-authenticate new devices. Ask for a second factor when an unfamiliar device appears on a sensitive account, which also covers account takeover.
4. Reserve hard blocks for the clear cases. Save a real restriction for accounts whose pattern only resale explains, like dozens of devices across many countries.

The thread is that detection informs the response, but your own rules own it. The data layer tells you how many people sit behind a login and how confident it is; what you do about it depends on your product, your pricing, and your tolerance for friction.

How ShieldLabs detects account sharing

ShieldLabs gives every session a persistent device identity and lets you attach it to the account in your system, so it counts the distinct devices behind each login over time. When an account behaves like many users, a pre-built pattern for account sharing surfaces in the analytics dashboard, alongside an impossible-travel pattern when the same account logs in from places it could not have traveled between.

Each session also returns a risk score from 0 to 100 with the named signals behind it, including the anonymity signals, a VPN, proxy, or anti-detect browser, that often accompany resold or out-of-household access. ShieldLabs scores and names the evidence. You get the risk score and named anonymity signals through the API and webhooks and decide, by your own rules, whether to prompt an upgrade, limit sessions, or re-authenticate to prevent account sharing, so the verdict stays in your application.