Client device metrics and how they are counted.
Client device metrics look like a simple headcount and rarely are. The definition of what counts as a device, and which devices fall in scope, is where audits inflate the number and where a precise reading of the entitlement reverses it.
Several IBM products are licensed by a client device measure, where the entitlement is tied to the number of devices that interact with the software rather than to processor capacity. The metric feels intuitive, which is exactly why it is dangerous. A loose internal assumption about what a device is can differ sharply from the License Information definition, and an audit will count to the definition, not to the assumption.
What counts as a client device
The License Information document defines the device for each product, and the definitions are not uniform. A client device may be any device that runs or accesses the software directly or indirectly, which can sweep in more than the obvious endpoints. Indirect access is the recurring trap: a device that never touches the IBM software directly but receives data from it through an intermediary can still count, depending on how the entitlement is written.
Direct and indirect access
The distinction between direct and indirect use is where counts diverge. If a product is licensed per managed or accessing device and the rule includes indirect access, then a reporting layer, a middleware tier, or a downstream application that passes the software's output to many endpoints can pull all of those endpoints into scope. Teams that count only the directly connected devices, and auditors who count every downstream consumer, can arrive at numbers that differ by an order of magnitude.
- Read the device definition in the License Information document per product
- Determine whether indirect access counts toward the device total
- Separate managed devices from merely present or networked devices
- Exclude devices the entitlement does not bring into scope
Managed versus present
Another frequent over count comes from confusing devices that are managed by the product with devices that merely exist on the network. A systems management product licensed per managed endpoint counts the endpoints it actually manages, not every device discovered in a scan. Pulling a raw discovery total into the count, rather than the managed population the metric defines, inflates the requirement and the finding that follows from it.
Counting to the definition
The defensible count starts from the entitlement definition and works outward: identify exactly what the metric counts, establish the population that meets that definition, and document the exclusions. Done in advance, this produces a number you can stand behind. Done only in response to an audit, you are negotiating against IBM's reading of the same words, usually from a weaker evidentiary position.
Client device counts are won or lost on the definition. The License Information document decides whether indirect access counts and whether the metric means managed devices or every device present, so an audit that inflates the number is challenged by counting precisely to the entitlement rather than to a loose internal assumption.
Unsure how your client devices should be counted?
Our PVU Reconciliation engagement reads the device definition for each entitlement, builds the count to the rule, and challenges findings that sweep indirect or unmanaged devices into scope.
See PVU Reconciliation →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.