Most license counting assumes a person logs into the software and uses it directly. Indirect access is the harder case: value flows through an intermediary, a custom front end, an integration layer or another application, so the people and devices consuming the IBM software never appear as named users. It is one of the quietest sources of audit exposure because the usage is real but the licensing is easy to overlook.
What indirect access means.
Indirect access describes any use of IBM software that reaches the product through something other than its own interface. A reporting portal that queries a Db2 database on behalf of thousands of staff, a middleware flow that pushes transactions into an IBM engine, or an analytics layer that consumes Cognos content through an API all create demand on the underlying entitlement even though no one logs in to the IBM product itself.
Where it surfaces in an audit.
The exposure depends on how the product is licensed. Under a user based metric, the question becomes who ultimately consumes the output, not who holds the direct connection. Under a processor based metric such as PVU, the question is what capacity the intermediary drives. Common patterns include:
- Authorized user counts that capture only the integration service account, while the real population of downstream consumers goes uncounted.
- Batch and API interfaces that move large volumes of work into IBM middleware without a corresponding seat or capacity entitlement.
- Data warehouses and reporting tools front ending an IBM database for a far larger audience than the database is licensed to serve.
How to reason about it accurately.
IBM's treatment of indirect use is governed by the specific product terms and the metric on each entitlement, not by a single universal rule, so the defensible approach is to read the actual license metric and map the real flow of consumption against it. The principle that holds across products is straightforward: routing usage through an intermediary does not remove the underlying entitlement demand. If a thousand people read Db2 data through a portal, the database is serving a thousand people regardless of how the connection is made.
Document every integration that touches IBM software and trace it to the population it actually serves. The buyer side position is to model indirect consumption against the precise metric on your entitlement before IBM does, so that any claim about downstream users is met with your own mapping rather than IBM's assumption. Vague architecture diagrams favor the auditor; a clear consumption map favors you.
Containing the exposure.
The practical defense is visibility into your own integration landscape: a current map of which applications, services and interfaces reach each IBM product, the metric that governs each one, and the real consumer population behind every connection. With that in hand, indirect access stops being a hidden liability and becomes one more line you can reconcile and, where IBM overreaches, challenge.