Device-based licensing and access control

Third in our series on what causes problems during a software vendor audit. This one is about device-based licensing, and why controlling access at user level does not do what most people assume it does.

What device-based licensing means

Some publishers, Microsoft among them, license certain products per device rather than per user. Historically that has covered products like Project and Visio, and desktop Office under some agreement types. The rule is unforgiving: you need a licence for every device with the ability to access the application, whether or not anyone ever does.

A device here is anything — a desktop PC, a laptop, a thin client terminal, a workstation, a tablet, a virtual desktop. In a conventional environment where applications are installed on the machines that need them, this is rarely a problem. Install it on forty machines, licence forty machines, done.

It becomes a problem the moment you put a thin client layer in the middle. Citrix, Remote Desktop Services, Azure Virtual Desktop, any published-application model. If those environments are not managed deliberately, the licence position they produce is expensive and entirely avoidable.

The risk: locking down at user level does not make you compliant

Many organisations assume that restricting an application — Microsoft Project, say — to a named group via group policy or software restriction policy takes care of the licensing. It does not.

Publishing an application to a restricted user group is a user-level control. The licence is a device-level obligation. Those users can reach the published application from any device in the farm, and it is that ability to access, not the act of accessing, that triggers the requirement.

Work the arithmetic through. You have a Citrix farm delivering applications to 1,000 devices. One user needs Microsoft Project. Because that user can launch Project from any of the 1,000 devices, all 1,000 devices are licensable. You are buying a thousand licences to serve one person — who may only ever have opened it on their own machine.

That is the finding. It is not a grey area, it is not a negotiating position, and it is a straightforward calculation for an auditor to run.

Three ways out

Option 1: install the software locally and bypass the thin client layer

The obvious choice, and often the wrong one. If only a handful of users need the application, installing locally means circumventing the controls you put in place to govern software acquisition, and it leaves a patching and update gap that will still be there in two years. If you have standardised on thin client hardware you also have to buy fat clients for those users. It costs money, it undermines the platform strategy, and it creates a small permanent exception that nobody will remember to review.

Option 2: license every device

Compliant, simple, and expensive in direct proportion to the size of your farm. For most organisations this is the option you are trying to avoid rather than the one you choose.

Option 3: restrict access at device level, and keep the evidence

The requirement is to genuinely prevent the application from running on unlicensed devices, and then to be able to show that the control was in force. Contrary to a persistent myth, Microsoft does not maintain a list of “approved” tools for this. Whatever mechanism you use, what matters is that you can present the evidence of control to the publisher.

CerteroX SAM does this with Access Control rules covering RDS, Citrix and VDI streamed-application licensing. You define which devices are permitted to run a given application; attempts from anywhere else are blocked. The Blocked Files log then records exactly what was blocked, with per-user and per-device block counts — which is the evidence part, and the part organisations usually cannot produce when it is asked for. A control you cannot demonstrate is worth very little in an audit.

Two related capabilities matter here as well. Terminal Server and RDS remote usage is tracked per device, so you can see actual access patterns rather than assume them — often the fastest way to work out how small the genuinely licensable population is. And the Exclude From Licensing workflow handles the legitimate exceptions, such as MSDN, development, training and second-use devices, so they do not inflate the count you are defending.

The practical point

Per-device licensing punishes environments that were designed for flexibility. Virtual desktops and published applications exist precisely so that any user can work from any device, and that is the exact property the licence metric charges for.

You do not have to choose between the two. You do have to control access at the level the licence is measured at, and keep the log that proves you did.

To see Access Control deny a launch and the Blocked Files log record it, book a demo.