Named User Plus was built to count a known, authorized population, which is exactly what a public-facing system does not have. This page explains the contractual mechanics, how Oracle's audit scripts expose the gap, and the specific moves that shrink the exposure before it becomes a settlement.
Named User Plus was built to count a known, authorized population, which is exactly what a public-facing system does not have. This page explains the contractual mechanics, how Oracle's audit scripts expose the gap, and the specific moves that shrink the exposure before it becomes a settlement.
Named User Plus (NUP) is defined in Oracle's ordering documents as "an individual authorized by you to use the programs which are installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time." Read that clause slowly, because two words carry the entire risk: authorized and regardless. The trigger is authorization, not activity. A user who touches the database once a year counts identically to one who hammers it all day. There is no dormant-account discount, no casual-use exemption, and no seasonal adjustment.
In 25 years negotiating this metric with Oracle, I have never seen it work cleanly against a population the customer cannot enumerate. That is not an accident of drafting. NUP exists to price a finite, known set of named individuals: employees, contractors, named partners, and the non-human devices that reach the database. The moment the population becomes open-ended, the metric stops being a discount lever and becomes an audit liability. Our broader treatment of these counting mechanics sits in the pillar on Named User Plus counting rules, per-processor minimums, and audit traps, and this page drills into the specific failure mode of internet exposure.
The trigger is authorization, not activity. A user who logs in once a year counts exactly the same as one who never logs out.
The clause that ends the argument reads: "If multiplexing hardware or software (e.g., a TP monitor or a web server product) is used, this number must be measured at the multiplexing front end." This is the front-end rule, and it is the single most misunderstood sentence in Oracle licensing. Customers assume that if a web application connects to the database through one shared service account, they license one user. Oracle's contract says the opposite: you count the humans and devices behind that front end, not the connection pool in front of the database.
That is why an e-commerce site with a single application login and thousands of shoppers behind it owes licenses for those thousands, not for the one connection string. It is why a partner portal with 500 registered customer accounts owes 500 NUP even if only 50 log in per month, and it is why inactive accounts still count until they are disabled and removed. If you cannot name and count everyone the front end serves, NUP is not merely expensive, it is structurally uncompliant. The full mechanics of this are in our note on why a middle tier does not shrink your named user count.
A shared service account does not compress the population. Oracle counts the humans behind the front end, not the connection in front of the database.
The problem with internet-facing systems is not that the NUP bill is large. It is that the bill cannot be calculated. NUP requires a defensible, reconcilable list of authorized individuals. A public site has no such list. Registration may be open, accounts may be created faster than they are audited, and a marketing campaign can multiply the population overnight without any change to the underlying architecture. You cannot certify a count you do not control, and Oracle's compliance position is that everyone who could access the programs must be licensed. "Could access" plus "open registration" equals an uncountable population by design.
Oracle's own answer to this is the Processor metric. Under Processor licensing there is no user count at all: unlimited users, direct or indirect, for a fixed number of processor licenses. Every serious Oracle licensing practitioner reaches the same conclusion for external deployments, and so does Oracle: when the population is large, unknown, or unlimited, Processor is the correct metric. The decision framework is laid out in Named User Plus or Processor: the Oracle metric decision, and the crossover math is quantified in the NUP-to-Processor crossover.
Oracle prices these two metrics so that the answer is deterministic once you know your user density. On the Technology Global Price List effective April 16, 2026, Database Enterprise Edition lists at $47,500 per Processor and $950 per NUP. That is a precise 1:50 ratio. Every Database line prices NUP at one fiftieth of the Processor price. The implication is arithmetic, not judgment: the moment a processor serves more than 50 real users, Processor licensing is cheaper, and once the count is uncountable the comparison collapses entirely in Processor's favor.
| Metric / product | 2026 list price | Structure | Where it fails |
|---|---|---|---|
| Database EE, NUP | $950 per user | Count every authorized human and device | Uncountable public population |
| Database EE, Processor | $47,500 per processor | Unlimited users per processor | High capacity, low user count |
| Database SE2 | $17,500 per socket | Cores ignored, capped at 2 sockets | Not available above the socket cap |
| WebLogic Suite, Processor | $45,000 per processor | Unlimited users, 10 NUP floor | Rarely, given low floor |
| SOA Suite, Processor | $57,500 per processor | Unlimited users per processor | High-throughput integration tiers |
Support compounds every one of these numbers. Oracle charges 22 percent of net license fee annually, indefinitely, and across a five-year horizon that stream quietly exceeds the original license. A metric choice that looks cheaper on day one but is uncountable by day 400 is not a saving, it is deferred exposure with 22 percent interest attached.
Even where NUP is theoretically viable, Oracle applies a minimum count that catches customers who think they are licensing to actual users. Enterprise Edition requires a minimum of 25 NUP per Processor. Standard Edition 2 requires a minimum of 10 NUP per server. Most Fusion Middleware products, including WebLogic Server, SOA Suite, WebCenter, OBIEE, and Identity Management, apply a lower 10 NUP per Processor floor. You always license the higher of your actual user count and the minimum.
The worked example makes the trap concrete. A server with 16 cores at a 0.5 core factor requires 8 Processor licenses. The NUP floor is then 8 processors multiplied by 25, which is 200 NUP minimum. Even if only 50 people actually use the system, you must buy at least 200 NUP. For internet-facing systems the floor is almost irrelevant because the real count already dwarfs it, but it matters when a system straddles the line: an internal application with 40 users that later gains a public front end. We work through more scenarios in the 25 NUP-per-processor minimum with worked server examples.
The dangerous case is not the deliberately public site. It is the internal application that was licensed on NUP, then quietly acquired external reach: a partner portal, a customer self-service page, a mobile app, or an integration opened to a third party. Nobody re-examines the license metric when the firewall rule changes, and the exposure sits dormant until an audit surfaces it.
Oracle's audit tooling is built to find exactly this. The USMM (User and System Measurement Managed) utility and the LMS SQL scripts run against the data dictionary enumerate every active session, every connection string, and every application identifier the database can see. The scripts adhere strictly to the multiplexing rule, counting each unique database user or application connection toward the requirement unless explicitly exempted. When an application connects on behalf of thousands, the typical LMS finding lists tens of thousands of "unlicensed users" reaching Oracle through the middleware layer. Non-human callers are not spared either, as we cover in counting non-human named users: batch jobs, sensors, and automated devices.
The events that trigger these audits map directly to the moments a system goes external: large deployment changes, mergers and acquisitions, public cloud migrations, lapsed support, and Java downloads. If your architecture changed and your metric did not, you are carrying an unpriced liability that an auditor is trained to price at list.
When the finding lands, the number is deliberately alarming. Oracle prices the shortfall at list and adds backdated support fees for the period of unlicensed use. A miscount of even a few Enterprise Edition processors at $47,500 each, plus 22 percent support compounded across the unlicensed years, balloons into hundreds of thousands of dollars. Indirect-access findings against a public front end routinely open in the millions. Treat that opening number as a negotiating position, not an invoice.
The audit report is an opening bid priced at list. In defended engagements, the settlement typically lands well below the claim once the count is rebuilt.
Three levers move the number down. First, rebuild the count independently. Oracle's scripts overcount by design, treating every visible connection and every dormant account as a licensed user; a clean reconciliation removes disabled accounts, duplicate identities, and connections that resolve to a smaller real population. The method Oracle's own auditors accept is set out in our forthcoming note on building a defensible named user list. Second, reset the metric prospectively: convert the offending system to Processor licensing so the going-forward position is clean and the argument shifts to the backdated period only. Third, test the audit scope. Most Oracle agreements restrict the audit right to "use of Oracle software." Where Oracle claims fees for indirect access created purely by a third-party application, there is a colorable argument that the scope has been exceeded. It rarely ends the engagement, but it creates real settlement leverage.
The pattern here is consistent and old. Oracle introduced processor-based metrics precisely because per-user counting broke down against web-scale populations. The contract has not softened since. NUP remains the right tool for a known internal population and a permanent trap for a public one. Get the metric right at architecture time, and the audit never has anything to find.
No. Oracle's multiplexing clause requires the count to be measured at the multiplexing front end, meaning you license every human and device behind the shared connection, not the single account. A public site with open registration cannot be counted, so NUP is uncompliant by design and Processor licensing is the mandated alternative.
Yes, until they are disabled and removed. NUP is triggered by authorization, not activity, so a dormant account is a licensed account. This is why standing account hygiene matters, and why Oracle's audit scripts inflate counts by enumerating every identity the database can still see.
The USMM utility and LMS SQL scripts query the data dictionary and enumerate every active session, connection string, and application identifier. When an application serves thousands of external users through a middleware layer, the report lists them as unlicensed users. Audit triggers include cloud migrations, mergers, large deployment changes, and lapsed support, all of which coincide with systems going external.
On Database Enterprise Edition the ratio is exactly 1:50, since NUP lists at $950 and Processor at $47,500 on the 2026 price list. Above 50 real users per processor, Processor is cheaper. For an uncountable public population the comparison is moot, because there is no defensible NUP number to compute.
No. It is an opening position priced at list plus backdated support. In defended engagements the settlement typically lands well below the claim once the count is rebuilt, dormant and duplicate accounts are removed, the metric is reset to Processor prospectively, and the audit scope is tested against the "use of Oracle software" restriction in the agreement.
It applies to any Enterprise Edition NUP deployment, but for a genuinely public system the actual user count already exceeds the floor, so the floor is rarely the binding constraint. The minimum matters most for boundary cases: an internal NUP application with a small user base that later gains external reach and should have moved to Processor.
Oracle sells the same database per user and per processor. The 25 NUP per processor minimum, the 50 user break-even, and how to choose the metric that fits the workload.
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.
