Hardware IDs
A license is bound to the device that activated it, through a hardware fingerprint built from several hardware characteristics of that device. Knowing roughly how this works tells you what to expect when a customer's hardware changes, and what to tell them when a license stops matching.
What can change without breaking a license
Routine hardware changes, such as replacing a component, do not invalidate a license:
the fingerprint still matches.
Moving to a different machine, however, makes the device count as a new one: the
fingerprint no longer matches, and validation returns BAD_CONTEXT. The remedy is to
deactivate the old identity and activate again
on the new one. Until it is deactivated, the old seat stays held, so make
deactivation easy for your customers to find in your product.
Whether reinstalling the operating system makes a new device depends on the platform. On Windows, the reinstalled machine is still the same device. On Linux, a reinstalled operating system counts as a new device, like a different machine. Inside WSL2, with SDK 1.3.0 and later, reinstalling or re-importing the distribution makes a new device, while restarting WSL or Windows does not.
Deactivating and activating again
A deactivation releases the device's seat, but the service keeps the machine's identity. The same holds for a force-release from the console, and for deleting another license the machine held. When the machine activates again, it gets back its own previous activation, with the same per-device period and the same activation tally. For every license, that means:
- A trial cannot be restarted by deactivating and activating again (automatic trials).
- The Activations per device limit holds across deactivate and reactivate cycles: each return after a deactivation counts as one activation, and renewals never count (license terms).
- Deactivating or deleting one license leaves the same machine's activations of your other licenses untouched.
Fingerprints too weak to recognise
A device that cannot be identified reliably enough to recognise it again is refused at
activation, for every license: the service answers HTTP 403 device_unidentifiable, and
the SDK reports NOT_FOUND. Both SDKs already refused to validate a license locally on
such a device. The usual case was a .NET application published with Native AOT on SDK
1.1.0, running on some Windows machines; SDK 1.2.0 and later identify those machines
reliably (publishing your app).
Privacy
No raw hardware identifiers ever leave the device. The SDK sends and stores only irreversible cryptographic hashes of each hardware characteristic, so activation cannot leak any hardware identifier. This is worth telling privacy-conscious customers directly: the service never sees, and could never recover, the underlying hardware values.
Cloud instances and virtual machines
Virtual machines and cloud instances have a device identity like any other operating system installation, so licensing works the same way. On AWS and GCP, a new instance is a new device. Cloned images, however, share the same fingerprint until they are re-provisioned, and ephemeral instances that activate and then disappear hold their seats until their licenses lapse. For elastic fleets, floating licenses with short lease periods are a better fit: seats free themselves automatically when an instance goes away.
WSL2 distributions are virtual machines too. With SDK 1.3.0 and later, each distribution is one device, reported as running in a virtual machine. A cloned distribution can keep the identity of the original, like a cloned virtual machine. A device that activated inside WSL2 with an earlier SDK is a new device after the update, and activates again.
ARM devices
ARM devices, including Windows-on-ARM and Apple silicon, are fully supported.