Fake account prevention

A scaled signup farm in 2026 mints accounts for less than a dollar per identity, assembled from disposable phone numbers, throwaway emails, rotating residential proxies, and per-account fingerprint profiles from anti-detect browsers. Every identifier the traditional defenses check has become a commodity the operator can cycle through at will. What survives the rotation is the device itself, which is why the defense that holds up is a stable device identity that links accounts back to the same operator no matter which surface-level identifiers change.

This is the third post in the abuse cluster. Related: account takeover prevention, credential stuffing, and promo abuse prevention.

What “fake account” means

The phrase covers a few distinct attack patterns that look similar at the signup endpoint but have different motivations:

Free tier abuse. Sign up many accounts to consume free credits, free trials, free API quota, free storage. Common on developer platforms, AI services, cloud storage, and SaaS with generous free tiers.
Multi-accounting for promo abuse. Sign up many accounts to redeem one-per-customer promotions repeatedly. Covered in promo abuse prevention.
Ban evasion. A user banned from a platform creates a new account to re-enter. Common on social, marketplaces, gaming.
Engagement manipulation. Sign up many accounts to inflate metrics: likes, follows, votes, reviews, comments.
Synthetic identity fraud. Sign up accounts using combinations of stolen and fabricated personal information, typically as a precursor to financial fraud months later.
Resale and farming. Sign up many accounts to sell to other operators (often to be used for one of the above purposes).

The economics differ but the operational pattern is the same: high-volume signup, low per-account value, defeated by anything that links the accounts back to the same operator.

A modern signup farm operation has three layers.

Identity supply. Disposable email services (tempmail.io, mail.tm, hundreds of others). SMS verification services that rent phone numbers per OTP for $0.05 to $0.50 (SMS-Activate, 5sim, SMSPool). Personal information generators that produce plausible names, addresses, and dates of birth at scale. Stealer-log data and breached identity databases for synthetic identity construction.

Infrastructure. Residential proxy networks for IP rotation. Anti-detect browsers (Multilogin, Octo, Dolphin Anty, GoLogin, AdsPower) for per-account fingerprint isolation. Automation frameworks layered on top of the anti-detect browsers to script the signup flow.

Orchestration. Operators run the farm through automation scripts that pick an email, pick a phone number, pick a proxy, launch a profile, run the signup script, save the resulting credentials, repeat. A single operator with this setup can produce thousands of accounts per day.

DataDome’s account farming write-up covers each layer in detail (DataDome: Account Farming). The operational sophistication is high but the engineering cost is low, because most of the components are commodity products with their own user communities and Telegram support channels.

Why email and IP-based defenses fail

The traditional fake-account defenses were variations on “verify the user is who they say they are by email, by phone, and by IP.” Each has been undermined.

Email verification

Email verification proves the user controls an inbox. It does not prove that inbox is uniquely the user’s, that the user is a real person, or that they are not running the verification through an automated email handler.

Disposable email services provide thousands of throwaway addresses with full inbox access.
Email forwarding services (anonaddy.com, simplelogin.io) provide unlimited per-service aliases that all forward to one real inbox.
Plus-addressing on Gmail (user+anything@gmail.com) provides an effectively infinite supply of distinct addresses on a single account.
Catch-all domains (anyone with a domain can configure *@domain.tld to deliver to one mailbox) provide unlimited addresses per domain.

Defenses that reject disposable email domains help on the low-effort end and miss everything sophisticated.

Phone verification

Phone verification used to be the strongest signup signal. In 2026 it is no longer reliable, and the send-code endpoint is an attack surface in its own right: SMS pumping fraud covers the scheme where bots drain your messaging budget through it.

SMS-activation services rent real phone numbers in dozens of countries for $0.05 to $0.50 per OTP delivery. The number can be used once and discarded.
The number range pools rotate frequently, so blocking specific number prefixes only works briefly.
Voice OTP can be intercepted similarly.

Phone verification still has value because it raises the cost per fake account, but it no longer proves uniqueness.

IP-based throttling

Per-IP rate limiting on signup is defeated by residential proxies for the same reasons it is defeated for credential stuffing. The attacker rotates IPs faster than the rate limit can fire.

CAPTCHA-solving services solve CAPTCHAs at industrial prices ($1 to $5 per 1,000 solves). For a $0.50 per-account fake-account margin, $5 per 1,000 CAPTCHA solves is a rounding error. CAPTCHA at signup costs every real user a few seconds and costs the attacker pennies per account. When the signup flow genuinely needs an automation check, CAPTCHA alternatives that score the session invisibly are a better fit than a puzzle.

What works: linking accounts by device continuity

The single defense that meaningfully degrades signup farms is device continuity. An attacker can rotate emails, phones, IPs, names, fingerprints, and behavioral patterns far more easily than the underlying device.

The premise is simple. A given physical machine, even one running anti-detect browser profiles, leaks signals that are operational rather than per-profile:

The host GPU’s performance characteristics under microbenchmarks.
The host CPU’s timing fingerprint.
The TLS stack’s behavior at the network layer in ways the anti-detect browser cannot fully spoof.
The proxy provider used (inferred from the IP pattern).
The hour-of-day pattern.
The behavioral signature derived from the operator’s interaction style.

A device intelligence layer that computes a stable visitor fingerprint per device lets the application ask: “Is this signup from a device that has produced other signups recently?” If yes, treat the signup as part of a farm operation. If no, allow normally.

The visitor fingerprint is what differentiates a device-continuity defense from an IP-based defense: IPs and per-profile fingerprints rotate constantly, while the device behind them persists.

Proximity detection addresses the same problem from a different angle: detecting that two accounts are being managed from physically nearby devices (same Wi-Fi network, similar Bluetooth ambient signal, correlated motion-sensor patterns on mobile), which is the typical setup for a small farm operating a single physical location. The device intelligence layer makes this kind of cross-account clustering possible at the moment of signup.

A practical fake-account defense layers signals from cheap to expensive.

Layer 1: Cheap server signals

TLS fingerprint vs claimed browser. A signup from tls-client or curl-impersonate with a Chrome UA is automation.
IP class. Datacenter IPs for consumer signup are almost always automated. VPN and known proxy IPs are higher-risk.
Email pattern. Throwaway domains are flagged for review. Catch-all and plus-addressing variants are not blocked but are clustered against the underlying inbox.

Layer 2: Device intelligence

Device classification. Anti-detect browser detection. Headless framework detection. Emulator detection on mobile.
Visitor fingerprint. A stable identifier for the device (visitor_fingerprint.id) that survives the surface-level identifiers the operator rotates.
Fingerprint lifecycle. The history attached to that identifier: when the device was first seen, when it was last seen, and how many sessions it has produced (visitor_fingerprint.lifecycle.seen_count).

Layer 3: Account graph

Has this visitor fingerprint created accounts before? If yes, what was the outcome?
Does the fingerprint’s lifecycle look like a farm device? A device that has produced dozens of sessions but holds no established account is operating, not browsing.
Does this signup share infrastructure markers (proxy ASN, browser version pattern, behavioral pattern) with a known farm operation?

Layer 4: Friction proportional to risk

Low risk: allow, no friction.
Medium risk: email verification.
High risk: phone verification, or a step-up that requires real-world identity.
Confirmed farm: silent acceptance (let the signup complete from the user’s perspective but isolate the account in a sandbox for monitoring). Outright blocking tells the operator they have been detected.

The graduated-response pattern lets the system charge friction proportional to the risk evidence rather than uniformly. Most real users see no friction. Most farm accounts get filtered before they reach productive use.

Sandbox-and-monitor over hard-block

For confirmed-farm accounts, the response that learns most is silent isolation rather than blocking.

Let the signup complete. The user-visible flow finishes normally.
Flag the account internally. It does not reach public surfaces: posts are invisible to other users, engagement is not counted, API calls are quietly throttled.
Watch what the operator does with it. The behavioral data from active-use farm accounts is valuable for tuning the detection of future signups.
Periodically test whether the account is being shared with downstream buyers (a sudden change in behavior or geography after a quiet period suggests the operator sold it).

The operator does not learn they were caught. The defender learns what the farm looks like in operation.

This is the same pattern that mature anti-spam, anti-fraud, and anti-cheat systems converge on: shadow-bans, isolation, and information collection beat hard rejection because they degrade the attacker’s signal about what works.

Free tier abuse specifically

Free tier abuse has the clearest economics of any pattern here: the attacker’s goal is to consume your free quota without paying. The standard responses:

Reduce the free-quota size. If the free tier is large enough that 1,000 accounts produce meaningful value, the attacker will sign up 1,000 accounts.
Tie the free tier to identity. Require email verification (catches the easiest cases). Require phone verification (catches mid-tier cases). Require credit card verification (catches all but the most determined).
Link by device. Use the visitor fingerprint to refuse the free tier to a device that has already consumed it. The user-visible result is “you have already used the free tier on this device,” which is the truthful and useful message.
Watch for consumption patterns. A real free-tier user evaluates the product and decides whether to upgrade. A farm account drains the quota linearly. The difference is detectable in the first hours of use.

SEON’s writing on account opening fraud covers free-tier-specific tactics in detail (SEON: Account Opening Fraud).

How Foil supports it

Foil’s role in fake-account prevention is the device intelligence layer that makes account graphing possible. The SDK collects fingerprint, network and behavioral signals during the signup interaction and produces a sealed token the application verifies server-side. From there the application gets:

A decision: a bot, human, or inconclusive verdict with a risk score.
A stable visitor fingerprint (visitor_fingerprint.id) for the device, with a lifecycle history of when it was first seen and how many sessions it has produced.
Attribution labels flagging anti-detect browsers, headless frameworks, and agent tooling.
A durable device-to-account link, built by attaching each session to the account it produced (sessions.attachClientUser).

A typical signup integration:

import { Foil, safeVerifyFoilToken } from "@abxy/foil-server";

const client = new Foil({ secretKey: process.env.FOIL_SECRET_KEY });

app.post('/api/signup', async (req, res) => {
  const result = safeVerifyFoilToken(req.body.foilToken, process.env.FOIL_SECRET_KEY);
  if (!result.ok || result.data.decision.verdict === 'bot') {
    return res.status(400).json({ error: 'signup_temporarily_unavailable' });
  }

  const { visitor_fingerprint, session_id } = result.data;
  if (!visitor_fingerprint) {
    return requirePhoneVerification(req, res);
  }
  const visitorId = visitor_fingerprint.id;

  // The account graph: what has this device done before?
  const priorAccounts = await accounts.findByVisitor(visitorId);
  if (priorAccounts.length >= 3) {
    return requireKYC(req, res);
  }

  const session = await client.sessions.get(session_id);
  const labels = session.attribution.labels;

  if (labels.some((l) => l.kind === 'evasion' && l.value === 'anti-detect-browser')) {
    return enableSandboxMode(req, res, visitorId);
  }

  if (session.network.anonymity.hosting) {
    return requirePhoneVerification(req, res);
  }

  const account = await createAccount(req.body, { visitorId });
  await client.sessions.attachClientUser(session_id, account.id);
  return res.json({ accountId: account.id });
});

The decision and the fingerprint history provide the evidence, and the application encodes its own policy on top of them. The attachClientUser call at the end is what builds the account graph: every future session from this device resolves to the same visitor fingerprint, and the fingerprint carries the list of accounts it has produced.

That division of labor is what makes the defense durable. Emails, phone numbers, IPs, and per-profile fingerprints will keep getting cheaper to rotate, while the physical device behind them stays expensive. A defense anchored on device continuity holds up as the farm tooling evolves because it keys on the one input the operator cannot acquire cheaply at scale.