Content

Stopping Free-Trial Abuse with Device Intelligence

One laptop, forty trial accounts. How multi-accounting actually works, why email and IP checks miss it, and the device-level pattern that catches it.

WhorlID Team18 July 2026trial abusemulti-accountinguse case

Every SaaS with a free tier eventually meets the same user. They love the product. They have used it every month for a year. They have never paid, because every time a trial expires they sign up again with a fresh email address, and to your database they are a brand-new customer each time.

Multiply that by every plus-sign Gmail trick and disposable-mail domain, and trial abuse quietly becomes a real cost line: infrastructure spent on non-customers, skewed conversion metrics, and in API businesses, straight-up consumed quota.

Why the usual checks miss it

Email uniqueness is the check everyone starts with, and it is the weakest. Addresses are free and infinite. Blocking disposable domains helps for a week, until the abuser moves to a domain you have not listed.

IP address feels stronger but breaks both ways. It misses the abuser on mobile data whose IP rotates hourly, and it false-positives an entire office or university behind one NAT. Ban an IP and you ban a building.

Payment card at signup works, and it also cuts legitimate trial signups dramatically, which is usually a worse trade than the abuse.

The common flaw: all of these identify claims (an address, a network location) rather than the thing actually sitting on the desk. The one constant across all forty signups is the device.

The device-level pattern

With device identification in the signup flow, the pattern becomes visible immediately. The agent runs on your signup page and returns a visitor id derived from the device's technical characteristics: GPU rendering behavior, fonts, hardware shape. Clearing cookies does not change it. A new email address does not change it. An incognito window usually does not change it.

So the moment "[email protected]" hits Create Account, you can ask a precise question: how many accounts has this device already created?

The implementation is a single lookup. On signup, your frontend sends the requestId to your backend; your backend fetches the authoritative event with a secret key (never trust the browser's copy) and reads the visitorId. Count existing accounts with that visitorId and apply your policy:

  • 1 previous account: normal. People re-sign-up legitimately.
  • 2 to 3: allow, but flag, shorten the trial, or require a card.
  • More, created rapidly: this is farming; block or route to manual review.

The graduated response matters. A hard block at two accounts will eventually hit a family sharing a laptop or a consultant with a client's machine. Fraud prevention that never inconveniences real users is fraud prevention people keep enabled.

Reading the extra signals

Trial farms rarely operate by hand at scale, so the surrounding signals earn their keep. Each identification also reports whether the browser shows automation markers (bot score), whether the connection comes from a datacenter rather than a residential network, and how confident the match is. A signup that is simultaneously a repeat device, automation-flagged, and datacenter-sourced is not a judgment call.

What honestly to expect

A determined attacker with a fleet of real devices, or a hardened anti-fingerprinting browser, can still get a second trial. The economics are the point: resetting an email costs nothing, resetting a device identity costs effort per attempt. Device intelligence does not make trial abuse impossible. It makes it more expensive than paying you, which is all it ever needed to do.

See it recognize your own device: run the demo, close the tab, come back. Same device, same id, no cookie involved.

Run the live demo