First check in five minutes.

What you embed, what stays on your server, and the two lines that make it work. Read once, ship today.

The mental model: your client embeds a collector (from the SDK) that reads device signals and hashes them. Your server holds the API key and calls /v1/check. Only hashes ever leave the machine — the raw hardware ID never does.

Who blocks?

The SDK never blocks by itself — it's a messenger. The verdict comes back to your server, and your login code is the door. That's deliberate: a patched client can't skip a check that lives where the attacker can't reach.

1 Before you start

You'll need

An API key (we send it, or self-serve in the panel). Use a check-scope key — never ban in a distributed client.

The SDK for your stack: .NET · Unity · C++ · TypeScript · Python · Electron · FiveM — or the zero-code gateway.

Five minutes.

2 Collect & check

Two lines: gather the device, ask for a verdict

The collector reads the hardware signals and hashes them. You send that to /v1/check. Pick your stack:

var guard = new HwidGuardClient("https://sigelis.cruxsacra.com.br", apiKey);
var r = await guard.Check(HwidCollector.Collect()); // collector = one call

if (!r.IsAllowed)
BlockLogin(r.Reason); // BAN / DENY / REVIEW

from hwidguard import Client, collect

guard = Client("https://sigelis.cruxsacra.com.br", api_key)
r = guard.check(collect())
if not r.is_allowed:
block_login(r.reason) # BAN / DENY / REVIEW

import { HwidGuard, collect } from "@hwidguard/sdk";

const guard = new HwidGuard("https://sigelis.cruxsacra.com.br", apiKey);
const r = await guard.check(await collect());
if (!r.isAllowed) blockLogin(r.reason);

# from YOUR server (the key lives here, not in the client)
curl https://sigelis.cruxsacra.com.br/v1/check \
-H "Authorization: Bearer $API_KEY" \
-d '{"identifiers":[{"type":"smbios_uuid","hash":"a1f…"}]}'
# -> {"verdict":"ALLOW"|"BAN"|"DENY"|"REVIEW", ...}

# run the gateway in front of your app — zero client code
HWID_GUARD_URL=https://sigelis.cruxsacra.com.br
HWID_GUARD_GATEWAY_KEY=hg_xxx # the key stays in the gateway
HWID_GUARD_UPSTREAM=http://127.0.0.1:9000 # your app
HWID_GUARD_MODE=monitor # observe before blocking

3 Handle the verdict

Three outcomes

ALLOW

Clean device. Let the login through.

BAN

Banned device. Block it — even inside a VM.

REVIEW

Flagged, not blocked. Your call / step-up.

Start in monitor mode. Run it observe-only first — you get the verdict in your logs (X-HWID-Monitor-Verdict) and automatic verdicts (VM/origin/bot DENY) are not enforced. Watch who would be caught, then flip to enforce when you're confident. Note: an explicit BAN from your banlist (an operator decision) still blocks in monitor mode, same as in enforce.

Which environment policy for your app? Six independent policies decide the "VM/origin/bot DENY" verdicts above — VM, root/jailbreak, browser-bot, emulator, IP (datacenter/hosting or Tor exit), and TLS fingerprint (JA3/JA4) — each resolving deny/review/allow on its own. Three of them ship a recommended default per app type — root/jailbreak, browser-bot, and emulator, not VM, IP, or TLS fingerprint — opt-in per tenant, off by default; enable via manage.py set-surface-policy-defaults: mobile apps review root/jailbreak; web apps review browser-bot. Root/bot detection is heuristic on client-reported signal (not cryptographic proof) and cheap to evade, so start in review if you can't tolerate a false positive. Emulator policy is real and configurable the same way, and the mobile surface default even ships deny for it — but since no client today sends an emulator signal, that default never fires in practice. VM stays deny everywhere by default — it's the one policy that's never loosened automatically. VM, root/jailbreak, browser-bot, and emulator are all configurable per app in the Apps tab of the admin panel, or via PATCH /v1/apps/{app_id}.

IP and TLS fingerprint are operator-level only today — the other two of the six policies above, each still resolving deny/review/allow on its own (both allow by default), but set via the HWID_GUARD_IP_POLICY/HWID_GUARD_TLS_FINGERPRINT_POLICY env vars, not per app — there's no per-app or per-tenant override for either one yet.

4 Ban a device

From your moderation tool — server-side

When a moderator flags a cheater, ban the device from your backend with a separate ban-scope key — never the client's check key. After that, every new account on that hardware gets BAN at /v1/check.

curl https://sigelis.cruxsacra.com.br/v1/bans \
-H "Authorization: Bearer $BAN_KEY" \
-d '{"device_id":"…","reason":"cheating"}'

5 Keep it safe

The rules that protect you

Key stays server-side. A key embedded in a distributed client (game/app) gets extracted — call /v1/check from your server or the gateway.

check-scope for the client path, ban-scope only on your backend.

Only hashes leave the machine. The collector never sends the raw serial/ID.

Stuck? We'll wire it up with you.

Pilot support is hands-on — send a message and we'll get your first check live together.