Named User Plus is the licensing metric customers reach for when usage is bounded and processor licensing would be wasteful. It is also the metric most often miscounted at audit. The definition counts more than humans, the per-processor minimum overrides intuitive math, and multiplexing rules can turn a 200-named-user deployment into a 2,000-user requirement. Here is how NUP actually works.
Oracle's contractual definition of a Named User Plus is "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. A non human operated device will be counted as a named user plus in addition to all individuals authorized to use the programs, if such devices can access the programs."
Two phrases drive most of the audit findings. First, "regardless of whether the individual is actively using" — meaning every authorised user, including dormant accounts, counts. Second, "a non human operated device will be counted as a named user plus" — meaning every batch job, every IoT sensor, every monitoring agent, every robotic process automation bot, every middleware service account that authenticates to the database is itself a Named User Plus.
The audit position is that authorisation, not active use, drives the count. A user with a valid account who has not logged in for six months still counts. A user with database access through a group membership they could activate counts. A contractor who left the company but whose account remains active counts. The leakage between HR offboarding and database deprovisioning is one of the most common sources of NUP overcount.
The "non human operated device" clause is more aggressive than most customers realise. Every device that can authenticate to the database independently must be licensed as a Named User Plus. In an industrial deployment with 5,000 IoT meters writing to a centralised database, that is 5,000 NUPs — independently of any human users.
The user count Oracle would defend is rarely the user count you began with.
Oracle Database Enterprise Edition has a minimum of 25 Named User Plus licences per Processor, calculated by multiplying the processor count of the database server by 25. The minimum applies regardless of the actual user population. A two-processor server with 10 actual users is licensed at 50 NUPs, not 10. A 16-processor server requires 400 NUPs minimum, even if the application has 25 users.
The minimum applies separately to each Option and Pack. If Partitioning is licensed by NUP on the same server, 25 NUPs of Partitioning per processor is also required. Customers stacking three or four Options under NUP licensing find the minimums dominate the cost calculation.
NUP licensing makes sense when actual users on the server materially exceed 25 per processor. For a 2-processor server with 30 users, NUP at 50 licences is cheaper than 2 Processor licences. For the same server with 250 users, NUP at 250 licences is more expensive than 2 Processor licences. The crossover varies by region, list price, and discount, but the rule of thumb is that NUP licensing makes sense for small, bounded, internal user populations and stops making sense for any application open to broad employee or external use.
NUP is unworkable for any database backing an internet-facing application, a partner-portal database, or an application with unbounded user counts. The minimum protects Oracle from the very-low-user case; the user definition protects Oracle from the very-high-user case. Customers attempting to license a 100,000-user e-commerce database under NUP almost always end up over-counting and over-paying compared to a Processor metric.
The NUP-versus-Processor decision framework with worked examples.
Multiplexing is Oracle's term for any architecture in which a frontend application pools or aggregates user connections before they reach the database — a connection-pool service, a middleware tier, an API gateway, a frontend portal authenticating users and using a shared service account into the database. Oracle's licensing position is that multiplexing does not reduce the user count. The licence must be held for every distinct end user of the application, regardless of how many physical database connections are open at any time.
In practice, this means a portal application with one service account into the database and 10,000 end users still requires 10,000 NUPs. The shared service account does not anonymise the user population from a licensing perspective. Customers who built application architectures specifically to "reduce database licensing" through connection pooling have, in our experience, the largest NUP audit gaps.
Batch jobs are treated as named users — one batch process or scheduled job equals one Named User Plus. Customers running large numbers of batch jobs through a single OS account still need to license each distinct job. Middleware-mediated batch (Informatica, Tibco, Boomi, custom orchestrators) is sometimes counted by Oracle as the number of underlying user-initiated jobs, not the number of OS accounts on the orchestrator.
Five NUP-specific audit positions we see consistently from Oracle LMS:
The defensible user count is built before the audit notice, not after.
If NUP is a material part of your Oracle estate, independent advice ahead of an audit or renewal is consistently the highest-leverage spend in the relationship — usually starting with a software license compliance assessment that rebuilds the defensible user count before Oracle's LMS team builds its own.
Our Oracle practice rebuilds NUP baselines for renewal leverage and audit defence.
Most teams learn a metric changed when the audit letter lands. Subscribers learn the month it happens, with the buyer-side response already mapped.