Skip to content

Don't Play Russian Roulette with Indirect Access Licensing

Indirect access is where a licence bill arrives for users you never counted, because they reached the system through something else. What multiplexing looks like, how each publisher treats it differently, and how to identify it before a true-up does.

Publisher agreements from Oracle, SAP and Microsoft are complicated enough on their own. Indirect access is the clause that catches organisations who thought they had read them.

What is indirect access?

Indirect access — also called indirect usage, or multiplexing — is where your software is reached by a third party that the licence never named. That third party can be a person or a machine.

Take a common example. An organisation builds a system that lets every employee submit expenses. That system passes the expense data to a second system, an ERP or a database, using a single named service account.

Every user of the expense system is an indirect user of the second system. Under a user-based metric, they all have to be counted when the second system is licensed. Because SAP and Oracle both use Named User licence types, you are non-compliant if each of those people is not licensed — even though, as far as your access logs are concerned, only one account ever connected.

That is the whole trap. Consolidating access through one device, one web server or one service account does not consolidate the licensing. The users behind it still need licences.

Why it keeps getting worse

The definition of indirect usage differs by publisher, and in several agreements it is vague. That vagueness is not neutral — it is resolved at true-up or audit, by the party that wrote it.

The pressure is also structural rather than temporary. As applications move to SaaS and continue to draw on Oracle databases or SAP ERP systems to do their work, the number of systems reaching other systems through a service account only goes up. Integration platforms, reporting layers, customer portals and automation tools all create the same pattern. So does every AI agent that queries a licensed back end on a user’s behalf.

None of these are exotic architectures. They are the normal shape of a modern application, which is precisely why indirect access is worth identifying deliberately rather than discovering by letter.

Spotting the signs

Getting to grips with indirect access starts with classifying the users of your software correctly as direct or indirect, so that each is given the right licence type. Doing that by hand is difficult, but there are tell-tale signs that make it easier to spot:

  • An account that is active all day, every day. No human works those hours without a break.
  • A volume of work processed by one account that no person could plausibly produce within the period recorded.

Both patterns point the same way: an account that is a conduit for other people, not a person.

What the publishers actually allow

The remedies differ, and they matter more than the diagnosis.

In the Oracle world, one way to sidestep indirect access on a given system is to licence by processor rather than by Named User. The metric stops caring how many people are behind the connection, because it is counting the hardware.

SAP took longer to offer an equivalent. For years the only route was Named User, which is what made indirect access such a live dispute for SAP customers. SAP introduced its Digital Access model in 2018: instead of licensing indirect use by counting people, it licenses the documents that indirect use creates in the system. That changes the shape of the exposure — it does not remove it. You still have to know which integrations are generating documents, and at what volume, before you can tell whether the document-based model or named users is the cheaper position. Both answers depend on measurement you have to produce yourself.

Microsoft’s multiplexing rules follow the same logic in a different vocabulary: hardware or software that pools connections does not reduce the number of Client Access Licences required.

Measuring it properly

Avoiding an indirect access problem comes down to detailed, continuous usage measurement — knowing who is really using what, through which route, and how often. Several parts of CerteroX SAM exist for exactly this.

File-based usage metering. AppsMonitor records first-used and last-used dates per application, and reports a % Used utilisation figure over a rolling 90-day window. An account with a utilisation profile no human could produce stands out against 90 days of real user behaviour.

Remote-usage tracking. Terminal Server and RDS sessions are tracked per device, so streamed and remoted usage is attributed rather than collapsed into the host. Access Control rules then handle how RDS, Citrix and VDI streamed applications are licensed, which is where multiplexing most often hides in plain sight.

Named users, de-duplicated, in SAP. A non-invasive ABAP connector reads named users de-duplicated across systems, along with roles, role groups, engines and authorisation definitions. Priority-ordered Analysis Rules then propose the licence type each user should hold, so you can compare your current position against a suggested and an optimal one — rather than accept the publisher’s count of it.

Oracle at the level the argument happens. Options and packs are reported with evidence and an override, alongside processor types and core factors, licence pools with hosting rights, and cover-down logic for Enterprise Edition. A processor-metric decision made to avoid indirect access is only safe if the processor maths underneath it is right.

Governance that acts. Governance Policies work as compliance-as-code with a reusable filter builder, so an integration pattern you have decided is unacceptable can be detected as a policy violation rather than found later in a report nobody read.

The point

Indirect access is not an obscure technicality. It is a normal architectural choice that carries a licensing consequence most organisations do not price in until someone else prices it for them.

Measure the usage, classify the users, and know which metric each system is licensed under before the true-up arrives. The alternative is finding out how your publisher defines “user” at the moment you can least afford to argue.

Book a demo, or read more about CerteroX SAM.

Related reading

Other posts covering the same ground.

  • Oracle ULA – What are the dangers and how do you avoid them?

    An Oracle Unlimited Licence Agreement is only unlimited within its clauses. What certification actually asks of you, where toxic consumption creeps in, and why the measurement work has to start at the beginning of the term rather than the last six months.

    • SAM
    • Governance
    6 min
  • Microsoft Licensing Update – August 2025

    Microsoft's August 2025 Product Terms changes: Extended Term standardised across programmes, Exchange and Skype for Business Server Subscription Editions, the Exchange and Windows 10 ESU programmes, and the Dynamics 365 F&O enforcement dates.

    • SAM
    • Governance
    4 min
  • Oracle ULA: know your options. Exit with confidence.

    Renew, rescope or exit — an Oracle ULA gives you three routes and a narrow window to choose between them. The questions to settle first, and a six-point health check to see how ready you actually are.

    • SAM
    • Governance
    6 min
From reading to evidence

Put the hardest claim here
to a technical person.

Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.

No gated download at the end of it.