Indirect access risk is the exposure created when third-party systems, devices, or users touch licensed software through an intermediary, and it has produced single audit claims above $50 million, most prominently the SAP indirect-use case that ran to roughly 55 million pounds before settlement. The danger is that the access is real, the contract usually permits the vendor to charge for it, and almost no buyer has counted it, so it surfaces for the first time inside an audit when the bargaining position is at its worst.
What indirect access is
Indirect access, sometimes called indirect use or multiplexing, occurs when a person or a system uses licensed software without connecting to it directly. A customer-facing web portal that reads from an SAP backend, a reporting tool that queries an Oracle database through a middle tier, a logistics platform that pushes orders into an ERP through an integration, all of these are indirect access. The user never logs into the licensed system, but their activity flows through it, and most enterprise software contracts define the licensed population to include anyone whose use is supported by the software, not just those who log in directly. That definition is the trap: the contract counts use the buyer never thought to count.
Where it shows up by vendor
Every major vendor has a construct for indirect access, and the mechanics differ enough that a buyer has to know each one.
| Vendor | Construct | What triggers it |
|---|---|---|
| SAP | Indirect / digital access (document-based) | Third-party systems creating documents in SAP |
| Oracle | Multiplexing | Middleware pooling connections to the database |
| Microsoft | External connector / multiplexing | External users reaching a licensed server through a portal |
| IBM | Indirect use under PVU terms | Non-human and external access to licensed programs |
The common thread is that none of these requires a direct login, and all of them can be running for years before anyone counts them. The SAP case is the most instructive because SAP responded to the litigation by publishing a document-based digital-access model, which is covered in detail in our SAP indirect vs digital access guide, with the broader history in SAP indirect access.
The SAP document model and why it matters elsewhere
After the indirect-use litigation, SAP introduced a model that prices indirect access by the number of documents that third-party systems create in the SAP system, sales orders, invoices, purchase orders, and the like, rather than by counting the users behind those systems. The shift matters beyond SAP because it shows the direction of travel: vendors are moving from user-based to outcome-based metrics for indirect access, which can be cheaper or more expensive depending on the integration profile. A buyer with many low-value documents may pay more under the document model than under a user count, and the only way to know is to measure the actual document volume before agreeing to the metric. Disputes over which metric applies are common, and our license metric disputes guide covers how they are fought.
Why audits find it and you do not: Indirect access is invisible in normal operations because nothing breaks and no error appears. The integration works, the portal serves customers, the report runs, and no internal system flags that a licensing boundary is being crossed. The vendor's audit tooling, by contrast, is built to detect exactly this, the connections, the service accounts, the document creation that signals third-party use. The asymmetry is the whole problem: the vendor can see the exposure and the buyer cannot, which is why indirect access has to be mapped proactively, not discovered reactively when the audit letter arrives.
Mapping your integration surface
Controlling indirect access starts with an inventory of every system that touches the licensed software, which most organizations have never compiled. The work is to trace every integration, every middleware connection, every reporting tool, every customer or partner portal, and every service account that reaches the licensed system, then classify each as direct or indirect use under the specific contract. The output is a map of the indirect-access surface and an estimate of the exposure it creates under each vendor's metric. That map is the single most valuable artifact in an indirect-access negotiation, because it converts an unknown, open-ended risk into a measured number the buyer controls. The standing capability that produces and maintains this map is covered in our license compliance program guide.
Contract clauses that cap exposure
The strongest protection against indirect access is contractual, negotiated before the exposure is discovered. Several clauses do the work. A clear definition of authorized use that names the permitted integrations and excludes the rest removes ambiguity the vendor would otherwise resolve in its favor. A digital-access or indirect-use cap that fixes the maximum charge for third-party access bounds the exposure. A carve-out for specified system-to-system traffic that the buyer can show is operational rather than user-driven removes whole categories from the count. And a most-favored treatment clause on any future indirect-access metric change protects the buyer when the vendor revises the model mid-term. These are negotiated at the contract, not at the audit, which is why the time to address indirect access is when bargaining power is highest.
Remediation and licensing options
When indirect access is found, whether by the buyer or the vendor, the options are to license it, to re-architect to remove it, or to reclassify it. Licensing it is the path of least resistance and the most expensive; it should be the choice only after the alternatives are tested. Re-architecting, routing the third-party traffic so it no longer crosses the licensed boundary, can remove the exposure entirely but takes time and engineering. Reclassifying, demonstrating that the access does not meet the contract's definition of licensable use, is often available where the contract language is ambiguous and the buyer has the integration map to support the argument. The right path depends on the size of the exposure and the strength of the contract, and our software audit defense guide covers how the argument is made when a claim is already on the table.
Governing indirect access over time
Indirect access is not a one-time cleanup because the integration surface grows. Every new application, every new partner portal, every new analytics tool is a potential new indirect-access path, so the integration map has to be a living document maintained as the estate changes, not a snapshot taken once. Fold indirect-access review into the change-control process so a new integration is assessed for licensing impact before it goes live, not after. The discipline mirrors the broader compliance cadence: measure continuously, assess change before deployment, and keep the exposure number current so it never surprises you. That cadence is the subject of our license compliance program guide.
Costing the exposure under each metric
An indirect-access exposure is only a negotiation once it is costed, and the cost depends entirely on which metric the vendor applies. The same set of integrations can produce very different numbers under a user-based count, a document-based model, or a processor-based assertion, so the costing exercise has to model each metric the contract could support and identify which the vendor is likely to claim. A buyer who arrives at the negotiation with the exposure costed under each plausible metric controls the conversation, because the vendor cannot anchor on the most expensive interpretation unopposed. The buyer who has not done the costing accepts whichever number the vendor presents, which is always the largest one the contract arguably permits.
Indirect access in the age of AI and automation
The indirect-access surface is growing because automation and AI add new categories of non-human access. A workflow automation that reads and writes to a licensed system, an AI agent that queries an ERP to answer a question, and a robotic process that posts transactions all touch licensed software without a human logging in, and each can fall inside the contract's definition of licensable use. Vendors are alert to this, and contracts written before automation was widespread often define use broadly enough to capture it. The buyer's task is to map these automated and AI-driven access paths alongside the traditional integrations, because they are the fastest-growing source of new exposure and the one most likely to be overlooked. The contract clauses that bound this are best negotiated now, while the technology and the metrics are still being settled.
Settling an indirect-access claim
When a claim has already landed, the settlement is a negotiation, not a fixed bill, and the buyer's position rests on the integration map and the metric analysis assembled in advance. A well-prepared buyer disputes the metric, narrows the scope to access that genuinely meets the contract's definition, and trades a forward licensing commitment for relief on the back claim, which is the same pattern that governs any audit settlement. A buyer without the map accepts the vendor's count. The defense framework for a claim already in motion is covered in our software audit defense guide, and the standing capability that prevents the surprise sits in our license compliance program guide.
Reporting indirect-access risk to the business
Indirect access is a financial risk, and like any material risk it belongs in front of the people accountable for it rather than buried in the licensing function. A clear statement of the exposure, what it is, what it could cost under the vendor's likely metric, and what is being done to bound it, lets the business decide deliberately whether to license, re-architect, or accept the risk, instead of discovering the number for the first time in an audit settlement. Reporting the exposure also funds the remediation, because the integration mapping and the contract work that bound indirect access compete for resources they will not get unless the risk is visible. The organizations that handle indirect access well treat it as an ongoing risk on the register with a named owner and a periodic review, not as a one-time cleanup, and the cadence that sustains that is covered in our license compliance program guide.
Addressing indirect access at the contract stage
The cheapest time to deal with indirect access is at the original contract or the renewal, when bargaining power is highest and the exposure is still a negotiation rather than a claim. A buyer who raises indirect access proactively, naming the integrations, proposing the definitions, and negotiating the caps, sets the terms before the vendor has a finding to anchor on. A buyer who waits until an audit surfaces the issue negotiates from the weakest position, under the pressure of a claim the vendor has already quantified in its own favor. The practical move is to make indirect access a standing agenda item in every contract negotiation for the vendors most likely to assert it, SAP, Oracle, Microsoft, and IBM, and to carry the integration map into that negotiation as evidence. Treating it as something to settle in advance rather than to defend in arrears is the single largest difference between buyers who control the exposure and buyers who pay for it, and the negotiation discipline that frames it is set out in our software contract negotiation guide.
The buyer's takeaway
Indirect access is the largest licensing risk most buyers have never measured, and it surfaces at the worst possible moment if left to the vendor to find. Map the integration surface, size the exposure under each vendor's metric, negotiate definitions and caps into the contract while bargaining power is high, and test re-architecture and reclassification before agreeing to license the access. Keep the map current as the estate changes. We map indirect-access exposure and negotiate the protective clauses through our software licensing advisory and vendor audit defense practices, and the strategy that ties them together sits in our software contract negotiation guide. The exposure you have measured is a negotiation; the one you have not is a claim.