Zentitle Virtualized Environments
VMs, docker containers, OSes with virtualized environments underneath, all catered for
How does Zentitle handle virtualized environments?
Virtualized environments — full VMs, Docker containers, virtual desktops — are now the default rather than the exception. Zentitle detects them, distinguishes between legitimate instances and clones, and ensures every seat is properly paid for.
Why cloning is a licensing risk
Cloning a running VM is trivial. Without protection, one activated seat can be copied into dozens of identical instances, and the vendor has no way to know. Zentitle’s nonce-based mechanism stops that without adding friction for legitimate users.
How the nonce mechanism works
Every license refresh rotates a short-lived secret (the "nonce") that only the originating instance knows.
- Each license refresh returns a fresh nonce from the cloud
- The instance must present the current nonce on every subsequent refresh
- If an instance is cloned, only one copy keeps the latest nonce; the other is detected and denied
- Vendors define the policy for what happens when a clone is caught (deny, re-checkout, alert)
Who this video is for?
Security architects and licensing leads who need confidence that virtualized deployments can’t quietly inflate usage.
Video transcript
Auto-generated from the video and lightly edited for readability.
Wasn't that many years ago where virtualized environment we're still relatively uncommon.
Spring forward to today, and really virtualized environments are everywhere, whether it's full VMs, docker containers, or even individual desktops now. A lot of desktops running Windows eleven, for example, present themselves as being virtual And under the covers, they are, in fact, a virtualized environment. So we wanted to build in really great support for a virtualized image detection and decloning, and to ensure that you get properly paid for every single seat of the license that you sell to your customers. The way we do that is with a technique we call the nonce. So think of the knot as being kind of a transient secret. So every time there's a communication between the application back to the Zentitle Cloud, as part of the license refresh.
We will generate a brand new notch that comes back from the server that is then registered to that individual in So if that instance stores that nonce and then makes a subsequent request, they have to provide that nonce again that nonce comes in as part of that request. We'll see that they actually did provide the right nonce. So we'll make that a validated authenticated use of that seat of the license.
And we will then generate a brand new right, which will then go back to the client. And so that will continue through that conversation.
Now, if The process gets activated so they get their nonce, then they clone themselves. So both process one and process two will then have the same secret.
The first of these that then do that refresh request will have that be validated by the Zentitle Cloud, and then that will generate a brand new nonce back to whichever process made that request.
But now one of those two processes will no longer know the current nonce that was just refreshed. And so when they do a refresh, They won't have the correct nonce, and the request will be denied. Now when the request is denied at that process, they realize, Hey, we don't have a seat because we lost it a clone, etc.
Then the application can decide, Hey, I wanna try checking out another seat against the license So that's up to you as the vendor to define what kind of policy you want to enforce when we've detected that a clone has already grabbed that seat. Away from that process.
Decouple your
monetization today
Join the enterprises scaling their revenue without rebuilding their stack every year.
Unleash the monetization potential of your software / SaaS / Hardware