$ feature / hwid-locking

Bind every license to a specific machine.

Hardware locking (HWID binding) is what stops "I'll just share my key in Discord" from being a real attack on your revenue. AuthForge ties each license to a configurable number of machine fingerprints: install on machine #1, license activates; try to reuse the same key on machine #2 without freeing up a slot, validation fails. Below is how the flow works, what configuration knobs you have, and how to handle the inevitable "I bought a new laptop" support email.

How HWID binding works

The first time a license is validated from a given device, AuthForge records the fingerprint your SDK sends in hwid and stores it in the next free slot on that license. Every subsequent validation has to come from one of the bound HWIDs; otherwise the response is a rejection, even if the key itself is otherwise valid. Slots fill up to the maxHwidSlots limit you set (default: 1, but typically 1–3 for indie software, higher for B2B).

The fingerprint format is up to your SDK; the official SDKs ship with a sensible default that combines stable hardware identifiers (CPU, motherboard, primary disk) into a hash. You can override it if you have a better signal (Telegram user id, Discord snowflake, IMEI, whatever uniquely identifies the seat in your context).

Seat counts

Each license carries its own maxHwidSlots integer. Set it from the dashboard when issuing a license, or override it on the developer API when bulk-issuing keys. Common patterns:

• 1 seat: strictest. Indie utilities and one-machine licenses.
• 2–3 seats: typical for desktop apps that customers expect to install on a laptop and a desktop.
• 5–10 seats: small-team or family-plan licenses.
• 0 / unlimited: disable HWID enforcement for a particular license while keeping the rest of the validation/rate-limit pipeline.

Reset flow

When a customer needs to free a slot (new laptop, reformatted disk, hardware swap): you have three places to do it:

1. Dashboard: open the license, click Reset HWIDs. One click, no support ticket needed.
2. Developer API: POST /v1/licenses/{licenseKey}/hwid/reset with a Bearer token. Useful for shipping a "reset license" command in your CLI or building a Zendesk macro.
3. Hosted customer portal: configure a self-service reset policy per app (e.g. "one reset per 30 days"), and your customers click the reset button themselves at portal.authforge.cc. No support inbox, no key copy-paste in tickets.

Reset via the developer API

A minimal example using curl. Replace the Bearer token with one of your af_live_* keys from the dashboard.

curl -X POST https://api.authforge.cc/v1/licenses/K3MX-9AB2-LP4Q-7TWN/hwid/reset \
  -H "Authorization: Bearer af_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "reason": "customer_self_service" }'

The endpoint is idempotent: reissuing the same reset is a no-op. A successful reset emits a license.hwid_reset webhook, which most teams pipe to a Slack/Discord channel for audit visibility.

What HWID locking does not do

HWID locking is one layer of defense, not a silver bullet. A determined attacker with full debugger access to the licensed binary can spoof a fingerprint at the syscall level. That's why AuthForge pairs HWID enforcement with signed validation , nonce replay protection, rate limiting, and the self-ban flow . Defense in depth, not a single binary check.

For 99% of indie shipping (small dev tools, B2B utilities, single-binary games), HWID locking eliminates the casual sharing problem completely. For the remaining 1% (high-stakes targets, repeated cracking groups), combine it with self-ban triggers and the rest of the security surface.