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.