Licensing built for how your software actually runs
Desktop software, embedded hardware, virtualized environments, and web-delivered products each carry different licensing risks and constraints. Find yours below.
Talk to us about your application type"It works on our test machines." Support tickets say otherwise.
Desktop software installs on machines the publisher never sees — different builds, inconsistent networks, IT policies that block calls a licensing check assumes will work. An activation flow that looks solid in a demo can generate a steady trickle of "I can't activate my license" tickets once it reaches real customers.
Desktop licensing needs to activate reliably at install time and every time after, regardless of the customer's environment — built on machine-locking and delivery methods suited to local installs.
- Why it matters: Reliable activation across varied customer machines, with no forced cloud dependency.
- Who it's for: Publishers distributing traditional installed applications — engineering, design, or line-of-business software.
The device ships. You won't touch it again.
Once embedded software ships inside a physical device, there's usually no network relationship with it — no server call, no remote patch, often no full OS. Whatever licensing logic is on the device at ship time is effectively what's there for the life of the deployment.
Hardware-based delivery works without connectivity the device may never have, with protection matched to physical access risk and time-based licensing that doesn't need a network clock.
- Why it matters: Works with zero connectivity, and time-bound terms hold up even fully offline via RTC dongles.
- Who it's for: Publishers building software for dedicated hardware, industrial equipment, or embedded devices.
One license. Then it's running on five VMs by Friday.
Virtual machines can be cloned, snapshotted, and spun up or down in seconds — a licensing check built around a unique physical machine doesn't hold up when the "machine" itself is disposable and infinitely copyable. A license tied to a hardware fingerprint can invalidate itself every time IT re-provisions a VM, or worse, get cloned right along with the image, silently multiplying seats no one intended to grant.
Entitlement tied to something more durable than a single hardware fingerprint, with tracking that recognizes provisioning and cloning patterns instead of treating every VM refresh as a new machine.
- Why it matters: License counts stay accurate even as VMs are cloned or refreshed, so entitlement doesn't silently drift.
- Who it's for: Publishers whose software is deployed inside virtualized or auto-scaling infrastructure.
The product lives in a browser. What does "licensing" even mean here?
For installed software, licensing enforcement happens inside code the customer's machine runs. For a web-delivered product, there's no local binary to protect and no install to gate — access itself is the product. Publishers moving from a desktop model to a web-delivered one often find their existing licensing logic doesn't map onto session-based, account-based access at all.
Entitlement and access management applied at the account and session level rather than the binary level, working through the same APIs used for desktop-style enforcement.
- Why it matters: Account-level entitlement stays consistent whether access happens through a browser, an API, or a hybrid local component.
- Who it's for: Publishers offering web-delivered or hybrid products where "license" means account access, not an installed binary.
Not sure which application type describes yours?
Tell us how your software runs — we'll take it from there.
Start Conversation