The trial that never ends

This page is the attack playbook. For the implementation checklist and detection order, read How to detect and prevent free trial abuse.

How the attack works

Trial abuse is the cheapest fraud in this collection because it barely requires tooling. The whole technique is producing a new identity on a schedule:

• A new email — a catch-all domain or a plus-address on a provider that ignores it, so one mailbox produces unlimited addresses that all deliver.
• A new IP — a residential proxy or just a phone hotspot, enough to break any per-address counting.
• A cleared browser, or for the more committed, an antidetect profile so the device fingerprint does not repeat either.

At the low end this is one person and a bookmark. At the high end it is an agency running a client workload permanently on somebody's free tier. The distinction matters commercially and not at all technically — the detection is identical.

Why the usual defences miss it

Email uniqueness is not identity. Catch-all domains produce infinite valid addresses; plus-addressing does the same on major providers unless you normalise it, and normalising it breaks legitimate users who genuinely rely on tagged addresses.

Requiring a card works and has a price: it is the single largest drop in trial signup conversion most teams ever measure. It is a business decision disguised as a fraud control, and it should be made on the conversion number rather than on the abuse one.

Per-IP limits catch the careless and punish the legitimate: an office, a university or a carrier NAT range shares one address between hundreds of real people.

Device fingerprinting works right up until someone uses an antidetect browser, at which point every trial is a genuinely new device.

What the verdict returns

Screening at trial signup, with your own account id passed in so the linkage is computed against your accounts only:

{
  "decision": "review",
  "risk_score": 61,
  "reasons": [
    "multi_account_device",
    "residential_proxy"
  ],
  "device": {
    "visitor_id": "hashed",
    "first_seen": "2026-02-14",
    "linked_accounts": 9,
    "multi_account": true
  }
}

linked_accounts: 9 on a device whose first_seen is months old is the entire finding. It says this browser environment has opened nine of your accounts — which no per-account check can see, because each account really was new. The linkage is per-customer and hash-only: your accounts are never linked against another customer's.

Note the decision is review, not block. Nine accounts on one device is a contractor with nine clients as often as it is one person resetting a trial, and the two deserve very different treatment.

What to do about it, in order

Blocking is the worst first move here, because the population contains paying customers who have not converted yet.

1. Measure before enforcing. Run the signal for a month and act on nothing. The distribution will not be what you assumed, and you will find a small tail worth looking at by hand.
2. Limit the resource, not the account. Cap what a trial can consume — seats, API calls, exports — rather than how many trials exist. A resetter loses the value; an evaluator does not notice.
3. Ask for the upgrade. An account on its fifth trial with real usage is a customer telling you your pricing has a gap. The message that converts is an offer, not a warning.
4. Refuse only the unambiguous tail. High linkage, proxy, antidetect, no meaningful usage. Keep it small.

The arithmetic

A worked model. Replace the inputs with yours.

Recovered revenue is 320 × 10% × €300 = €9,600, plus €4,480 of infrastructure you stop donating. The third input is the one everybody gets wrong: the instinct is to multiply all 320 by the plan price and call it recovered ARR. Most of that population leaves rather than pays, and a model that assumes otherwise will justify enforcement that costs more than it returns.

Which is why the honest version of this number needs a holdout — a slice you deliberately leave alone. Without one you cannot distinguish revenue you recovered from churn you caused.

The adjacent problem: competitors in your trial

The same signals surface something teams are often more annoyed by than the free usage: competitors and data brokers taking trials to scrape pricing, feature availability or your customer-facing directory. The pattern is distinctive — a trial that consumes read endpoints heavily, touches nothing that writes, and never invites a second user.

That behavioural half is yours to measure; the network and device half is the same call described above, and the combination is much stronger than either.