Indirect access in OpenText and Micro Focus audits.

Indirect access is one of the most contentious lines in any software audit, and OpenText and Micro Focus reviews are no exception. The argument is simple to state and hard to bound: if people or systems reach a licensed product through an intermediary application rather than logging in directly, the vendor may try to count them as licensable users anyway.

The reason indirect access matters so much is leverage. A direct user is visible and finite. An indirect population is inferred, and inference can be stretched. Left unchallenged, an indirect access theory can multiply a finding far beyond the count of people who ever touched the product, which is exactly why it has to be met with facts rather than concessions.

What indirect access means

Indirect access describes any situation where a person or process consumes the capability of a licensed product without authenticating to it directly. A custom portal that reads documents from a Documentum repository, a middleware layer that submits data to an analytics engine, an integration that pushes events into a security platform, or a reporting tool that queries a licensed database all create indirect consumption. The vendor's position, broadly, is that the value of the licensed product is being enjoyed regardless of how the connection is made, and that the consuming population should therefore be licensed.

Why it inflates a finding

The danger is that indirect theories turn a bounded number into an open ended one. Consider a Documentum estate with a few hundred named users. If a customer facing portal draws content from that repository, the vendor might argue that every portal user is an indirect consumer, turning hundreds of licensed users into tens of thousands of claimed ones. The same pattern appears across the estate: an integration that touches a security or analytics product can be recast as a vast indirect population. Because the count is inferred rather than observed, the opening figure is limited only by how aggressively the theory is applied.

How indirect claims are defended

Indirect access is defended on the facts of the architecture and on the language of the agreement, not on principle. Several lines of argument do most of the work. The first is technical reality: what actually crosses the boundary, how often, and whether the intermediary aggregates, caches, or transforms data so that no per person consumption of the licensed product occurs at all. A portal that serves a cached, transformed view is not the same as thousands of people querying the repository directly. The second is the contract: many agreements and Additional License Authorizations define the licensable unit in terms that do not automatically extend to every downstream consumer, and the precise metric definition often does not support the broad theory. The third is the population itself, since indirect claims frequently sweep in the same duplicate, dormant, and service account problems that inflate direct counts. The discipline of rebuilding the real population before conceding anything is described in building an effective license position before the vendor script runs.

Where indirect access shows up across the estate

Indirect theories attach to different products in different ways. In ECM, the trigger is usually a portal or application reading from a repository, which is why named consumer definitions matter so much in our OpenText ECM and Documentum audit defense track. In security products such as ArcSight, the question is often whether connectors and feeding systems constitute indirect identities. In analytics and DevOps, integrations and automated pipelines raise the same issue. The common thread is that the metric definition, read carefully, rarely supports the broadest version of the claim, and the governing Additional License Authorizations frequently constrain it further, as covered in our Micro Focus ALA and entitlement review track.

Multiplexing and the question of where the line sits

Many indirect access disputes turn on multiplexing, the use of an intermediate layer that pools the activity of many people or systems into a smaller set of connections to the licensed product. A reporting tool that opens a handful of service connections to serve thousands of report viewers is the classic example. The vendor sees thousands of beneficiaries and argues for thousands of licenses. The buyer sees a handful of connections and a layer that aggregates demand. Where the licensable line sits between those two views is the entire dispute, and the agreement rarely answers it as cleanly as the vendor's opening position suggests.

The practical defense is to describe the architecture precisely and then read it against the metric word by word. If the intermediate layer transforms or caches data so that downstream consumers never exercise the licensed capability themselves, the case for licensing each of them weakens considerably. If the layer simply passes requests through unchanged, the analysis is harder, but even then the count must respect the metric's actual unit rather than a headcount of everyone who ever saw an output. Documenting these data flows early, before the vendor frames them, is what keeps an indirect theory from hardening into an accepted figure.

Why the metric definition is the battleground

Almost every indirect access dispute reduces to one question: what does the agreement actually license, and in what unit. If the unit is a named user authenticating to the product, an indirect consumer who never authenticates may fall outside it. If the unit is a defined measure of consumption, the question becomes how that consumption is measured at the boundary. Vendors prefer the broadest reading because it maximises the count. The defense holds them to the wording, the architecture, and the realistic flow of data. This is the same discipline that takes apart direct counts, applied to a harder to see population.

Bringing an indirect claim back to reality

Indirect access is where findings can balloon, and where careful work returns the largest reductions, because the opening figure is so often built on an assumption rather than a fact. Test the architecture, hold the vendor to the metric, and rebuild the population, and the inferred number tends to collapse toward the count of people and systems that genuinely consume the product. For the full method across every track, see the complete OpenText audit defense playbook, and the contractual framing the vendor relies on in why compliance is the sole responsibility of the licensee. If an indirect access theory is driving your finding, open a case.