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 purpose | Typical target | What the attacker needs from the account | Sign-up stage tell |
|---|---|---|---|
| Promotion and referral abuse | Retail, delivery, ride hailing, betting | A new-customer bonus or referral credit | Bursts of sign-ups sharing devices, payment cards or address patterns |
| Spam and scam outreach | Social media, dating, marketplaces, messaging | Ability to post or message strangers | Profiles populated by script, stock photos, copy-paste bios |
| Fake reviews and ratings | Marketplaces, app stores, review sites | Review rights | Accounts created in batches then dormant until a review campaign |
| Money mule and laundering accounts | Fintech, payment apps, marketplaces | Ability to receive and move money or goods | Identity details reused across accounts, synthetic identities |
| SMS pumping | Any flow that sends one-time codes | Nothing: the sign-up itself triggers paid SMS to premium ranges | High volumes of verification requests to unusual country codes |
| Inventory and capacity abuse | Ticketing, limited releases, free trials | Many accounts to bypass per-account limits | Sign-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 family | Examples | Strength | Weakness |
|---|---|---|---|
| Network | IP reputation, data centre or hosting ranges, known proxy and VPN exits, residential proxy indicators, ASN, geolocation mismatch with stated country | Cheap, real time | Residential proxies make bad traffic look like home broadband; shared mobile carrier IPs cause false positives |
| Device and browser | Device fingerprint, emulator and automation framework indicators, headless browser traits, app attestation on mobile, device reuse across accounts | Strong for linking accounts | Privacy-respecting browsers look unusual; fingerprints can be spoofed |
| Disposable or newly registered domains, plus-addressing and dot variants of the same mailbox, mailbox age, domain without mail records | Good for low-effort farms | Large free providers offer unlimited mailboxes | |
| Phone | Line type (mobile, fixed, VoIP), recent porting, number reuse across accounts, carrier and country risk | Raises cost per account | SIM farms and rented numbers defeat simple checks; sending codes can itself be abused |
| Behaviour | Time to complete the form, typing and paste patterns, field order, copy of identical profile text | Hard for scripts to fake well | Human solving farms behave like people |
| Velocity and graph | Sign-ups per IP, device, card, address or email pattern per hour; links between accounts sharing attributes | Best for catching networks | Needs history and storage; tuning required |
| Identity and payment | Card or bank account verification, consortium checks, document and liveness checks for high-risk services | High assurance | Friction 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 band | Action | Example |
|---|---|---|
| Low | Allow silently | Residential IP, established email domain, unique device, normal timing |
| Medium | Allow with friction | Email confirmation link plus phone verification, or an invisible challenge |
| High | Step up or hold | Hosting IP and reused device: require stronger verification or place the account in a restricted state pending review |
| Very high | Deny or silently restrict | Known 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.
- Re-score on first actions: first purchase, first message, first listing, first withdrawal and profile changes are new decision points with more evidence.
- Link accounts: run graph analysis across shared devices, cards, addresses, phone numbers and IP ranges to find networks, then act on the whole cluster.
- Watch dormancy: accounts created in batches and left idle are often stockpiles for later campaigns; flag them for re-verification before they gain rights.
- Act proportionately: restrict, require verification, then suspend; keep an appeal route for genuine users caught in a cluster.
- 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
- Baseline: measure current sign-up volume, confirmed fake rate per cohort (from later abuse) and genuine drop-off at each step.
- Instrument: collect network, device, email, phone and timing signals on every registration, web and API, and store them with the account.
- Deploy rules in monitor mode: run velocity and reputation rules for two to four weeks logging what they would have done.
- Tune: compare would-be actions against later confirmed abuse; set thresholds that catch most fakes with acceptable false positives.
- Enforce gradually: start with friction rather than denial, on one market or one per cent of traffic, then widen.
- Add deferred value: change bonus, referral and payout rules so new accounts must earn trust.
- 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
| Framework | Reference | Application |
|---|---|---|
| OWASP Automated Threats | OAT-019 Account Creation; OAT-009 CAPTCHA Defeat; OAT-017 Spamming | Threat definition and related automated threats |
| OWASP API Security Top 10 2023 | API6:2023 Unrestricted Access to Sensitive Business Flows | Registration and referral flows exposed through APIs |
| OWASP ASVS 5.0 | V2.1.3, V2.4.1, V2.4.2, V6.2.12, V6.3.8, V16.3.3 | Business limits, anti-automation, breached passwords, enumeration, logging |
| MITRE ATT&CK | T1585 Establish Accounts (T1585.001, T1585.002) | Adversary account creation as resource development |
| NIST SP 800-53 Rev. 5 | IA-12 Identity Proofing; SI-4 System Monitoring | Proofing for high-risk roles; monitoring of registration traffic |
| CWE (cited by OAT-019) | CWE-799, CWE-837, CWE-841 | Interaction 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
- OWASP: Automated Threats OAT-019 Account Creation
- OWASP: Automated Threats OAT-009 CAPTCHA Defeat
- OWASP: API6:2023 Unrestricted Access to Sensitive Business Flows
- OWASP: Application Security Verification Standard 5.0
- MITRE ATT&CK: Establish Accounts
- Home Office: Online Fraud Charter
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Promotion and Bonus Abuse Guide · Bot Management Guide · Synthetic Identity Fraud Guide · Fraud Prevention Guide for Digital Businesses