Licensing in virtualized environments

Client applications running on virtualized environments, such as virtual machines (VMs) and containers, cannot rely on hardware-bound licensing models. When licensing your client applications, consider how virtual environments affect your ability to track and control license consumption.

Challenges in licensing in virtualized environments

Protecting software in virtualized environments introduces challenges for traditional, hardware-bound licensing models:

Virtual machines are frequently reset, re-imaged, or assigned random hardware IDs on reboot, which can cause conventional node-locking or concurrent session tracking to leak seats.
A VM can be easily cloned, letting a user copy an active machine state so that multiple concurrent instances access your software from a single seat.
Some virtualized environments are completely isolated or air-gapped from the Internet. When an application cannot report state changes back to a live licensing server, preventing unauthorized duplication of local license files becomes especially difficult.

10Duke Enterprise licensing solutions for virtual machines

To minimize the risk of license misuse, 10Duke Enterprise provides deployment options tailored for both online and air-gapped virtual environments.

Count-based metered licensing

The most direct and secure option for virtualized environments is a count-based metered licensing model, where consumption is tracked by the count the client application reports.

When applications run across multiple cloned machines presenting identical hardware IDs, they all draw from the same limited pool of use counts. 10Duke Enterprise enforces the total quantity independent of the node or machine count, and no overage is allowed unless you explicitly configure it in your license model.

To protect use count-based pools from exploitation across cloned instances, configure short lease times (leaseTimeCache) in your count-based metered license models.

Seat-based licensing in online environments

If your business model requires seat-based licensing for Internet-connected VMs, tracking static hardware IDs alone is not secure. See how to select and maintain stable hardware IDs on a host device.

To resolve the security risks of identical hardware IDs, 10Duke Enterprise provides an enforcement mechanism called lease chaining.

By enforcing lease chaining in the ConcurrentSessions constraint rule in the license model, you shift trust from a static hardware ID to a cryptographic state machine managed between the client application and 10Duke Enterprise.

With lease chaining enforced, any request to extend or renew an active session must prove it holds the unique token ID (the jti claim in the license token) generated by the immediate previous request.

If an active VM is cloned, the clone may copy the active license token. When the clone triggers a renewal, 10Duke Enterprise accepts the current token ID (the jti claim value), completes the renewal, and returns an entirely new jti. The original VM’s next renewal then fails, because its stored token ID is now outdated, forcing it to start a brand-new lease and consume an additional seat from the pool, blocking free duplication.

We recommend that you configure short lease validity (leaseTimeCache) in your seat-based license model so that a copied, active token cannot be used for long without triggering the renewal check.

Virtual machines in air-gapped environments

For client applications running in virtualized environments that are completely offline and isolated from the Internet, a live connection to 10Duke Enterprise is not possible. In this case, you can use offline license tokens: download them from 10Duke Enterprise and deliver them to the VM through secure manual transport.

Because an air-gapped application cannot report state back to the server, there is an inherent risk that a distributed token is copied to cloned VMs, letting multiple instances run against a single seat. This risk is difficult to eliminate entirely in isolated environments. To limit the exposure, issue offline license tokens with a short validity period, so that any copied token expires quickly and each VM must obtain its own.

Containerized and Kubernetes deployments

Containers and Kubernetes pods share the cloning and hardware-ID instability of virtual machines, and add rapid autoscaling. Replicas are created and destroyed continuously, often with ephemeral or identical hardware IDs, and frequently terminate without a chance to release their lease cleanly. Two approaches keep seat counts accurate under this churn.

Where possible, prefer a count-based metered licensing model. As with cloned VMs, replicas presenting identical hardware IDs all draw from the same use count pool, and 10Duke Enterprise enforces the total independent of the pod count. This ensures that horizontal scaling cannot inflate consumption and licensing does not depend on stable per-pod identity.

If you need seat-based concurrency, combine short lease validity with explicit release. Configure a short lease validity (leaseTimeCache) so that a seat held by a terminated pod unlocks automatically soon after. In addition, have your application release its lease on shutdown, for example, from a SIGTERM handler during pod termination (the preferred way to end a process because it allows the program to shut down gracefully, saving data and releasing resources properly), so the seat frees immediately for a rescheduled replica. Where per-pod hardware IDs are unstable or shared, enforce lease chaining (leaseTrackingMode set to REQUIRE_LEASE_ID) so that a copied token forces one holder onto a new lease rather than letting two replicas share a seat silently.

For multiple worker processes within a single pod, add LicensedProcess to your sessionAnchors alongside the primary anchor, so each process is counted individually instead of the first one locking the whole pod.

License consumption workflow in virtualized environments

In your client application logic, implement the license consumption and renewal cycle as follows:

Initial consumption (the first request)

Make a standard authorization call to the 10Duke License Consumption API. Parse the returned license token, extract the jti claim, and store it as the active leaseId.
Lease renewal (enforcing the chain)

Before the current token expires, make another consumption call to renew the seat, including the leaseId query parameter set to your stored jti. A new token with a new jti is returned; immediately update your stored leaseId with this value for the next cycle.
Session clean-up

When the user closes the application or ends the session, send an explicit release request to the 10Duke License Consumption API using the active leaseId to instantly free the seat for other virtual sessions.

Configure the license model in 10Duke SysAdmin

To configure a license model that enforces lease chaining for online virtual environments using 10Duke SysAdmin:

Create a custom license model.

Follow the standard steps to create a license model.
Set the limits for how many concurrent sessions are permitted per user or device, enforce lease chaining, and define what counts as a license session in the ConcurrentSessions constraint rule.

Best practices

We recommend that you follow these best practices for virtual deployments.

Shorten lease validity

Configure a short lease validity (leaseTimeCache) in your license model. If a virtual container or VDI instance crashes without sending a clean release request, the seat unlocks automatically as soon as the brief lease expires.

Combine with process anchors

If multiple users share a single terminal server setup (such as Remote Desktop Services), a hardware session anchor alone locks out the entire machine after the first user logs in. To prevent this, add LicensedProcess to your sessionAnchors alongside Hardware. This tracks concurrency on a per-process level instead of locking the host machine.