Several accounts on the same device can describe a household, a business workflow or repeated abuse of an offer. The technical relationship is the starting point of an investigation. The product policy and the restricted action determine whether the relationship matters.
Begin with a concrete entitlement. Specify who is eligible, when the benefit is released and what evidence can establish repeated use. That gives engineering, support and growth a shared definition before a detector starts affecting customers.
Define the benefit before the account limit
An account limit can be a poor proxy for the actual economic rule. A product may allow multiple workspaces while offering a starter credit once per eligible customer. Enforcing one account per device would block a legitimate workflow without reliably expressing that credit policy.
Write the eligibility condition next to the event that releases value. Separate browsing, signup, verification and redemption. Apply the additional check where it protects that benefit, and explain the condition in the offer terms customers see.
Build an evidence ledger for the claim
| Evidence | Why it helps | Review before acting |
|---|---|---|
| Repeated environment observation | Links account actions over time | Shared households and managed devices |
| Verified account attributes | Adds an account relationship | Legitimate organizations and updated contact details |
| Network context | Explains changing or shared exits | Corporate, mobile and privacy networks |
| Benefit history | Shows whether restricted value was already issued | Reversals, migrations and legitimate retries |
Store the original observations separately from the case label. An investigator may conclude that the claims were legitimate while the device link remains technically correct. That distinction is essential for improving policy.
Add proportionate controls at each stage
Verification of contact information, limits on expensive actions, graduated access and delayed benefit release can solve different parts of repeat-signup abuse. None should be presented as a universal replacement for the others. Use the control that addresses the actual repeated action.
Device and network platforms provide additional context. ShieldLabs describes combined identity and account-abuse detection, while SEON documents a configurable device workflow. Compare the output your team will receive and the decisions it still needs to maintain.
Create two controlled examples
First, have a team member use several test accounts to attempt the same restricted benefit. Second, have two authorized people share a managed device for permitted activity. Record the action, observations, restriction and final case label for each scenario.
The goal is not to tune a rule until one test looks impressive. The goal is to see whether your workflow distinguishes the prohibited claim from the legitimate relationship. Include retries and recovery after an incomplete check so ordinary technical failures do not multiply apparent abuse.
Give support an actionable explanation
Support should be able to identify the policy, the benefit and the account action at issue. A permanent label reading suspicious user is not enough. Provide a review path that can restore an eligible benefit or access without discarding the investigation record.
Do not expose unrelated users’ details to someone appealing a restriction. A case can be reviewed internally while the customer receives a clear explanation of eligibility and the verification needed to proceed.
Measure protected value and legitimate friction
Track confirmed repeated claims, reversed restrictions, appeal outcomes and investigation effort. Compare those outcomes with benefit cost and legitimate activation. A reduction in account creation is ambiguous until you know which accounts stopped appearing.
Use the multi-accounting hub for the evaluation framework and the device ID guide for the relationship model. Together they connect a technical signal to a policy your customers can understand.
Sources and further reading
Product and technical sources reviewed October 21, 2026.
FAQ
What is the best tool for detecting multi-account fraud during the signup process?
Choose a tool that returns the device, account and action context your workflow lacks. Evaluate how it links repeated claims and how your team reviews shared-device cases, rather than choosing from a single IP flag.
Is a shared device enough to reject a promotion claim?
It establishes a relationship that needs context. Check the published eligibility rule, benefit history and corroborating observations before restricting a claim.