Fake accounts are accounts registered in bulk, usually by scripts, to be misused: to post spam, claim sign-up credits, or get around per-account limits. The FTC, for example, alleges that ticket brokers bypassed Ticketmaster's purchase limits "by creating thousands of Ticketmaster accounts". To detect them, follow new registrations into verification and first use. A surge of signups is a lead; the stronger evidence is accounts that repeat a workflow the service does not permit.
This is not the same as attacks on existing accounts, and it is not proof that a person is fake. "Suspected automated signup" is often a defensible label where "fake person" is not.
What a fake account is
For a site operator, a fake account is one registered to be misused rather than used the way a customer would. OWASP's name for the automated version is OAT-019 Account Creation, defined as "create multiple accounts for subsequent misuse," and "fake account" is one of the other names it lists. The misuse it names includes content spam, laundering cash and goods, spreading malware, and skewing SEO, reviews, and surveys. OWASP's API6 entry adds a referral example, where a script automates registration so that each new user adds credit to the attacker's wallet.
The form itself rarely separates these accounts from real sign-ups. Real users arrive spread over time, finish verification at varied speeds, and do different things first. A batch of fake accounts may share a creation burst, a client configuration, or one repeated first action, often the one that grants something: a credit, a post, a review. Compare the cohort with a normal onboarding period before you read much into any of these.
None of those traits proves fraud, and bot detection doesn't either. It can show that registrations were automated. Whether an account breaks your rules is shown by what it does next, which the rest of this guide follows.
Follow the account beyond the form
Build a bounded cohort of accounts created during the period under investigation. Compare it with a legitimate onboarding period using the same product flow.
Record registration outcome, verification state, time to first useful action, and the actions that consume resources or award benefits. Use internal account references, not raw passwords, codes, or unnecessary profile data.
The first-use step matters because different abuse goals leave different traces. Accounts created to claim a benefit should be reviewed against that benefit's rules. Accounts created to post repetitive content need a content and workflow investigation. A signup score alone cannot settle both.
Separate weak similarities from stronger evidence
| Observation | What it supports | What it does not establish |
|---|---|---|
| Shared source IP | A shared network origin | One operator or one person |
| Similar browser properties | A common client configuration | Unique device identity |
| Fast registration | A short completion time | Malicious intent |
| Repeated first-use sequence | A behavior worth grouping | That every grouped account is abusive |
| Repeated violation of a server-side entitlement rule | A concrete policy failure | Who owns the accounts |
Use weak signals to choose a sample for review. Avoid converting a cluster into a permanent denylist without examining the actual behavior.
An enterprise administrator importing users, a classroom onboarding together, or a permitted partner process may legitimately create accounts in a burst. Maintain an explicit owner and scope for those workflows.
Put controls where misuse becomes possible
Consider separating account creation from permission to perform costly or abuse-prone actions. A newly created account may need to complete a relevant verification step before sending invitations, posting broadly, or receiving a promotional entitlement.
Do not add friction without naming the action it protects. Requiring an extra step on every signup may damage completion while leaving a poorly protected benefit endpoint unchanged.
OWASP's sensitive-business-flow guidance includes automated registration connected to referral abuse. The general lesson is to review the complete value-granting flow, not just its first screen.
Give legitimate bulk onboarding a defined route
Approved automation should have bounded permissions and an accountable owner. It should not depend on an unlimited exception for a shared IP or a copied user-agent string.
Document who can invoke the onboarding path, how many accounts it may create, which privileges those accounts receive, and when the exception is reviewed. Keep that path separate from public self-service signup where possible.
For suspicious public registrations, start with a reversible restriction on the affected first-use action. Preserve enough evidence for review before deleting accounts or their data. Some users may be caught by association rather than behavior.
Measure completed useful work
Track signup completion, verification completion, and the misuse outcome separately. Blocking more registration requests is not sufficient evidence that the service is healthier.
Inspect where rejected users stop and whether they can recover. Also check whether unwanted activity simply moved to older accounts or another entry point.
The promo abuse and multi-accounting use case is the relevant product context. If benefits are being granted repeatedly, continue with promo-code abuse prevention and take the signup cohort into that review.