Join our Newsletter — 33% off our NHI Course
Home› Guides› Fake Account Creation and Sign-up Fraud Guide: Stopping…
Guide Fraud Prevention

Fake Account Creation and Sign-up Fraud Guide: Stopping Bulk Registrations at the Door

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 13 min read
On this page

Most fraud against an online service needs an account first, and fake accounts are cheapest to stop at the moment they are created. Bulk sign-ups feed promotion abuse, spam, fake reviews, scam profiles, mule networks and SMS pumping, yet many registration flows still accept any email address and phone number with no more than a CAPTCHA in the way. OWASP classes this as automated threat OAT-019 Account Creation. This guide treats the registration stage as its own defensive discipline: the signals available at sign-up, how to layer controls without blocking genuine customers, how to handle accounts that slip through, and what to measure. It is for fraud, trust and safety, product security and identity teams running consumer or marketplace sign-up flows. For what fake accounts are used for afterwards in promotions, see the Promotion and Bonus Abuse Guide.

Key takeaways

  • Treat sign-up as a sensitive business flow. OWASP API6:2023 uses scripted registration to farm referral credit as a worked example; registration needs the same protection as checkout.
  • No single signal works. Combine network, device, email, phone, behaviour and graph signals in a score, and decide friction by risk.
  • CAPTCHA is a speed bump, not a control. OWASP OAT-009 notes CAPTCHAs are defeated with machine reading, image databases and human solving farms.
  • Delay the value, not the sign-up. Hold bonuses, payouts, messaging and listing rights until an account has earned trust, so fake accounts that get through are worth little.
  • Measure cohorts, not blocks. Track what share of each sign-up cohort is later confirmed fake and what share of genuine users dropped off.

What fake account creation is and why it is distinct

OWASP's Automated Threats to Web Applications project defines OAT-019 Account Creation as creating multiple accounts for subsequent misuse: bulk account creation, and sometimes profile population, through the application's own sign-up process. It lists the misuse as content spam, laundering cash and goods, spreading malware, damaging reputation, mischief, and skewing SEO, reviews and surveys. OWASP separates it from OAT-007 Credential Cracking and OAT-008 Credential Stuffing, which abuse existing accounts. MITRE ATT&CK describes the attacker side as T1585 Establish Accounts, including T1585.001 Social Media Accounts and T1585.002 Email Accounts.

The distinction matters because the defences differ. Account takeover defence protects known customers at login; sign-up defence has to judge a stranger with no history, usually in under a second, without asking for documents that most services cannot justify. See the Account Takeover Prevention Guide for the login side.

Fake account purposeTypical targetWhat the attacker needs from the accountSign-up stage tell
Promotion and referral abuseRetail, delivery, ride hailing, bettingA new-customer bonus or referral creditBursts of sign-ups sharing devices, payment cards or address patterns
Spam and scam outreachSocial media, dating, marketplaces, messagingAbility to post or message strangersProfiles populated by script, stock photos, copy-paste bios
Fake reviews and ratingsMarketplaces, app stores, review sitesReview rightsAccounts created in batches then dormant until a review campaign
Money mule and laundering accountsFintech, payment apps, marketplacesAbility to receive and move money or goodsIdentity details reused across accounts, synthetic identities
SMS pumpingAny flow that sends one-time codesNothing: the sign-up itself triggers paid SMS to premium rangesHigh volumes of verification requests to unusual country codes
Inventory and capacity abuseTicketing, limited releases, free trialsMany accounts to bypass per-account limitsSign-up spikes before a release or trial reset

For the SMS-specific case see our guide on Phone Number Fraud; for fraud built on invented identities see the Synthetic Identity Fraud Guide.

Signals available at registration

Registration offers more evidence than teams usually collect. Gather it consistently, log it with the account, and use it both for the live decision and for later investigation.

Signal familyExamplesStrengthWeakness
NetworkIP reputation, data centre or hosting ranges, known proxy and VPN exits, residential proxy indicators, ASN, geolocation mismatch with stated countryCheap, real timeResidential proxies make bad traffic look like home broadband; shared mobile carrier IPs cause false positives
Device and browserDevice fingerprint, emulator and automation framework indicators, headless browser traits, app attestation on mobile, device reuse across accountsStrong for linking accountsPrivacy-respecting browsers look unusual; fingerprints can be spoofed
EmailDisposable or newly registered domains, plus-addressing and dot variants of the same mailbox, mailbox age, domain without mail recordsGood for low-effort farmsLarge free providers offer unlimited mailboxes
PhoneLine type (mobile, fixed, VoIP), recent porting, number reuse across accounts, carrier and country riskRaises cost per accountSIM farms and rented numbers defeat simple checks; sending codes can itself be abused
BehaviourTime to complete the form, typing and paste patterns, field order, copy of identical profile textHard for scripts to fake wellHuman solving farms behave like people
Velocity and graphSign-ups per IP, device, card, address or email pattern per hour; links between accounts sharing attributesBest for catching networksNeeds history and storage; tuning required
Identity and paymentCard or bank account verification, consortium checks, document and liveness checks for high-risk servicesHigh assuranceFriction and cost; only proportionate where the account can move money or reach vulnerable users

Collect only what you need and tell users about it. Device and behavioural data linked to an account is personal data, so document the purpose, retention and lawful basis. See the Residential Proxy Networks and Abuse Guide for the network signal problem in more depth.

Layered controls and when to use them

Design sign-up as a risk decision with three outcomes: allow, allow with friction, or deny. Most genuine users should see nothing extra.

  • Baseline for every service: rate limits per IP, device and email pattern; normalisation of email addresses before uniqueness checks; blocking of known disposable domains; anti-automation on the registration endpoint and API, not only the web form. OWASP ASVS 5.0 requirement V2.4.1 asks for anti-automation controls against excessive calls that could lead to garbage-data creation or quota exhaustion, and V2.4.2 for business flows that require realistic human timing.
  • Consistent responses: registration should not reveal whether an email is already registered. ASVS V6.3.8 extends user enumeration protection to registration and forgotten password flows.
  • Breached password check: ASVS V6.2.12 asks for passwords at registration to be checked against breached password sets, which also blunts later takeover of fake and real accounts alike.
  • Risk-based friction: for medium-risk sign-ups add email confirmation, a phone check, a proof-of-work or a challenge; for high-risk sign-ups require stronger verification or deny.
  • Verification for high-harm roles: sellers, advertisers, money transmitters and dating profiles may justify identity verification. The UK Online Fraud Charter commits marketplace signatories to verify sellers, advertising platforms to verify new advertisers, and dating services to let users verify their identity. See the Identity Proofing and KYC Guide.
  • Deferred value: new accounts start with limited rights: no payouts, low messaging or posting limits, bonuses released after a qualifying purchase or a holding period.
  • Bot management: a dedicated bot management layer can classify automated traffic before it reaches the application. See the Bot Management Guide.

Choosing friction by risk

Risk score bandActionExample
LowAllow silentlyResidential IP, established email domain, unique device, normal timing
MediumAllow with frictionEmail confirmation link plus phone verification, or an invisible challenge
HighStep up or holdHosting IP and reused device: require stronger verification or place the account in a restricted state pending review
Very highDeny or silently restrictKnown farm fingerprint, disposable domain and automation indicators together; consider shadow restriction so attackers cannot tune against the block

Small versus large services: a small shop or start-up should rely on its platform's built-in bot and fraud controls, block disposable domains, normalise emails, rate limit and delay bonuses until first purchase. Large platforms need a scoring service with device and graph signals, model governance, a review queue and a trust and safety team to remove networks after the fact.

After sign-up: catching what got through

Some fake accounts will pass registration, especially those made by human farms. Treat the first days of an account as a probation period.

  1. Re-score on first actions: first purchase, first message, first listing, first withdrawal and profile changes are new decision points with more evidence.
  2. Link accounts: run graph analysis across shared devices, cards, addresses, phone numbers and IP ranges to find networks, then act on the whole cluster.
  3. Watch dormancy: accounts created in batches and left idle are often stockpiles for later campaigns; flag them for re-verification before they gain rights.
  4. Act proportionately: restrict, require verification, then suspend; keep an appeal route for genuine users caught in a cluster.
  5. Feed back labels: confirmed fake accounts become training labels and new rules for the registration score.

Where identity fits

Registration is the start of the customer identity life cycle, and several identity design choices decide how easy bulk sign-up is.

  • Social and federated sign-in: accepting sign-in from large identity providers moves part of the fake account problem to them, but their accounts can also be farmed. Record which provider and whether it asserted a verified email, and score federated sign-ups like any other.
  • Passkeys at sign-up: creating a passkey during registration does not prove a person is real, but it binds the account to an authenticator and makes later takeover and resale of the account harder. See the Passwordless and Passkeys Guide.
  • Machine credentials in the sign-up path: the API keys for SMS providers, email verification, bot management and identity verification services are high-value non-human identities. A leaked SMS provider key lets an attacker send messages at your expense; store these keys in a secrets manager, scope them, cap spend at the provider and alert on unusual volumes.
  • AI agents creating accounts: legitimate agents acting for users will increasingly register on services. Decide whether you allow them, and if so prefer agents that identify themselves and act under a verified user, rather than treating all automation as hostile. See the Bot vs AI Agent Traffic Management Guide.

How to implement

  1. Baseline: measure current sign-up volume, confirmed fake rate per cohort (from later abuse) and genuine drop-off at each step.
  2. Instrument: collect network, device, email, phone and timing signals on every registration, web and API, and store them with the account.
  3. Deploy rules in monitor mode: run velocity and reputation rules for two to four weeks logging what they would have done.
  4. Tune: compare would-be actions against later confirmed abuse; set thresholds that catch most fakes with acceptable false positives.
  5. Enforce gradually: start with friction rather than denial, on one market or one per cent of traffic, then widen.
  6. Add deferred value: change bonus, referral and payout rules so new accounts must earn trust.
  7. Roll back safely: every rule and model version can be switched off individually, and genuine-user complaints are monitored daily during roll-out.

Detection and measurement

Log every registration attempt with its signals, score, decision and rule hits, and every later enforcement action linked back to the account's sign-up record. ASVS V16.3.3 asks applications to log attempts to bypass controls, including anti-automation. Monitor for spikes in sign-up volume by country, IP range or email domain, rising verification code requests to unusual country codes, and sudden changes in completion time.

  • Cohort fake rate: share of accounts created in a week later confirmed fake, by channel and market.
  • Prevented abuse value: bonuses, credits and payouts not paid to accounts stopped at or after sign-up.
  • Genuine friction rate: share of later-good users who saw step-up, and drop-off at each friction step.
  • Time to cluster removal: time from first detection of a fake account network to restriction of all linked accounts.
  • Verification code cost per genuine sign-up: SMS and voice spend divided by good accounts, which exposes SMS pumping.

Framework mapping

FrameworkReferenceApplication
OWASP Automated ThreatsOAT-019 Account Creation; OAT-009 CAPTCHA Defeat; OAT-017 SpammingThreat definition and related automated threats
OWASP API Security Top 10 2023API6:2023 Unrestricted Access to Sensitive Business FlowsRegistration and referral flows exposed through APIs
OWASP ASVS 5.0V2.1.3, V2.4.1, V2.4.2, V6.2.12, V6.3.8, V16.3.3Business limits, anti-automation, breached passwords, enumeration, logging
MITRE ATT&CKT1585 Establish Accounts (T1585.001, T1585.002)Adversary account creation as resource development
NIST SP 800-53 Rev. 5IA-12 Identity Proofing; SI-4 System MonitoringProofing for high-risk roles; monitoring of registration traffic
CWE (cited by OAT-019)CWE-799, CWE-837, CWE-841Interaction frequency, single unique action and workflow enforcement weaknesses

Common failure patterns

  • Protecting the form, not the API: the web page has a CAPTCHA but the mobile app's registration endpoint accepts scripted calls directly.
  • Uniqueness on raw email: plus-addressing and dot variants let one mailbox create hundreds of accounts that each get a welcome bonus.
  • Instant value: bonuses and referral credit paid at sign-up, so every fake account that passes is immediately profitable.
  • Unlimited verification codes: phone verification without limits on destinations and attempts turns the anti-fraud step into an SMS pumping cost.
  • Blocking visibly and statically: fixed, obvious blocks let attackers tune their tooling in minutes; vary responses and use silent restriction for the highest-risk traffic.
  • Trusting the account for ever after one check: an account that passed sign-up is never re-scored, so a farm that ages accounts for a few weeks before use walks past every later control. Re-score at each first-time action and when an account changes email, phone or payout details.
  • No feedback loop: trust and safety removes fake accounts weekly, but the labels never reach the team that sets registration rules.

Practitioner checklist

  • List every route that creates an account: web, app, API, partner and social sign-in.
  • Normalise emails and block disposable domains before uniqueness checks.
  • Rate limit sign-ups by IP, device, email pattern and phone number on every route.
  • Collect and store network, device, phone, email and timing signals with each account.
  • Score registrations and apply friction by risk band, keeping most genuine users friction-free.
  • Defer bonuses, payouts and messaging rights until accounts earn trust.
  • Limit verification code sends per number, destination country and session.
  • Run graph analysis to remove linked fake account clusters and feed labels back to sign-up rules.
  • Report cohort fake rate, prevented abuse value and genuine friction monthly.

Standards and references

Related NHI Mgmt Group resources: Promotion and Bonus Abuse Guide · Bot Management Guide · Synthetic Identity Fraud Guide · Fraud Prevention Guide for Digital Businesses

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org