Oracle Named User Plus Licensing: The Complete Guide to NUP Rules, Minimums, and Strategy

What Oracle Named User Plus Actually Means

Oracle Named User Plus (NUP) is a licensing metric defined in Oracle's standard licence definitions as a licence required for each individual person authorised to use the software, and each non-human operated device that accesses the Oracle program. The key word is "authorised" — the metric does not measure actual usage, concurrent sessions, or frequency of access. If a person has the right to access Oracle software, they need a NUP licence regardless of whether they use it daily, monthly, or once a year.

This distinction between authorised access and active use is the source of most NUP licensing disputes. Organisations that believe they are licensed for their active user base discover during Oracle audits that Oracle counts all authorised accounts — including accounts that have never been used, accounts belonging to contractors who left years ago, and integration service accounts that run automated processes.

Oracle's NUP metric applies to a wide range of Oracle products: Oracle Database (Enterprise Edition, Standard Edition 2, and various options), Oracle Fusion Middleware products including WebLogic Server, SOA Suite, Identity Management, Business Intelligence, and several Oracle application tiers. The specific minimum requirements and counting rules vary by product, which is one reason NUP licensing requires careful product-by-product analysis.

Who Counts as a Named User Plus

Oracle's licence definitions specify that a Named User Plus includes every individual person or non-human operated device that accesses the Oracle program. This covers considerably more than most organisations expect when they first evaluate NUP licensing.

Human Users

Every person who is authorised to use the Oracle software requires a NUP licence. This includes regular employees who log in daily, managers who access reporting dashboards infrequently, contractors and temporary workers with system access, employees on extended leave who retain system accounts, and third-party vendors with direct database or application access.

Oracle's definition does not distinguish between full-time employees and part-time workers. A part-time employee who accesses Oracle Database twice a week requires the same NUP licence as a DBA who manages the database all day. The named user licence travels with the individual's access rights, not the volume of usage.

Named licences are person-specific and non-transferable on a concurrent basis. Two employees sharing access credentials under a single NUP licence would constitute a licence violation. Each individual requires their own named licence even if they never access the system simultaneously.

Non-Human Devices and Service Accounts

Non-human operated devices — server-to-server integrations, middleware batch processes, monitoring agents, ETL tools, application integration layers — require NUP licences unless they are operated directly by a licensed named user. This is one of the most misunderstood aspects of Oracle NUP licensing and one of the most common sources of audit findings.

A monitoring tool that polls an Oracle Database every five minutes to check system health requires a NUP licence. An ETL job that extracts data from Oracle Database into a data warehouse nightly requires a NUP licence. A message broker that routes transactions through Oracle Middleware requires a NUP licence per integration point. The scale of non-human device licences in a well-integrated enterprise environment can exceed the human user count significantly.

The exception to non-human device licensing applies where the non-human process is directly operated by a licensed named user. If a DBA runs a script that performs database operations, those operations are covered by the DBA's NUP licence because the DBA is the authorised person operating the tool. However, automated processes that run independently of any user session — scheduled jobs, system agents, integration middleware — require their own NUP licences.

Per-Processor NUP Minimums Explained

Oracle imposes minimum NUP licence counts tied to the number of processor licences that would be required if you were licensing by Processor metric instead. These minimums exist to prevent organisations from using NUP as a way to licence large hardware environments with very small user populations.

Oracle Database Enterprise Edition Minimum

For Oracle Database Enterprise Edition, the minimum is 25 Named User Plus licences per Processor licence that would be required. To determine this minimum, you first calculate how many Processor licences the hardware would require (using Oracle's Core Factor Table to adjust for processor type and core count), then multiply that number by 25.

Example: A server with two Intel Xeon processors, each with 16 cores, would require 2 × 16 × 0.5 (Intel core factor) = 16 Processor licences under the Processor metric. The NUP minimum would therefore be 16 × 25 = 400 Named User Plus licences. Even if only 50 people access the database, you must licence 400 NUP users under the minimum rule.

This minimum calculation makes NUP significantly less attractive than Processor licensing for database environments with small user populations running on powerful servers. The 25 NUP per processor minimum was introduced specifically to maintain Oracle's revenue on high-capacity hardware regardless of actual user numbers.

Oracle Database Standard Edition 2 Minimum

Standard Edition 2 uses a different minimum structure: 10 Named User Plus licences per server (not per processor). This reflects SE2's server-based licensing model, where the licence covers the entire server regardless of socket or core count. The practical effect is that SE2's NUP minimum is typically lower than EE's NUP minimum for equivalent hardware, contributing to SE2's attractiveness for smaller user environments.

Oracle Fusion Middleware Minimums

Most Oracle Fusion Middleware products — including WebLogic Server, SOA Suite, WebCenter, Oracle Business Intelligence Enterprise Edition, and Oracle Identity Management — apply a 10 Named User Plus per Processor minimum rather than the 25 minimum used for Database Enterprise Edition. This difference makes NUP relatively more competitive for middleware products compared to the database.

For WebLogic Server specifically, the NUP minimum of 10 per processor applies to the processor licences required to cover the physical servers or virtual machines running WebLogic. Oracle's virtualisation rules determine what hardware is counted, which means that environment topology directly affects the minimum NUP calculation for middleware.

The Multiplexing Rule and Why It Does Not Help

Multiplexing is the practice of routing multiple users through an intermediary layer — typically a middleware application, web server, or connection pool — so that the Oracle database sees only one or a small number of connections rather than individual user connections. Many organisations assume that multiplexing reduces their NUP licence requirement. Oracle's licence definitions explicitly state that this assumption is incorrect.

Oracle's standard licence definitions state: "Multiplexing does not reduce the number of licences required; multiplexing may reduce the number of connections but does not reduce the number of users that need to be licensed." This means that an e-commerce platform routing 50,000 customer sessions through a three-tier application architecture still requires NUP licences for all 50,000 customers — not just for the application tier that connects to the database.

The multiplexing rule is one of the most commercially significant aspects of Oracle NUP licensing and one that organisations frequently get wrong. Internet-facing applications, customer portals, and B2B integration platforms built on Oracle Database often face enormous NUP exposure precisely because the user population accessing the Oracle platform exceeds what organisations anticipated when they licensed by named user metric.

For internet-facing deployments where the user population is large, unknown, or unlimited, Oracle's Processor licensing metric is almost always the appropriate choice. NUP licensing for internet-facing systems creates an open-ended licence obligation that Oracle's audit methodology will investigate rigorously.

Counting Users in Practice: Common Complications

Determining the correct NUP user count for a compliance review or audit response involves several practical complications that go beyond the basic definition of "named user."

Stale and Inactive Accounts

Oracle's audit approach is to request a list of all database or application accounts with authorised access, regardless of when those accounts last logged in. Accounts for employees who left the organisation six months ago but were not deleted from the database count as authorised users until they are explicitly deprovisioned. Organisations with poor access management practices — a common finding in larger enterprises — frequently discover their NUP position is significantly worse than expected when active user counts alone would suggest.

Oracle auditors typically request user data from Oracle's database audit tables (DBA_USERS, V$SESSION, system logs) and compare the number of accounts with login rights to the number of NUP licences held. Any gap between those two numbers becomes an audit finding and a demand for back licence fees plus annual support.

Oracle Support Fees and NUP Growth

Oracle's annual support fees on Named User Plus licences increase by 8% per year. If an organisation holds 1,000 NUP licences with an annual support fee of $100,000, the support fee in year two is $108,000, in year three $116,640, and so on. Over a five-year period, the cumulative support increase on a fixed NUP licence count is significant. Organisations that are also growing their user base face compounding cost increases: more NUP licences being added each year, each carrying the escalating 8% annual support trajectory.

Shared User Accounts and Single Sign-On

Some organisations create shared functional accounts — a single Oracle Database account used by all members of a specific team, for example — to reduce the perceived user count. Oracle's audit methodology investigates these configurations and treats each individual who accesses the shared account as a named user requiring their own NUP licence. The existence of a shared technical account does not create a shared NUP licence. Each human being authorised to use that shared account requires individual licensing.

Single sign-on environments present similar complications. If a user's enterprise credentials provide access to Oracle systems through an SSO layer, Oracle counts that user as a named user at the point of authentication, regardless of the technical mechanisms between their credentials and the Oracle software.

NUP vs Processor Licensing: When Each Is Preferable

The choice between Named User Plus and Processor licensing should be driven by the arithmetic of the specific deployment, not by Oracle's sales preferences or default contract positions.

When NUP Is the Better Choice

NUP licensing is economically preferable when the actual and foreseeable user population is small relative to the hardware capacity. For a database running on a high-core-count server with a small, well-defined user community — a specialist financial system used by 15 analysts, for example — NUP at 15 licences may be considerably cheaper than Processor licensing for the server's full core count.

NUP is also appropriate when the application has a clearly bounded, identifiable user population with no internet-facing exposure. Internal-only systems with stable user populations where every user can be accurately named and tracked are the textbook NUP use case. The overhead of managing user licence counts is manageable when the population is small and stable.

When Processor Licensing Is the Better Choice

Processor licensing is preferable whenever the user population is large relative to the 25-per-processor NUP minimum, when the application has internet-facing components, when users are unknown or subject to significant growth, or when the organisation has poor access management practices that would make NUP compliance difficult to maintain.

For high-volume OLTP systems, enterprise resource planning platforms with broad user populations, customer portals, and any internet-connected Oracle deployment, Processor licensing provides both compliance simplicity and, in most cases, lower total cost. The administrative overhead of maintaining accurate NUP counts across a large and changing user population also favours Processor licensing for most enterprise deployments.

The break-even calculation is straightforward: divide the total Processor licence cost by the per-unit NUP licence price, and compare that number to the NUP minimum multiplied by the Processor count, plus the actual user count (taking the higher of the two). If actual or expected users are above the NUP minimum, compare Processor cost to NUP cost directly.

NUP Licensing for Oracle Options and Packs

Oracle Database options — Advanced Security, Partitioning, Real Application Clusters, Diagnostics Pack, Tuning Pack, and others — follow the same licensing metric as the base database licence. If Oracle Database Enterprise Edition is licensed by NUP, every option enabled for use must also be licensed by NUP for the same user count and subject to the same per-processor minimums.

The options and packs issue is one of the most common sources of Oracle audit findings. Organisations that licence Oracle Database Enterprise Edition by NUP and then enable options through the Enterprise Manager interface — or through database feature usage — often fail to separately licence those options. Each option carries its own list price, and the licence fees accumulate quickly. An audit finding covering Diagnostics Pack, Tuning Pack, and Advanced Security on a moderately sized database estate can easily run to millions of dollars in back licence fees.

The principle to apply is that any Oracle feature or option used by the users covered by the base NUP licence requires its own matching NUP licence for that feature. Usage of an option by even a single licensed DBA requires that the option be licensed for the minimum NUP count applicable to the deployment.

NUP Licensing in Cloud and Virtualised Environments

Oracle NUP licensing in cloud environments follows different rules than processor-based licensing in the same environments, which creates important strategic choices for organisations moving Oracle Database workloads to OCI, AWS, Azure, or Google Cloud.

On Oracle Cloud Infrastructure, NUP licensing is available as an option for some Oracle Database services, but the BYOL (Bring Your Own Licence) mechanism is more commonly applied to processor-based licences because the OCPU-to-processor mapping makes Processor metric BYOL calculations straightforward. NUP BYOL on OCI requires careful tracking of user populations against OCI service consumption.

On third-party hyperscalers, Oracle's standard NUP licence definitions apply to software deployed in cloud VMs. However, Oracle's guidance on virtual environments — which machines Oracle can "see" on shared infrastructure — may affect the processor count used to calculate NUP minimums. Organisations deploying Oracle Database on AWS or Azure under NUP licensing should confirm the virtual environment rules with Oracle before assuming that NUP counts are calculated solely on the basis of the assigned VM size.

Managing NUP Compliance Proactively

The organisations that avoid expensive Oracle NUP audit findings share several practices. They maintain accurate user access inventories linked to Oracle software deployments, with a disciplined deprovisioning process that removes Oracle access rights promptly when employees leave or change roles. They distinguish clearly between human users and non-human integration accounts, and they licence both categories correctly.

They also review the NUP versus Processor economics at each renewal cycle. User populations change, hardware configurations change, and Oracle's pricing evolves. The metric that was economically optimal at the last renewal may not remain optimal three years later. A fresh calculation before each renewal prevents the gradual drift into a commercially disadvantaged position.

Finally, organisations that manage NUP compliance well keep detailed documentation of how their user counts were calculated, what data sources were used, and when counts were reviewed. This documentation becomes critical evidence if Oracle requests an audit. The ability to present a transparent, methodology-supported user count is far more defensible than an undocumented number that cannot be reconstructed.

For independent support in reviewing your Oracle NUP position, calculating exposure, or preparing for a renewal negotiation, visit the Oracle Knowledge Hub or contact our Oracle advisory team directly.