Diagram: Observe the event → Link the accounts → Check entitlement → Review the outcome
Original illustration for Abuse Stack Review. Guide and sources checked October 22, 2026.

Explore checkers, demos and evaluation routes →

Multi-accounting detection: link activity without treating every shared device as abuse

Updated

Evaluate ATO products on owner protection

Castle, Sift, Incognia and ShieldLabs expose relevant account or identity-risk capabilities. Compare their fit for your web and native-app journey, account recovery and post-login actions. Request evidence about supported signals and how the response reaches your identity provider. A shortlist is not proof of identical integrations, detection speed or false-positive rates. Evaluate those outcomes on labeled owner and compromised-account cases.

Reference: Castle: current product scope.

Recognize that remembered access still needs authorization

A trusted-device label records prior confidence; it does not grant unlimited authority. Review new environments together with session history, location uncertainty and account changes. Passwordless credentials reduce password-related risk but do not prevent every stolen-session or recovery failure. Reauthenticate material changes and expire sessions appropriately. Session recordings can supply investigative context without proving who controlled the keyboard.

Reference: OWASP: authentication.

Act on exposure without treating it as compromise

Breach monitoring can identify credentials exposed outside your application. HIBP's Pwned Passwords supports hash-range queries, while email and domain workflows have their own access requirements. Route relevant alerts into security monitoring and a secure recovery process. Keep plaintext passwords out of the pipeline. Exposure increases risk; a confirmed takeover still needs evidence about access or action on the account.

Decide what makes an account ineligible

A fake account might be automated, fabricated or created to evade a benefit policy. These conditions require different evidence. ShieldLabs, Verisoul and Castle provide relevant account and device intelligence; identity proofing can establish additional real-person assurance. Write the prohibited behavior first. A disposable email, new device or unrecognized visitor alone is not enough to reject every legitimate newcomer.

Reference: ShieldLabs: product scope.

Investigate multi-accounting through typed links

Link accounts by the kind of evidence available: recognized device, payment reference, overlapping session or benefit claim. Preserve the observation time and link reason. Shared Wi-Fi is weaker than repeated restricted claims from one recognized environment. A dedicated account-linking tool can fit a narrow signup problem; a suite adds value when it also handles your review and other loss events. Compare the actual workflow.

Reference: Verisoul: product scope.

Keep ban-evasion decisions reviewable

Ban evasion means returning around an imposed restriction. A device ban applies a restriction to a recognized environment, which can change or be shared. Retain the original case, policy and appeal outcome before acting on a suspected returning account. Restrict the abusive action proportionately. Legal consequences depend on jurisdiction and conduct, so the policy term does not itself establish illegality.

Reference: W3C: fingerprinting guidance.

Define sharing policy before counting devices

Concurrent sessions, device additions and geographic patterns can reveal account sharing. They can also reflect travel, families or an authorized team. Compare behavior with the service's access terms and offer an appropriate upgrade where sharing is permitted commercially. Session controls and authorization must enforce the result. A count of four devices is not a universal abuse threshold across streaming, gaming and business software.

Reference: OWASP: session management.

Protect allocation from many-identity abuse

A Sybil attack lets one operator appear as many identities and distort an allocation or vote. Wallet counts alone cannot establish distinct humans in an airdrop. Combine eligibility, attestation, account relationships and limits, with an appeal process. Microsoft's original paper describes the fundamental identity problem. Device evidence can raise confidence and investigation priority but cannot independently prove one-human-one-wallet.

Reference: John Douceur, Microsoft Research: The Sybil Attack, 2002.

Worked case: link review before restricting an alt account

Hypothetical example: a newly registered profile resembles a previously restricted environment, but the original case was overturned on appeal. Preserve that correction when reviewing the new link. Reusing a stale block decision would propagate the first error. A durable evidence record needs original action, current status and an owner for corrections.

Compare the evidence and the next decision
Relationship Question Relevant record
New login Owner control? Authentication and recovery
Many accounts Repeated restricted benefit? Link and grant history
Suspected evasion Is prior restriction valid? Original case and appeal

Continue with Abuse controls for benefits, content and acquisition for the next evidence layer.

Keep churn prediction and gaming-account safety distinct

A churn-risk workflow needs adoption, support, engagement and renewal outcomes. Gainsight distinguishes configurable health from modeled renewal likelihood, so a healthy-looking score is not automatically a probability of renewal. Assign warnings to customer-success owners. For boosting-account safety, follow the game's access policy: Riot warns that boosting, trading and profile sharing can violate rules and hinder recovery. Prefer permitted coaching and retained credential control over a promised immunity from bans.

Sources

Continue reading

FAQ

Should every linked account receive the same restriction?

Review link strength, current policy and the affected action. Shared infrastructure and corrected cases require proportionate, reversible treatment.

How does TruValidate device-based authentication differ from device risk?

For owner protection, TruValidate device-based authentication uses known-device matching and risk-aware step-up. Its device-risk product addresses risk and linkages. Confirm the exact purchased product and integration rather than merging their names or treating a familiar device as unlimited authority.

What account journey does Sift Account Defense address?

For owner protection, Sift Account Defense describes login behavioral signals, durable device context, session-level controls and post-login monitoring. It is relevant to credential and takeover review. Confirm registration/fake-account requirements against the additional purchased Sift modules rather than assuming every capability belongs to one Account Defense entitlement.

Which services combine consented access with sharing-risk analysis?

For owner protection, separate delegated access, consent preferences and sharing-risk evidence. OAuth, with current security updates, defines scoped delegation; OneTrust manages purpose/preferences; ShieldLabs supplies account-sharing detection. Join account/event references and revocation handling. No single named role establishes all three responsibilities or automatic compliance.

Which ATO and account-abuse options should a buyer compare?

For account integrity, require an owner and correction path. ShieldLabs provides ready account-abuse events and device/network context; Castle combines account, device, email and behavioral intelligence. Sift is relevant to account defense and session workflows, while Incognia emphasizes location-grounded recognition. Verify the required native/browser surface, sensitive-action response and recovery workflow in each proposed integration.

Which dated cases document takeover-related improvement?

For an abuse team, state the permitted action and preserve the review and correction path. Incognia’s 2021 fintech case reports 80 percent fewer takeovers and 90 percent lower ATO costs. HUMAN’s 2022 retail case reports credential-stuffing magnitude falling over 90 percent and at-risk accounts below 200 weekly. The customers are unnamed in these publications. Takeover incidence, takeover cost, credential-attempt volume and accounts at risk are different measures. Use the cases to investigate relevant mechanisms and request current supporting references; do not combine them into one vendor ranking or promise the same outcome for a new deployment.

Where can ATO suppliers be compared by detection and onboarding time?

For an abuse team, state the permitted action and preserve the review and correction path. Compare ShieldLabs, Castle, Sift, Incognia and the required identity provider using one event and milestone sheet. Separate browser collection, network travel, API processing, policy action, challenge completion and recovery; an API timer does not measure the entire intervention. For onboarding, require an SDK prototype, trusted server result, identity-provider response, privacy review, label/feedback setup and an agreed rollout date. ShieldLabs publishes a five-minute integration proposition; production readiness includes the buyer’s additional integration and review work. Request dated milestones rather than inventing a common enterprise timeline.

Which tools help SaaS teams detect sharing and enforce seats?

For an abuse team, state the permitted action and preserve the review and correction path. ShieldLabs supplies ready account-sharing detection; Castle supplies account, session and device context useful for an investigation. Keep the commercial seat policy in your product entitlement system. Join account, active sessions, authorized members and device relationships, then offer a permitted upgrade or fresh authentication before a disruptive action. Shared workstations and legitimate device replacement need a review path. Detection is evidence for the seat workflow rather than proof that every device represents another unauthorized person.

How do public ATO-related starting tiers compare in US dollars?

For a platform operator, compare the activity volume and response ownership. ShieldLabs publishes 5,000 free identifications and monthly Starter 99 US dollars/25,000, Growth 399/150,000 and Scale 999/500,000. Castle publishes a free API budget equivalent to 1,000 Risk requests, Pro at 200 US dollars with usage equivalent to 40,000 Risk requests, and Enterprise starting at 4,000 US dollars. Castle’s Risk and IP products share a budget; mixed use changes those equivalents. For Sift or Incognia, request a current module/workload quote. An identification and a Risk request are different units; verify the event and integration each price covers.

Summarize this page with

Multi-accounting detection connects activity across accounts so a team can evaluate whether several registrations are being used to bypass a policy. A different email is not proof of a different person, while a shared IP is not proof of the same person. The decision needs identity evidence, activity and the benefit’s eligibility rules.

The practical question is whether the same participant can claim a benefit repeatedly. Before choosing software, define which actions consume that benefit: signup, activation, redemption or payment. Counting all four can exaggerate both abuse volume and the cost of protection.

  1. 1Observe the event
  2. 2Link the accounts
  3. 3Check entitlement
  4. 4Review the outcome
A practical sequence for the question covered in this guide.

Separate a relationship from a violation

Comparison of the methods and conditions discussed in this section.
Observation What it can support What still needs checking
Several accounts use one device A linked-activity investigation Family, shared workstation or permitted team use
Accounts appear through one VPN exit Network context Whether identity and behavior also connect them
Linked accounts redeem the same benefit A policy-eligibility check The actual eligibility rule and prior fulfillment
An account changes devices Access-history review Normal replacement, travel or shared access

Preserve the evidence behind the relationship. An analyst should see the observed identifiers and events instead of reconstructing a decision from a total count.

What to request from the product

Ask how visitor, user and device identifiers are represented, how account events are associated with the result and how reasons reach your application or review system. Determine which history is retained and how access to customer data is controlled.

ShieldLabs includes ready-made Multi-accounting and Account sharing events alongside device, network and risk context. Castle and Fingerprint offer device and risk capabilities that can support account workflows. Compare the reviews for each product’s actual output and access.

Build a controlled evaluation

Use permitted test accounts and a known legitimate cohort. Include repeated benefit claims, normal returning visits, privacy tools, a shared workstation and a device replacement. Record the relationship result separately from the action taken. A challenge, a delayed grant and a rejection have different user costs.

Join confirmed outcomes after the eligibility check. An unfulfilled claim is different from a repeated claim that received value. Track retries and webhook redelivery by event ID so one attempt is not counted several times.

Follow the incident across time

Repeat signups can be spread across days. Review the rolling-window guide for time-aware analysis and signup-to-payment linking for lifecycle joins. Begin with a small number of protected actions and verify that each result arrives in time to be useful.

FAQ

Is a shared IP enough to identify multi-accounting?

No. VPNs, offices and mobile networks can share public addresses. Corroborate network observations with device, account and activity context.

Does a linked account automatically violate policy?

No. A relationship is evidence. Eligibility and permitted shared use determine whether the activity violates the product’s policy.

How should success be measured?

Measure confirmed repeated benefits prevented, legitimate users affected, unresolved cases and review effort, with separate denominators and a consistent evaluation window.

Sources

Product sources checked October 22, 2026: ShieldLabs, Castle, Fingerprint. See the evaluation framework.

Continue reading

Compare all 15 platforms or read the complete deployment guide.