Feature

Lua whitelist key system with HWID authentication

Product informationSources dated October 2026 · Vampauth Team · Vampauth compatibility reviewed against the November 4, 2026 production release; competitor details retain their source dates.

Vampauth supports HWID authentication for Roblox script licensing: one device per bound key when the project and loader allow binding. A mismatched client-supplied device ID is rejected. An authorized reset lets a legitimate user move devices without replacing the license.

Protection choices on every plan

Double-layer Full VM protection for new protected payloads and required generated stubs. Off/passthrough supports plain or externally protected code. Runtime checks are configurable. Default protected-payload allowance: 5 new builds/week on Free, 10 on Developer, 15 on Pro. Reset Monday 00:00 UTC.

Native MCP management

Connect a compatible AI client through Model Context Protocol (MCP) to manage projects, keys, loaders and providers. Connection scopes, current project permissions and resource allowances still apply; read-only actions do not activate keys.

0% revenue cut — always

Checkpoint links point to your accounts. Vampauth never takes a share. Free at core, with optional higher-limit plans.

How Lua auth checks HWID-bound script whitelists

1. Access is checked. A valid, non-FFA key can bind to the first device ID used successfully. Merely creating, viewing or copying the key does not bind it.
2. Every check verifies the device. The client supplies its device ID alongside the key. When binding is enabled, a different ID fails the device check. Advisory fingerprint signals are separate from this saved binding.
3. You control resets. Confirm ownership before clearing the binding. A binding reset does not change the license duration, restart a first-use timer or remove a ban.

Device-bound licensing controls

With HWID checks enabled, a non-FFA license key binds to one device on successful use. An authorized reset clears its device binding while preserving key expiry and usage history.
Binding happens on a successful eligible check, not by copying a key
Clear a legitimate binding through authorized management controls
Expiry, key bans and hardware bans are separate access decisions
FFA keys bypass binding; keyless delivery does not require a key
Default protected-payload allowance: 5 new builds/week on Free, 10 on Developer, 15 on Pro. Reset Monday 00:00 UTC.
0% revenue cut: checkpoint links point to your own ad accounts
Server-side access validation and protected loader sessions
Usage history, device information and ban controls
Free — binding is not a paid feature on Vampauth

HWID mismatch, expired key or ban?

A device mismatch means the supplied ID differs from the saved binding. Expiry means the key's permitted time has ended. A key ban or a hardware ban is an explicit denial. Diagnose the reported state before resetting: clearing an HWID does not fix expiry or override a ban.

Reset a legitimate HWID binding

Confirm which key the user owns before resetting its device binding. Check its current status and binding, then use the dashboard or documented management reset action with the required permissions. Test the next successful check on the new device. Do not assume a checkpoint-stacking cooldown is an HWID-reset cooldown; follow the rules of the reset surface you use.

Illustrative device change: a key is bound to Device A. Device B fails a bound check. After the developer authorizes a reset, a successful check from Device B binds the key there. The key keeps its existing expiry and usage history.

Inspect advisory fingerprint history after a device change

Fingerprint history helps support review changed execution signals without treating them as proof of a person's identity. When fingerprinting is enabled and observations are available, a key's history includes accepted and denied attempts, first/last seen times, occurrence counts, executor and reported signal changes. A missing or malformed advisory signal is not an authentication failure.

Confirm the user's key ownership and actual denial reason. Review current expiry, bans and the saved HWID before considering a reset.
In key details, compare the latest accepted observation with the relevant denied attempt: when it occurred, which loader/executor was reported, and which signals changed.
After an authorized binding reset, compare the next accepted observation. Retained history provides context; a reset does not wipe it or extend expiry.

Illustrative support case: a user changes executor and receives a device mismatch. Changed signals can be consistent with that explanation, but cannot prove ownership or account sharing. An assessment such as “changed” or “possible sharing” is advisory, not an automatic ban or a separate access gate. HWID enforcement remains the distinct binding policy. History is bounded by retention and entry limits, not a complete record of every run.

See hardware binding and fingerprints and scoped support-team permissions.

When FFA, keyless access or loader settings skip binding

FFA means the key is not device-bound; keyless means no license key is required. Binding can also be disabled in project or loader settings. Keep key checking and HWID binding enabled for device-restricted access. Session leases and device bans are independent controls, not substitutes for a correctly configured binding policy.

Related comparisons

Vampauth vs Panda Auth — binding and licensing workflows
Vampauth vs Luarmor — device checks and reset controls
What is a Roblox key system?
Free script licensing allowances
Payload protection and runtime checks
Compare licensing plans

Create a project with device-bound keys

Register free, create a project and enable one-device binding. Configure reset controls and test both a valid key and a device mismatch.

Create your first project Read binding and reset docs

Key system with HWID — FAQ

What is HWID binding in a key system?

HWID means hardware ID. With binding enabled, a successful key check associates a non-FFA license with one client-supplied device ID. Later checks compare that ID with the saved binding. A different ID is rejected unless an authorized reset clears the binding. Device binding is separate from optional fingerprint analytics and is not a guarantee against client spoofing.

How many devices can a key be bound to on Vampauth?

With HWID checks enabled, a non-FFA license key binds to one device on successful use. An authorized reset clears its device binding while preserving key expiry and usage history.

What happens when a user changes their PC?

An authorized developer can clear the key's device binding using the dashboard or supported management integration. The next successful bound check can attach the new device. A reset preserves expiry, usage history and activation; it does not renew an expired key or unban a banned key. The management reset action rejects already-unbound, banned or revoked keys.

Can HWID binding be bypassed?

Device IDs come from the client/executor, so HWID authentication is a licensing control rather than proof of a physical device's identity. Server-side checks, optional session leases and obfuscation serve different purposes. Keep management credentials off the client, test your integration and avoid treating obfuscation as a guarantee that code cannot be inspected.

Does HWID binding cost extra?

One-device HWID binding, reset controls and key lifecycle management are available on Free. Developer and Pro offer higher resource allowances; Pro also includes custom flow URLs.