"Ban the device" means something different in a game, a FiveM server, a SaaS login, and a licensed app. HWID-Guard weighs the signal that actually fits — not one blunt fingerprint for everything.
A generic HWID check bans innocent players and misses real abusers. The difference between good and useless is weighting the right identifiers for the case. That's the product.
A player is banned for cheating and reappears in minutes on a new account — same PC. A small team can't run an anti-cheat department, and needs a signal that works in the game and the launcher, before login.
A weighted composite of hardware identifiers, scored server-side, with a threshold that needs multiple signals — so swapping one part won't ban an innocent player. VM detection stops players spinning up a virtual machine to reset their hardware.
A cheater kicked from an RP server is back in minutes on another Rockstar account — the account is disposable, the PC isn't. Small communities rely on manual reports; by the time staff re-ban, the damage is done. Multi-server networks want a ban to optionally carry across servers.
FiveM exposes a strong, anti-tamper hardware token (GetPlayerToken) that most platforms don't have. Account and network identifiers (steam:, ip:) are ignored — they're not the device. Drop-in Lua SDK.
A free tier gets hammered with throwaway accounts — trial abuse, coupon farming, credential stuffing, bots clearing signup at inhuman speed. IP bans miss residential proxies; CAPTCHA alone adds friction and doesn't stop re-entry: the same automated machine comes back on a new account.
The browser has no hardware HWID — so the strong signal here is origin classification. The client reports raw signals (webdriver, headless, automation) and the server decides bot vs person; a validated CAPTCHA/liveness pushes toward person. VM detection catches datacenter bots.
Paid software gets cracked, or one license key is shared across many machines. Blocking by the key alone doesn't work — a string is trivial to copy. What has to stay bound is the device, and you need visibility into how many devices actually activated a license.
The desktop composite applies, but with more rigor — a false positive here blocks a paying customer, so the threshold and the review path matter more than in a free game. Bind activations to hardware, count real devices per license.
A botter or multi-client abuser is banned and reappears on a fresh character, same machine — and the level/item economy rots for everyone. Owners are usually solo, with no anti-cheat team; IP bans punish shared connections and account bans cost the abuser nothing.
A native collector in the client (OTClient C++) reads the desktop hardware composite, weighed server-side; IP and account are ignored — they're not the device. VM detection stops the "fresh virtual machine" reset trick. Built by someone who runs one of these servers.
One human spins up many accounts to smurf in ranked, dodge MMR, or evade a competitive ban — wrecking matchmaking for everyone else. The accounts are free and infinite; the machine behind them is not.
Device reputation correlates many accounts to one device — you see the single machine behind N accounts and can cap accounts-per-device or flag the smurf. Ambiguous cases (a shared family PC, siblings on one machine) go to REVIEW, not an automatic ban.
A scammer, a banned seller, or a repeat-offender returns under a new profile and email to keep abusing buyers or the community. Moderation bans the account; the person and their machine are unchanged, so they're back the same day.
Ban the device, not the profile — the banlist keeps that hardware out across every new signup. A public or shared machine (library, internet café) goes to REVIEW so you don't wall off a whole location over one bad actor.
Scalpers and bots hoard scarce slots — restaurant tables, appointments, event tickets, exam/visa bookings — across dozens of throwaway accounts, then resell or no-show. Banning the account or the email does nothing: it's one machine behind many identities, and a repeat no-show abuser is back the same day with a fresh signup.
Booking is mostly web, so the strong signals are origin classification (webdriver/headless/automation → bot) and device-to-accounts correlation — N accounts booking from one device is the scalper pattern. A banned no-show device stays out across new signups.
These are the patterns we've mapped — games, RP servers, SaaS abuse, licensed software, ranked smurfing, marketplaces, bookings, and fraud/anti-abuse stacks. The same API adapts to whatever your device story is. Tell us your setup and we'll point you at the right weighting.
Get your API key