Oracle's audit teams count every supplier login, partner collaborator, and B2B connector as a full named user unless you push back. This is how the license definitions actually work, and where you cut the external-user count down to what your deployment really requires.
Oracle's audit teams count every supplier login, partner collaborator, and B2B connector as a full named user unless you push back. This is how the license definitions actually work, and where you cut the external-user count down to what your deployment really requires.
Oracle wants you to license every person and device that touches Agile PLM, and its opening audit position treats a supplier who checks an RFQ twice a year the same as a full-time engineer. That is the trap. In roughly 60 to 80 Oracle audits we defended across 2024 and 2025, the single largest inflator on Agile PLM external-user counts was Oracle collapsing three distinct license types into one full-price named user. The defense is not a clever argument. It is Oracle's own documentation, read against your actual access grants.
If you are new to how Oracle prices this product, start with the Agile PLM licensing buyer guide and the breakdown of named user versus concurrent metrics. This page focuses narrowly on suppliers, external collaborators, and integrations, because that is where the count is most negotiable and where Oracle's LMS team most often overreaches.
Oracle's opening audit number treats a supplier who checks an RFQ twice a year the same as a full-time engineer. That is the trap, not the rule.
Oracle's own Agile PLM administrator documentation (chapter 35, "Licenses") defines three distinct user-license types: Named (formerly "Power"), Concurrent, and Restricted. That distinction is the most important lever you have. Third-party compliance advisories, and often Oracle's own audit worksheets, describe a flat Named User Plus (NUP) model where every external collaborator requires a full license "regardless of their frequency of access." That framing is convenient for Oracle. It is not the whole rule.
The critical definition for your supplier population: Oracle documents Restricted users as "people outside your company (such as distributors and suppliers) who are given limited access to the Agile PLM system." That is the tier your external users usually belong in. It carries capability limits, which is exactly what makes it defensible and cheaper. Chapter 7 of the documentation is explicit: "Both Restricted and Power users can respond to RFQs, but only Power users can generate and view reports." If your suppliers respond to RFQs and view assigned items but do not run reports, they are Restricted users by Oracle's own text.
| License Type | Who It Covers | Concurrency Applies | Typical Fit |
|---|---|---|---|
| Named (Power) | Internal power users, engineers, analysts | No (always able to log in) | Full-time internal staff who run reports and administer records |
| Concurrent | Shared internal pool subject to simultaneous-login limits | Yes (can be locked out at the cap) | Occasional internal users where peak concurrency is well below headcount |
| Restricted | Distributors and suppliers with limited access | N/A (limited role) | External collaborators who respond to RFQs and view assigned items, not report |
The functional line matters for cost. Named users "are not applied against concurrency counts," so a named user can log in at any time. Everyone who is not Named or Restricted is "subject to concurrency counts, and may be locked out due to a concurrency limit." Read those definitions together and you have a three-way sort, not a single flat NUP tally. Get your supplier population into Restricted, and your occasional internal population into Concurrent, before Oracle counts anyone as a Named user.
Here is the example that circulates in vendor and compliance content: a business with 200 employees and 50 suppliers "will need 250 NUP licenses, regardless of how often each individual uses the software." That number ignores the Restricted-user category entirely, and it ignores the option to put occasional internal users on Concurrent. It is the difference between an opening audit claim and a defensible position, and buyers who accept the framing pay for it.
Do the math on the same population using the license types Oracle actually publishes. If the 50 suppliers are RFQ responders (Restricted), and 60 of the 200 internal users are occasional and fit a Concurrent pool sized to peak simultaneous logins, your Named count drops from 250 toward 140 Named plus a modest Concurrent block plus a Restricted block. The exact split depends on your role assignments and your telemetry, but the direction is not in dispute: the flat 250 is Oracle's ceiling, not your requirement.
The flat named-user tally is Oracle's ceiling, not your requirement. Restricted and Concurrent are in Oracle's own documentation for a reason.
Frequency of use is not, on its own, a defense. Oracle's rule is explicit: "even infrequent users require a license," and "licenses must be maintained for all individuals as long as they have system access." So the win is not arguing that a supplier logs in rarely. The win is placing that supplier in the correct, cheaper license type and, where the account is dormant, deprovisioning the access grant entirely so there is nothing to count. Access removed is a license not owed. Access left open is a license Oracle will count.
Named User Plus audit disputes concentrate on indirect access, and Oracle interprets it broadly. Oracle's working definition of "User" reaches "any person, application, or device that in any way interacts (or could interact) with the Oracle software," counted at a "multiplexing front end" such as an application server if one exists. The NUP metric explicitly covers "non-human operated devices" as well as people. That is the hook Oracle uses to argue your EDI feeds, supplier portal middleware, and B2B connectors each generate countable users.
There are two exposures buried here, and you must separate them. The first is the Agile PLM application layer, where a supplier portal that fronts the application can, in Oracle's reading, require you to count the humans behind it. The second is the embedded Oracle Database beneath Agile PLM, where indirect access disputes are "typically more complex and more expensive," and where Oracle's LMS team tries to establish which users reach the database indirectly through connected applications. Do not let Oracle blur the two into one number. Read the restricted-use database license limits before you concede anything at the database tier, because the embedded license may already bar the general-purpose use Oracle is trying to charge you for.
On integration hubs specifically, Oracle's June 2025 License Definitions and Rules document contains "Interface" language: a service connecting to multiple external products "either directly or indirectly (e.g., through an approved integration hub)" may require a separate Interface license per connection. That language is a double-edged sword. It gives Oracle a claim, and it gives you a boundary: an Interface license is priced and scoped per connection, not per human being behind the connection. Force Oracle to pick a theory. It cannot charge you a per-connection Interface fee and a full NUP for every supplier user behind that same connection without double counting.
When the external-user population is large, fluid, or genuinely uncountable (think a broad supplier network or a public-facing collaboration portal), the Processor metric removes the counting problem. Under Processor, "there is no limit to the number of users, regardless of whether they access the program directly or via a front-end application." You license the hardware, not the humans, and the indirect-access argument evaporates because there is nothing left to count.
Price it before you negotiate. The comparison hinges on the NUP minimum. Oracle Database Enterprise Edition, which frequently sits under Agile PLM, requires at least 25 Named User Plus licenses per processor. The effective count is max(actual users, 25 × processor count). If your database runs on a modest core count but you are trying to license hundreds or thousands of supplier users, the per-processor minimum may make Processor licensing cheaper and cleaner than any NUP tally. Model both. Then present the cheaper one as your position.
| Scenario | Better Metric | Why |
|---|---|---|
| 50 suppliers, RFQ responders only | NUP (Restricted tier) | Small, countable, low-capability; Restricted is far cheaper than Named |
| Hundreds of fluid supplier users behind a portal | Processor | Unlimited users, removes indirect-access counting entirely |
| Small database, large uncountable external population | Processor | NUP minimum (25 per processor) undercuts a large user tally |
| Stable internal-only deployment | NUP (Named + Concurrent) | Countable, no per-processor minimum penalty |
Oracle does not publish standard Agile PLM pricing, which forces every buyer into quote-based negotiation. Third-party benchmarks put per-user list around $75 to $150 per user per month for 1 to 100 users, with enterprise pricing above 1,000 users described as negotiable. Cloud subscriptions have been quoted from roughly $13,800 per year at the entry point, with on-premise licenses reaching six figures. Treat every one of these as an opening bid, not a rate card. The volume discount curve is steep and the external-user tier assignment moves the number more than the unit price does.
The practical takeaway: negotiating the unit price saves you a percentage; negotiating the count and the tier saves you a multiple. A supplier reclassified from Named to Restricted, or a portal population shifted to Processor, changes the order of magnitude. Watch also for module sprawl in audit findings, because add-on modules assigned to external users compound the per-user overcount.
Oracle removed version 9.3.7 from its roadmap in October 2023, making 9.3.6 the final release, with Premier Support ending December 31, 2027. After that date Oracle stops shipping security patches, bug fixes, and technical support, leaving 9.3.6 on Sustaining Support only. This deadline is leverage for both sides, and you should know which way it cuts before Oracle raises it.
Oracle will use the deadline to push you toward Fusion Cloud PLM, which is built on "an entirely different architecture and data model" and typically takes 8 to 12 months to migrate. That migration rebuilds your supplier integrations from scratch, which resets the external-user counting problem entirely, sometimes in your favor, sometimes not. Two alternatives deserve pricing before you commit: the licensing changes in a Fusion Cloud PLM migration, and staying put on third-party support if the roadmap does not justify the spend. Do not let the 2027 date stampede you into a re-licensing event on Oracle's terms.
The defense sequence is mechanical once you have the evidence. First, control audit scope: keep Oracle's team to the products and environments named in your agreements, and volunteer nothing about unrelated systems. Second, produce the access data before Oracle assumes it, because whoever brings the numbers sets the frame.
The pattern here mirrors what we see on the SAP side, where the winning move is to count the right thing, not the vendor's inflated default. Buyers who defended indirect usage claims with document-flow evidence cut opening numbers by 80 percent and more. The Oracle Agile PLM version of that discipline is license-type classification plus access-grant hygiene plus a Processor-versus-NUP model. Bring the data, hold the definitions, and the external-user count comes down to what your deployment actually requires.
Usually not. Oracle's own documentation defines a Restricted user tier for "people outside your company (such as distributors and suppliers) who are given limited access." Suppliers who respond to RFQs but do not generate reports fit the Restricted tier, which is cheaper than a full Named (Power) license. Oracle's audit opening often ignores this category, so you must assert it.
No, not by itself. Oracle's rule is that a license is required regardless of usage frequency and must be maintained as long as an individual has system access. The real reduction comes from placing users in the correct, cheaper license type and from deprovisioning dormant external accounts entirely so there is nothing to count.
Oracle defines a "User" as any person, application, or device that interacts or could interact with the software, and the NUP metric explicitly covers non-human devices. It counts at the multiplexing front end. Oracle may also cite Interface licensing for connections through an integration hub. Force Oracle to pick one theory, per-connection Interface or per-user NUP, and reject double counting of the humans behind a licensed connection.
When the external population is large, fluid, or uncountable. Processor licensing places no limit on user count and removes the indirect-access counting problem. Model it against the NUP tally, including the 25-per-processor minimum on Oracle Database Enterprise Edition, because that minimum can make Processor cheaper even with a small user base.
Premier Support for the final release, 9.3.6, ends December 31, 2027, after which only Sustaining Support remains. Oracle will use the deadline to push a Fusion Cloud PLM migration, which rebuilds supplier integrations and resets the counting problem. Price third-party support and the Fusion migration before committing, and do not let the deadline force a re-licensing event on Oracle's terms.
An export of every external account with its role and privilege grant, mapped to Named, Concurrent, or Restricted using Oracle's chapter 35 and chapter 7 definitions, plus proof that dormant accounts were deprovisioned before the measurement date. Whoever brings the access data sets the frame, so produce it before Oracle assumes it.
Oracle licenses cores times a core factor, not raw cores. The 0.5 x86 factor, the worked counting, the virtualization trap, and where the factor does not apply.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
