Oracle Middleware Named User Plus
Named User Plus licenses Oracle middleware by counting individuals and devices authorised to use it, subject to a per processor minimum. It is cheaper than Processor only when the user population is small, countable, and stable; above the break even point, Processor wins.
What middleware Named User Plus licensing means
Oracle middleware Named User Plus, usually abbreviated NUP, licenses a product by counting the individuals and non human operated devices authorised to access it, rather than by counting the cores it runs on. It is the alternative to the Processor metric across most of Fusion Middleware, and choosing between the two is the single most consequential cost decision a buyer makes when licensing a middleware product. The wrong choice can multiply the bill several times over.
The defining constraint is the per processor minimum. NUP is never purely a headcount; Oracle requires a minimum number of named users for every processor the software runs on, so even a product with three actual users on a large server must be licensed for the full minimum. Understanding where that minimum lands is the whole game, and it sits inside the broader metric framework described in the Oracle middleware licensing pillar and the head to head comparison of the Processor and Named User Plus metrics.
Who counts as a named user
A named user is any individual authorised to use the program, whether or not they are actively using it, plus any non human operated device that accesses it. The word authorised is what trips buyers up: the count is based on who is permitted to use the software, not who logs in during a sample period. A directory of 5,000 entitled accounts is a 5,000 user count even if only 800 people use the system in a given month. Reconciling the authorised population against the entitlement is therefore the core discipline.
The per processor minimums
Oracle sets a minimum number of named users per processor for each middleware program, and the processor count is calculated the same way as the Processor metric, cores multiplied by the core factor. The general level of these Named User Plus minimums means that on a large server, the minimum can exceed the actual user count, at which point you are paying for users you do not have. The minimum is a floor, never a ceiling: if the real authorised population is higher than the minimum, you license the real number.
| Scenario | Cores after core factor | Effective NUP requirement |
|---|---|---|
| Small server, few users | Low | Often the minimum, not the headcount |
| Large server, few users | High | Minimum can exceed real users |
| Any server, large population | Any | Real authorised user count |
When Named User Plus beats Processor
NUP is cheaper than Processor only below a break even point set by the per processor minimum and the relative list prices. For a constrained internal tool with a small, stable, countable user base running on modest hardware, NUP usually wins. For a product on large hardware, or one exposed to an unbounded or external population, Processor almost always wins because the user count, or the minimum, runs away from you. The calculation has to be done per product and per server, because the same product can favour different metrics in different parts of the estate.
Which middleware products offer NUP
Most core middleware products offer both metrics, including WebLogic Server, SOA Suite, Coherence, and the identity components covered in the Oracle Identity Management licensing guide. Some products are Processor only, and some are user only, so the metric choice is constrained by what the price list offers for each program. The edition also interacts with the metric; the WebLogic editions guide sets out where the choice is available.
Do batch jobs and devices count as users?
Yes, in the cases that matter most. Oracle definition counts non human operated devices that access the program, which sweeps in automated interfaces, batch schedulers, and connected equipment in industrial settings. A middleware integration that fronts thousands of devices, sensors, or downstream systems can generate a device count far larger than the human user base. This is one of the most common reasons a NUP estimate built on employee headcount turns out to be wrong, and it is why high fan in integration workloads usually belong on the Processor metric.
The multiplexing trap
Multiplexing is the practice of funnelling many end users through a smaller number of front end accounts or a middleware tier, in the hope of reducing the user count. Oracle counts named users at the point of origin, not at the multiplexing layer, so the full population of individuals and devices behind the front end still counts. A portal that authenticates 10,000 people through a single integration service account is a 10,000 user requirement, not a one user requirement. Designing an architecture to hide users from the count does not work and is a reliable audit finding.
Keeping a Named User Plus count defensible
A defensible NUP position rests on an accurate, current register of authorised users and devices per program, reconciled against entitlements and purged of dormant and orphaned accounts. Because the metric counts the authorised population, directory hygiene is a direct cost control: every account that should have been deprovisioned but was not is a user you are paying for. The register should be refreshed on a schedule, not assembled in a panic when an audit notice arrives.
Where NUP audits find money
NUP findings cluster around four patterns: authorised user counts that exceed the entitlement because accounts were never deprovisioned, device and batch populations omitted from the count, multiplexed architectures that hid the true population, and servers where the per processor minimum was undercounted. Each is preventable with an accurate user and device register and a metric chosen deliberately per server. When an audit measures the population, contest the count with register evidence through structured Oracle audit defence rather than accepting Oracle figure.
The buyer side view
Named User Plus rewards small, stable, countable populations and punishes large or unbounded ones, so the metric must be chosen per product and per server against the per processor minimum, not adopted estate wide. Maintain a current register of authorised users and devices, include batch jobs and devices in the count, never rely on multiplexing to hide users, and treat directory hygiene as the cost control it is. Buyers who manage the authorised population actively keep NUP cheaper than Processor where it should be and switch metrics where it should not. Our Oracle middleware licensing service runs the per server metric analysis, and you can contact the practice to scope it.
Common questions.
What is Named User Plus for Oracle middleware?
Named User Plus licenses a middleware product by counting the individuals and non human operated devices authorised to use it, subject to a minimum number of named users per processor the software runs on.
Who counts as a named user?
Any individual authorised to use the program, whether or not they actively use it, plus any non human operated device that accesses it. The count is based on who is permitted, not who logs in.
What is the per processor minimum?
Oracle requires a minimum number of named users for every processor, calculated as cores multiplied by the core factor. On large hardware the minimum can exceed the actual user count, so you pay the minimum.
When is Named User Plus cheaper than Processor?
Only below a break even point set by the minimum and list prices. It wins for small, stable, countable internal populations on modest hardware, and loses for large hardware or unbounded and external populations.
Do batch jobs and devices count toward the user total?
Yes. Oracle counts non human operated devices, which includes automated interfaces, batch schedulers, and connected equipment. High fan in integration workloads often belong on the Processor metric for this reason.
Does multiplexing reduce the user count?
No. Oracle counts named users at the point of origin, not at the multiplexing layer, so the full population behind a front end account or integration tier still counts.