TL;DR: account sharing prevention
- Passwords and MFA verify the credential, not the person. If a subscriber hands the credential to a friend, every credential-layer control passes.
- The hardware layer does not lie. Device fingerprinting reads 100+ browser signals into a stable ID that persists across incognito, VPN, and cookie clearing. Two distinct fingerprints on one account in 24 hours is a flag. Five in the same window is close to confirmation.
- Detection returns a verdict per session, not a batch report. The application decides the response: step-up auth, seat upgrade prompt, or audit log.
Account sharing detection is the practice of identifying when several people use one licensed account with a single set of credentials. The signal that catches it lives at the device layer: shared logins pass every password and MFA check, but each person brings a different browser and hardware profile, so one account starts authenticating from three or five distinct device fingerprints in a short window.
This is a different problem from account takeover, where an attacker steals credentials without the owner's knowledge. In account sharing, the legitimate user hands out their login on purpose, usually to avoid paying for extra seats. The revenue math is direct: if ten people work off one license, the vendor is billing for 10 percent of the actual usage. And because every shared login uses valid credentials, it clears authentication cleanly, so the evidence has to come from somewhere authentication cannot see.
What account sharing actually costs
Per-seat SaaS licensing is the model most at risk. A company buys one seat, one person registers, and then shares the username and password with the rest of the team. The product works. The vendor sees one active account. The team of eight that should represent eight seats represents one.
This is not a niche problem. In per-seat SaaS products, credential sharing is common enough that many users treat it as a normal workaround rather than a policy violation. The cost shows up in two places: direct revenue loss from seats never purchased, and distorted usage data that makes the product look like it has fewer active users than it does, which skews every expansion and retention decision downstream.
In iGaming, the sharing problem takes a different form. Players share accounts to pool bonuses, transfer balances between individuals, or let a more experienced player operate an account on someone else's behalf. This violates terms of service and creates both compliance exposure and chargeback risk when the account holder later disputes activity they claim they did not authorize.
In fintech, shared account access creates another risk: you cannot establish which person is responsible for a transaction when multiple people use the same account. That creates liability exposure and makes suspicious activity monitoring unreliable.
Why credential-layer controls cannot catch account sharing
Authentication controls (passwords, MFA, session tokens) are designed to verify that the person logging in holds the correct credential. They are not designed to verify that the person holding the credential is the specific individual who is supposed to hold it.
When a user shares their password with a colleague, the colleague logs in with a valid username and valid password. MFA sent to the account holder's phone only slows this down: the account holder can relay the one-time code to the colleague, or the colleague can work inside a session the account holder already authenticated. IP-based controls do not help either, because the shared users may be in the same office, on the same network, or in different legitimate locations.
The credential layer has no visibility into how many distinct humans are using a given set of credentials. That information exists one layer down, in the device.
The device fingerprint signal that reveals sharing
Every browser session produces a stable fingerprint from the hardware and software signals available in that session: canvas rendering output, GPU characteristics, font metrics, WebGL behavior, audio context, screen resolution, and dozens of other attributes. This fingerprint holds up across cookie clearing, incognito mode, and VPN use, because it is derived from physical hardware rather than stored identifiers.
When the same account is accessed from two or three distinct device fingerprints inside a short time window, that is a reliable signal of credential sharing. A single user switching from laptop to phone produces two fingerprints tied to a consistent behavioral history for that account. A group of colleagues sharing one login produces three, five, or eight fingerprints with no prior association to that account, often from machines with entirely different hardware profiles.
The threshold is configurable. As an illustration, two distinct fingerprints in 24 hours is a flag worth reviewing, and five distinct fingerprints in the same window is close to a confirmation of active sharing. The device signal does not require users to behave differently or slip up. It is structural, derived from hardware they cannot swap out mid-session.
How cside detects account sharing
cside device-bound sessions generates a stable device fingerprint for every browser session and associates it with the account that authenticates. The fingerprint is built from more than 100 browser signals and holds up with high accuracy across incognito mode, VPN connections, and cookie-clearing behavior.
When the same account authenticates from a new device fingerprint, cside returns a real-time verdict for the session: whether the fingerprint is known or new for that account, how many distinct fingerprints have been seen for the account in a rolling time window, and whether the current session matches the account's established device history.
Your application decides how to respond. Options include requiring step-up authentication from the new device, showing a seat upgrade prompt before the session continues, or logging the event for review by the account management team. The detection runs in the background, so the fingerprint is collected during the session without a prompt, and legitimate users on their own devices see no added friction.
The same fingerprint data that catches account sharing also supports account takeover prevention, new device alerts, and impossible travel detection. Integration is a single script tag, and the device fingerprint ID cside returns is compatible with your existing session management logic.
Where account sharing detection matters most
SaaS companies on per-seat models gain the most direct revenue impact from detection. Identifying accounts that are actively shared, and starting seat expansion conversations at the moment sharing is detected, turns a policy enforcement action into a revenue recovery workflow. Timing matters here: reaching out while sharing is actively happening works better than surfacing it in a quarterly audit.
iGaming operators face a different priority. Account sharing in iGaming is a terms of service violation that drives bonus abuse, liability uncertainty, and regulatory exposure. Detecting it at login, before the session proceeds, is the operationally correct intervention point.
Financial services and fintech companies need device-level attribution for compliance and audit purposes. Knowing which physical device was present at the time of a transaction is increasingly relevant to both internal risk policies and regulatory requirements around customer due diligence.
In all three cases the detection logic is the same. The response differs based on the outcome the organization wants: a seat expansion prompt, a session block, or an audit log entry.
