Node-locked license
A node-locked license binds entitlement to one machine via a stable hardware fingerprint. Copying the license file to another PC fails validation. Choose Auto-bind (instant lock on first validation) or Product owner approval (review in the Device Binding tab before the end user can run the app).
One machine
Hardware ID stored on server and in license.bin.
Binding modes
Auto-bind or product-owner approval at create time.
Device tab
Binding status, approve/reject, transfer, history.
Node-locked license — for product owners
Bind entitlement to one machine and one Issued to user. Choose Auto-bind or Product owner approval when issuing.
- Issue with required Issued to (must be a product member, not the owner account).
- Review pending bindings on the Device Binding tab — Approve or Reject.
- Transfer hardware via Device Binding when users replace laptops.
- Block rogue devices from Activations without revoking the license.
- Watch Unauthorized Access Attempts on Device Binding — you are notified when another machine tries a license that is already bound.
Dashboard walkthrough with screenshots continues below.
Node-locked license — for end users
Your license works on one computer only. The app sends a hardware fingerprint and your assigned email (Issued to) during validation — both must match.
- Auto-bind — first successful validation locks that PC immediately.
- Approval mode — first run shows pending until your vendor approves the device.
- Copying the license file to another PC returns hardware mismatch.
- Wrong login/email returns credential mismatch.
Need a new machine? Ask your vendor for a device transfer — do not share the license file.
Create a node-locked license (dashboard)
Open Licenses → Generate License. The wizard has four steps: Activation, License Type, Basic Info, and Details.
Step 1 — Activation mode
- Offline — typical for node-locked desktop apps. Distribute
license.bin; the SDK validates locally after an optional online bootstrap. - Online — live API validation on each run; activations and sessions appear in the dashboard in real time.
Step 2 — License type
Select Node-Locked. The card explains that hardware is captured on first run and the license is bound to that device.
Step 3 — Basic info
- Product (required) — e.g. IntelliJ IDEA.
- Software release (required) — version line the license is tied to (e.g. 1.0.2).
- Issued to (required) — end user assigned to that release. The SDK sends this as
IssuedToduring validation; it must match the license record. - License name (required) — internal label shown in lists and exports.
Step 4 — Details (device binding mode)
On the Details step, choose how the first device is locked:
- Auto-bind — first validation locks that machine immediately. No dashboard action required. Best for trusted or single-user deployments.
- Product owner approval — first validation submits a binding request. The product owner must click Approve Device in License details → Device Binding before the license works on that machine.
Also set optional Entitlement sets and Notes, then click Generate License.
After creation — licenses list
Node-locked rows show Type: NodeLocked, Mode: Online or Offline,
Status: Valid, and Activations (e.g. 1 / 1 when one device is bound).
Machine workflow (SDK / WinForms test app)
- Download
license.binand copy the license key from license details. - Configure the SDK: product public key, API key, and
ServerBaseEndpointinlicenpro.settings.json. - Load the license file and key in your app, then Validate License (online).
- The SDK sends a stable hardware fingerprint, IssuedTo, and device metadata to
POST /api/Licenses/validate. - On success, the SDK may start an online session (heartbeat while the app runs).
Auto-bind — first validation on machine
VALID on the client. Dashboard → Device Binding shows Bound with hardware ID, device name, and OS. Activations tab shows one active device.
Product owner approval — first validation on machine
INVALID on the client with a pending-binding message. Dashboard shows a yellow banner and Pending Approval on Device Binding. The end user must wait until the owner clicks Approve Device, then validate again.
Second machine (same license file)
Validation fails with a hardware mismatch message — the license is already bound to the first fingerprint.
License sharing detection
Blocking the second machine is only half the story: as the product owner you also want to know it happened. Whenever a bound node-locked license is presented from a different machine, LicenPro records the attempt and sends you an in-app notification. The end user's experience does not change — they still see the same hardware mismatch message, and nothing is revoked automatically.
- What triggers it — a license whose binding status is Bound is used from a fingerprint other than the bound one, during validation, activation, or session connect.
- What you see — the attempting hardware ID, the machine it should be bound to, device name, IP address, which entry point was used, how many times that machine has tried, and when.
- Who sees it — product owners only. End users and other product members cannot read these records.
- How often you are alerted — once per offending machine per day. A client stuck retrying in a loop will not flood your notifications; the attempt counter keeps rising in the background.
- Review — mark an attempt as reviewed once you have looked into it. The warning banner clears, but the record and its counter stay.
A new machine on a bound license looks the same whether the user shared their license or simply replaced their laptop or reinstalled Windows. Contact the user before acting. The usual fix for a genuine hardware change is device transfer or unbind, not revocation.
An offline license still checks in with the server the first time it runs on a machine, so a copied license usually shows up as an attempt on that first launch. After that it validates locally and stops reporting in — and nothing is recorded at all if the other machine was offline during its first launch. Use online validation if you need continuous visibility.
A wrong Issued to value is a different failure: it is rejected earlier as a credential mismatch and is not counted as a sharing attempt. Sharing detection covers the case where the credentials are correct but the machine is not.
License details — Overview tab
Use Overview for license metadata and binding summary:
- License type — NodeLocked
- Validation mode — Online or Offline
- Binding mode — Auto-bind or Product owner approval
- Binding status — Not bound, Pending confirmation, Bound to device, or Rejected
- Hardware ID — full fingerprint hash (copy button)
- Usage statistics — active devices vs allowed (typically 1 / 1)
- Online activity — links to Activations and Active Sessions counts
Device Binding tab
Primary operator view for node-locked hardware:
- Bound device — hardware ID, device name, OS, activated time, last seen
- Pending state — requested hardware ID with Approve Device / Reject (product owner only)
- Activation history — table of Activated / Deactivated / Transferred events with IP and timestamp
- Unbind / transfer — reset binding for legitimate hardware moves (owner actions)
- Unauthorized Access Attempts — machines that were denied because the license is bound elsewhere, with attempted and bound hardware IDs, IP, entry point, attempt count and timestamps. A badge on the tab and a banner on the license show how many you have not reviewed yet; Mark as reviewed clears them (owner only).
Activations tab (per license)
Shows the device record created when the license validated or activated. For node-locked online licenses there is typically one activation per license.
| Column | Meaning |
|---|---|
| Device | Hostname (e.g. DESKTOP-…) and hardware fingerprint prefix |
| User | Windows / SDK user name reported at activation |
| IP | Public IP at activation time |
| Activated | Relative time since first bind |
| Status | Active, inactive, or blocked |
| Actions | Block, deactivate, or manage device (owner) |
Active Sessions tab (online node-locked)
When validation mode is Online, the SDK opens a live session and sends heartbeats while the app runs. This tab lists current connections for this license only.
| Column | Meaning |
|---|---|
| User | Session user name and app version (e.g. v1.0.0) |
| Device | Hostname and operating system string |
| IP Address | Masked public IP of the client |
| Connected | When the session started (relative time) |
| Heartbeat | Last SDK ping — proves the app is still running |
| Actions | View session details or disconnect remotely |
Use Live auto-refresh and filters (All / Online / Offline) to monitor usage.
Global Activations & Sessions pages
Sidebar Activations and Sessions show records across all products and licenses — useful for support desks. See Sessions & Activations for column definitions and lifecycle.
Server messages (end user)
When validation or binding fails, the API returns clear messages (also shown in the SDK test app status detail):
- Binding submitted / pending — approval mode; wait for owner action
- Binding rejected — owner rejected; contact support or reset binding
- Hardware mismatch — wrong machine
- Credential mismatch — Issued To does not match validation params
- Device blocked — operator blocked this device from Activations
Compare with other models
- vs Perpetual — node-locked is one machine; perpetual may allow many activations (∞).
- vs Concurrent — node-locked is exclusive binding; concurrent is N simultaneous devices.
- vs Floating — node-locked is fixed hardware; floating is a shared seat pool.