Oracle Named User Plus Licensing: Counting Rules, Per-Processor Minimums, and the Audit Traps

Named User Plus is the cheapest Oracle metric on paper and the most expensive one to defend in an audit, because the definition counts authorization rather than usage and enforces a hardware-derived floor underneath your headcount. This guide gives you the verbatim contract language, the crossover math at 50 users per Processor, the edition-by-edition minimums, and the reconciliation evidence Oracle's auditors actually accept.

What Named User Plus Actually Means in Your Contract

Start with the text, not the sales deck. Oracle's License Definitions and Rules defines Named User Plus as "an individual authorized to use the programs installed on one or more servers, regardless of whether the individual is actively using them," adds that "a non-human operated device is counted as a Named User Plus in addition to all authorized individuals," requires that where multiplexing hardware or software (a TP monitor or web server, for example) is used "the number must be measured at the multiplexing front end," permits "automated batching of data from computer to computer," and puts the customer on the hook for "maintaining the Named User Plus per Processor minimums" in the user minimum table. Read each clause as a separate obligation, because Oracle's auditors do. The most expensive word in the paragraph is authorized. It is not "active," not "concurrent," not "logged in during the sample period." If a person holds the right to access the software, they consume a license whether they touch it daily, quarterly, or never, which is why dormant accounts, service desk break-glass IDs, and offboarded contractors still sitting in an Active Directory group turn into findings.

The second structural trap is that NUP is two counts, not one, and you must satisfy both simultaneously. Oracle's own definitions state that the minimums table provides the minimum number required "and all actual users must be licensed." The hardware-derived floor is a floor, never a cap. A 40-user application on a server whose processor math demands 100 NUP owes 100. A 400-user application on that same server owes 400, and the floor is irrelevant. Buyers routinely model one count and get invoiced on the other. In 25 years of these negotiations, the single most common self-inflicted shortfall I see is an estate that carefully proved its 25-per-Processor minimum and never rebuilt an accurate authorized-user list underneath it. Work through the arithmetic on both counts before you commit to a metric, and use our Named User Plus or Processor metric decision framework to document the comparison at the time of purchase.

The most expensive word in the Named User Plus definition is "authorized," and Oracle wrote it that way deliberately.

Third, check which version of the definitions your ordering document actually incorporates. Oracle publishes dated License Definitions and Rules documents (v111815, v061525 and others), and your agreement points at one specific version, not at whatever is on oracle.com today. This matters both ways. The June 15, 2025 text (v061525) enumerates IoT Devices expansively, including smart mobiles, fire alarms, door locks, medical sensors, fitness trackers, and security systems, which materially widens the non-human device population an auditor can claim. Older versions carry carve-outs worth defending, such as the v111815 rule that for certain management and monitoring packs (System Monitoring Plug-in for Non-Oracle Databases, Management Pack for WebCenter Suite) only the users of the managed program count toward the NUP quantity. Treat the version reference as a negotiation asset on new orders and as a defense asset in an audit: pull the exact document your contract names, quote it back, and refuse to be assessed against language you never signed.

The 50:1 Price Ratio That Decides the Metric

The Oracle Technology Global Price List dated August 3, 2026 makes the metric decision arithmetic, not opinion. Every Database line prices Named User Plus at exactly one-fiftieth of the Processor price. Enterprise Edition is $950 NUP against $47,500 per Processor. Standard Edition 2 is $350 against $17,500. Multitenant is $350 against $17,500. Real Application Clusters is $460 against $23,000. NoSQL Database Enterprise Edition is $200 against $10,000. The prior list, effective April 16, 2026, carried identical Enterprise Edition figures, so core Database list pricing held flat between the two 2026 releases. That consistency is the point: the theoretical crossover is 50 authorized users per Processor on every one of these lines, and any vendor argument that "NUP is cheaper for you" is really an argument about how many people you will authorize over the license term.

Do not manage to 50. The practical crossover sits well below it, and in my experience the number that survives a three-year term is closer to 30 to 35 authorized users per Processor. Three forces push it down. First, growth headroom: a NUP purchase sized to today's list fails the moment a new reporting group, a merged business unit, or an integration project adds authorizations, and incremental NUP is bought at whatever discount you can win later, not the one you won at signature. Second, contractor and service-account churn: every rotation adds identities faster than deprovisioning removes them, and non-human operated devices count in addition to individuals. Third, the risk premium on counting accuracy: a Processor license needs you to defend a hardware boundary, while a NUP license needs you to defend a complete, evidenced, continuously maintained list of every authorized human and device behind every multiplexing tier. That second evidentiary burden is the expensive one. If a Processor buy costs 20 to 40 percent more at list but removes an audit exposure you cannot cheaply prove away, buy the Processor licenses and stop counting people. Model both, then apply our Oracle metric decision guidance to the specific servers in scope rather than to the estate average.

The Per-Processor Minimum Math, Step by Step

Oracle documents the sequence explicitly, and the order is not negotiable: product minimums for NUP are calculated after the number of Processors to be licensed is determined, using the Processor definition (Oracle Database Licensing, oracle.com PDF 070584). That means three discrete steps. First, count physical cores in every server where the program is installed and running and multiply by the Core Factor. Second, multiply the resulting Processor number by the per-Processor NUP floor for that program and edition. Third, license the higher of that floor and your real authorized headcount, because Oracle's License Definitions and Rules state the minimums table gives the minimum required "and all actual users must be licensed." The floor is never a cap. Buyers who invert the sequence, counting people first and then checking hardware, consistently under-model the number and walk into audits with a shortfall they never budgeted.

The canonical example is worth committing to memory because Oracle's auditors use it. An eight-core Intel x86 server carries a 0.5 Core Factor, so eight cores equals four Processors. Database Enterprise Edition's floor of 25 NUP per Processor produces a minimum of 100 Named User Plus licenses, even if precisely 20 named individuals are authorized. At the August 3, 2026 list price of $950 per NUP, that is $95,000 of license for a 20-user system, plus 22 percent support at $209 per NUP, or $20,900 annually. The four-Processor alternative at $47,500 each is $190,000, so NUP is still cheaper here, but you are paying for 80 licenses that map to nobody.

Note what this does to hardware disputes. Every argument about virtualization boundaries and Core Factor now becomes a user-count argument. If Oracle asserts that a VMware cluster is not hard-partitioned and all 32 cores in the cluster must be licensed rather than the 8 cores of the guest, your Processor count jumps from 4 to 16, and the EE floor jumps from 100 NUP to 400 NUP, a $285,000 list swing on a system with 20 users. Same people, same usage, four times the license. Read our Named User Plus or Processor metric decision analysis before you concede any core-count position, because in NUP estates you are conceding headcount at the same time.

In a NUP estate, every core you concede in a virtualization argument is a user you never hired.

Edition and Product Floors: 25, 10, 5, and Sockets

The floors diverge by edition and by product family, and the divergence is where most estates misprice themselves. Database Enterprise Edition is 25 NUP per Processor. Standard Edition 2 is 10 NUP per server, not per Processor, which is a materially different and much softer floor. Legacy Standard Edition and Standard Edition One carried 5 NUP per customer (Livingstone Technologies, March 20, 2025). Most Fusion Middleware sits at 10 NUP per Processor, including WebLogic Server, SOA Suite depending on SKU, WebCenter, OBIEE, and Identity Management, so a two-Processor middleware server floors at 20 NUP rather than Database EE's 25. WebLogic Standard Edition counts differently again, at 10 NUP per occupied processor socket: one socket equals 10 NUP, two sockets equal 20.

Two of these lines are live market disagreements, and you should treat them as such rather than as settled fact. On WebLogic Standard Edition, the market splits between a NUP-only reading and a socket-default reading with NUP as an alternative metric. On SOA Suite, reporting puts WebLogic Suite at 10 NUP per Processor while placing SOA at 25 (Redress Compliance Middleware Guide, mid-2026), which is a 150 percent difference in the floor on the same physical server. Do not resolve either from a blog, including this one. Pull the minimums table referenced in your own ordering document and match it SKU by SKU, because the table incorporated by reference into your contract is the only one that bills.

There is a third contested reading with real money attached: that Processor-metric purchases still carry NUP floors underneath them, such that eight Processor licenses on a 10-NUP product would also require 80 NUP even with 50 actual users. In 25 years of negotiating this vendor I have seen auditors advance that position and I have seen it withdrawn under pressure, and it is product specific. Demand the clause reference in writing before you accept a single dollar of it. If Oracle cannot cite the ordering document section and the effective minimums table version, the claim is not a finding, it is an opening bid.

Multiplexing: Why the Middle Tier Does Not Shrink Your Count

The multiplexing clause is the single most expensive sentence in the Named User Plus definition, and it is three lines long: "where multiplexing hardware or software (e.g., a TP monitor or web server) is used, the number must be measured at the multiplexing front end." Read that literally, because Oracle's auditors do. The front end is the layer where human beings, or devices, first touch the chain that ends at the database. Everything downstream of that point is invisible to the count. A Java connection pool holding ten persistent sessions against Enterprise Edition does not produce ten Named User Plus licenses; if 4,000 employees log into the portal that pool serves, you owe 4,000 NUP at $950 list, which is $3.8 million before discount, against a Processor position on a four-Processor server that lists at $190,000. I have watched clients discover that ratio for the first time in an audit response letter, and there is no clever architecture argument that recovers it. Oracle wrote the rule precisely to kill the "we only see ten sessions" defense, and it has held in every negotiation I have run against them.

The architectures that attract audit attention are predictable, and every one of them looks like a cost saving to an engineer and a liability to a licensing analyst. Model them on Processor from day one and treat any request to move them to NUP as a red flag rather than a discount.

• Application server connection pools (WebLogic, Tomcat, JBoss) fronting an employee or customer portal: count every authorized portal identity, not the pool.
• Enterprise service bus and integration layers where a single service account writes on behalf of thousands of upstream requesters.
• Reporting and BI tiers, where a semantic layer proxies queries for an entire finance or operations population.
• SaaS integrations, Salesforce, ServiceNow, Workday, writing into Oracle through a single integration user: the SaaS user base is the front end, and Oracle will ask for its headcount.
• Any customer-facing or partner-facing web application, where the authorized population is unbounded by definition and therefore uncountable, which makes NUP contractually indefensible.

If the user boundary is uncontrolled, the metric is already decided: Processor, or you are underlicensed the day you sign.

The buyer move is structural, not tactical. Before you accept a NUP quote, draw the authorization boundary for the application and ask whether you can produce a defensible, enumerable list of every human and device on the far side of the front end. If you cannot, refuse NUP outright, even when Oracle's rep offers a steeper percentage discount on it, because the discount is applied to a quantity you will lose control of within two years of go-live. Our Named User Plus or Processor metric decision guide works through the boundary test in detail. In my experience across 25 years of these negotiations, internet-facing systems licensed on NUP are the most common source of eight-figure audit findings, and they are entirely self-inflicted.

Non-Human Users: Batch Jobs, Sensors, and IoT Devices

The definition continues: "a non-human operated device is counted as a Named User Plus in addition to all authorized individuals if it can access the programs," while "automated batching of data from computer to computer is permitted." Those two clauses sit next to each other and appear to contradict, which is exactly why Oracle likes them. The practical line falls on whether the interface has an independent origin. A scheduled ETL job that moves last night's transactions from one server to another is permitted batching and costs nothing extra. A meter, sensor, PLC, kiosk, badge reader, or handheld scanner that originates data and can reach the database, directly or through a middle tier that fails the multiplexing test, is a device and carries its own NUP license on top of every authorized person. The phrase "in addition to" is the part that gets missed in internal license reviews: devices do not substitute for headcount, they stack on it.

Oracle widened the surface area materially in its License Definitions and Rules v061525, dated June 15, 2025, which enumerates IoT Devices as simple human-operated input devices or remotely managed and fully automated devices collecting information or responding to commands from centralized control points, and names smart mobiles, fire alarms, door locks, medical sensors, fitness trackers, and security systems. Run that list against a real estate. A regional utility with 900 employees and 400,000 smart meters feeding an Oracle-backed head-end system has a device population three orders of magnitude above its headcount. A hospital group with 6,000 staff and 40,000 connected monitors, pumps, and access controls is in the same position. A manufacturer with plant-floor telemetry into an Oracle historian is too. Under a literal reading, a NUP position on those systems is not merely expensive, it is arithmetically impossible, which is the point: these estates belong on Processor, and the device clause is the mechanism Oracle uses to prove it during an audit.

The defense is documentary and it has to exist before Oracle asks. Build an interface register that lists every non-human data path into each Oracle database and classifies it, with the supporting evidence attached, as either permitted computer-to-computer batching or a licensable device population. Record the scheduler, the source system, the direction of flow, the account used, and whether any human or sensor can trigger the interface on demand rather than on a fixed schedule. Where a device population exists, decide the metric on that basis and put the reasoning in writing, ideally validated by counsel or an independent advisor, alongside the reconciliation approach in our metric decision workbook. Classification arguments you make during an audit are treated as post-hoc rationalization; classification you documented at deployment is treated as your license position. In every audit I have defended, that timestamp difference has been worth more than any technical argument that followed.

Options and Packs Must Match the Base Database

The License Definitions and Rules are blunt on this point: license counts for the listed option programs must match the associated database. There is no such thing as licensing Enterprise Edition for 400 Named Users Plus and Partitioning for 40 because "only the data warehouse team uses it." If the base database carries 400 NUP, every option installed or used against that database carries 400 NUP. On top of that, NUP-licensed options carry their own 25-per-Processor minimum, calculated on the same processor count as the base, so an option on a four-Processor server can never be licensed below 100 NUP regardless of how few people touch the feature. In practice this converts a single per-user figure into a stack. At the August 3, 2026 Technology Global Price List, Enterprise Edition is $950 per NUP, Multitenant adds $350, Real Application Clusters adds $460, and Advanced Security adds its own line, so a 400-user estate that quietly accumulates three options is carrying a per-user cost several times the headline EE number, plus 22 percent support on all of it, escalating annually under the Inflationary Adjustment Rate. The real exposure is not the deliberate purchase. It is the DBA who enables Partitioning during a test refresh, or the DBA who uses `ALTER SYSTEM` to turn on Diagnostics Pack features during a performance incident, because usage on one instance creates a liability sized to the full licensed population of that database, not to the incident. Treat option enablement as a change-controlled event with a named approver, and run DBA_FEATURE_USAGE_STATISTICS monthly rather than annually.

There is one carve-out worth memorizing, because Oracle's audit teams rarely volunteer it. For management and monitoring packs including the System Monitoring Plug-in for Non-Oracle Databases and the Management Pack for WebCenter Suite, the License Definitions and Rules state that only the users of the managed program count toward the NUP quantity. If Oracle prices those packs against your full database NUP population rather than the population of the managed target, cite the definitions text in your ordering document version and demand the recalculation in writing. On mid-size estates that single correction has repeatedly removed six-figure lines from a draft audit finding, and the same discipline of anchoring every count to contract text carries over into the broader Named User Plus or Processor metric decision.

Where NUP Beats Processor, and Where It Quietly Loses

The decision is arithmetic, not preference. Every Database line prices NUP at exactly one-fiftieth of the Processor price, $950 against $47,500 on Enterprise Edition, so Processor wins the moment your licensable population passes 50 per Processor. The complication is that "licensable population" is not headcount. It is the higher of actual authorized users (including non-human devices) and the floor of 25 NUP per Processor on EE, 10 per server on SE2, and 10 per occupied socket on WebLogic Standard Edition. That floor is derived from hardware you may not control, which is why the metric behaves so differently across deployment patterns.

Two traps sit inside that table. First, floors are calculated after the Processor count is determined, so any virtualization, DR standby, or capacity headroom that inflates cores inflates your NUP minimum with it. On a consolidation platform your license bill scales with hardware you are actively trying to make elastic, which is the opposite of the outcome you bought consolidation to achieve. Second, and less visible on the business case, NUP's real cost is not the license fee. It is the perpetual obligation to prove a number. Processor licensing is proved once, from a configuration file and a core count. NUP is proved every time Oracle asks, from Active Directory groups, database roles, application authentication tables, service accounts, and device inventories, all of which drift monthly. Budget internal effort for that proof and put it in the comparison, because in our audit-defense work the labor cost of reconstructing a defensible user list under a 45-day audit clock has repeatedly exceeded the annual saving the NUP metric was chosen to deliver.

NUP's real cost is not the license fee, it is the perpetual obligation to prove a number.

Do this now: for every EE database, calculate the floor (Processors x 25) and the authorized population including devices, take the higher, and compare it to Processor list at $47,500. Anything landing above roughly 40 users per Processor should move to Processor before the next true-up, because you are one project, one acquisition, or one hardware refresh away from crossing the line involuntarily. Anything that cannot enumerate its user population with an auditable source should already be Processor. Document the crossover calculation in the same file as your metric decision record so the rationale survives the staff turnover that Oracle's next audit cycle will otherwise exploit.

Support Economics: Why the Metric Choice Is Permanent

Support is where the metric decision becomes irreversible, and buyers routinely miss it because the license line is the only number in the business case. Oracle prices technical support at 22 percent of net license fees, which means the discount you negotiate on the license is also the discount you negotiate on every renewal for the life of the estate. At the August 3, 2026 price list, Enterprise Edition is $950 per NUP with $209 of annual support, and $47,500 per Processor with $10,450 of annual support. Each discount point on an NUP line is worth roughly $2.10 per year in perpetuity, and each point on a Processor line is worth roughly $104.50. Multiply across a 2,000-NUP estate and a single percentage point of extra discount is about $4,200 per year of avoided support, or $42,000 over ten years before any uplift. The asymmetry that matters is directional: Oracle will happily convert NUP entitlements to Processor when your headcount grows, because that transaction increases net license value and therefore increases the support base. Moving the other way, or simply reducing quantity, triggers repricing of the remaining support base under Oracle's matching service levels and pricing-following-license rules, so shedding 30 percent of your licenses rarely produces a 30 percent support reduction. In our practice, most attempts to trim quantity end with the remaining lines repriced closer to list and total support roughly flat.

The 2026 price list also changed the renewal escalation mechanic, and this deserves a redline before your next order. Flat-uplift language has been replaced with indexed renewals: renewal support equals the prior-year fees increased by the Inflationary Adjustment Rate (IAR), or, where an active Contractual Cap Rate (CCR) exists, the lower of the CCR or the IAR, with any support cap in the ordering document limiting the adjustment. Read that carefully. The IAR is defined and published by Oracle, not by an independent index you can audit, and the CCR only protects customers who contracted for it. If your ordering document contains no numeric cap, you have accepted an escalator that Oracle sets unilaterally.

• Insert an explicit numeric cap in the ordering document now, expressed as a percentage per renewal year, and state that it applies notwithstanding any published IAR.
• Ask for the cap to survive CSI consolidations, assignments, and any future metric conversion, otherwise a reorganization resets you to the default escalator.
• Model ten-year support, not three-year, before choosing between NUP and Processor: the metric with the lower license price is not always the metric with the lower total.
• Fix the discount on future quantities of the same SKU, because unpriced growth is where support bases quietly double.

How Oracle Audits a Named User Plus Estate

Understand the mechanic before you respond to the letter. Oracle's collection scripts, whether run by License Management Services or Global Licensing and Advisory Services, cannot enumerate authorized users, because authorization is a contractual concept that exists in your policies, not in the database. So Oracle asks you to produce the named user list. Then it attacks completeness. The standard evidence set includes DBA_USERS, listener logs, AUD$ and unified audit trail records, Active Directory group membership, application role and profile tables, and your interface or integration inventory. Anything that appears in those sources but not on your list becomes a proposed addition, and the burden of explanation falls on you. The finding pattern is predictable after twenty-five years of these engagements: disabled accounts that were never de-authorized, shared service and application accounts counted as individuals, orphaned schemas from decommissioned projects, contractors and third-party support staff with standing access, read-only reporting and BI consumers, and non-production copies where the same population is counted a second time.

Then the arithmetic compounds against you. Backdated license claims attract 22 percent support, and that base escalates, so a 500,000 unit license exposure becomes 700,000 or more once five years of support is layered on. Add the per-Processor floor and the damage doubles again: if the audited server carries 25 NUP per Processor and the box resolves to eight Processors, no argument about actual users takes you below 200, and every additional Processor Oracle can attribute through virtualization or DR adds 25 more. This is why an audit finding built on the auditor's query rather than your policy is so expensive.

The defensive posture follows from the contract, not from the tooling. You own the definition of authorization within the boundaries of the license text, so define it first, in writing, before anyone asks. Publish a policy that states which access mechanisms constitute authorization, how service accounts and batch identities are treated, how de-authorization is performed and evidenced, and who signs off quarterly. Then evidence it consistently across every environment, because inconsistency is what auditors monetize. If you are still deciding which metric to defend, work the crossover first using our Named User Plus or Processor metric decision guide, then align the policy to whichever metric you will be defending for the next decade. Never hand over a raw DBA_USERS extract as though it were a license count, and never let an auditor's SQL become your entitlement baseline.

Authorization is a contractual concept that lives in your policy, not in DBA_USERS, and whoever defines it first controls the license count.

Building a Defensible Named User List Before Anyone Asks

The only artifact that reliably caps an Oracle user-count claim is a dated, owner-signed named user register maintained per database instance, and in 25 years of these disputes I have never seen a spreadsheet without an owner's name on it survive contact with Oracle's Global Licensing and Advisory Services team. Build one row per authorized individual or documented device interface, and map both the database account and the upstream application account to a named person. Against each row, record the authorization source: the Active Directory group that grants entry, the HR record that establishes employment, or the service catalogue entry that defines an interface. Rows without an authorization source are not defensible; they are concessions waiting to be counted. Removals need the same rigor: keep the deprovisioning ticket, the date, and the account-disabled evidence, because Oracle's definition counts anyone authorized to use the programs regardless of whether they ever log in, and a dormant enabled account is a billable user. Finally, declare the multiplexing boundary explicitly for every front end. State in writing, per system, where you assert the count is measured, because the contract requires measurement at the multiplexing front end and silence on that point hands Oracle the wider reading.

• Reconcile the register quarterly against live database accounts, application role tables, and the identity directory, and sign off the delta with a named owner each time.
• Wire joiner-mover-leaver into the register so that a termination in HR triggers both account removal and a register line closure with evidence attached.
• Impose a standing ban on new NUP-metric deployments without an architecture review, because internet-facing or pooled front ends turn a cheap metric into an uncountable one.
• Publish a written classification rule for every interface: automated batching of data between computers is permitted, but a non-human operated device that can access the programs counts as a Named User Plus in addition to all authorized individuals.
• Store the register with the ordering document and the applicable License Definitions and Rules version, so the count and the definition it was built against travel together.

Treat the register as an exhibit, not a housekeeping task. In an audit, Oracle's alternative to your evidence is to count everything its scripts can see: every schema, every service account, every dormant login, every device on the network segment. A signed register with authorization sources and deprovisioning proof gives you a defensible ceiling and forces the argument onto the definition rather than the discovery output. Our Named User Plus or Processor metric decision guide sets out the same evidence structure alongside the crossover math.

What to Do First: A 30-Day Buyer Action Plan

Sequence this work, because doing it out of order costs money. Start with the paper, not the estate. Pull every ordering document and identify which version of the License Definitions and Rules is incorporated by reference, since the June 15, 2025 text (v061525) enumerates IoT devices, including smart mobiles, door locks, medical sensors and fitness trackers, while older incorporations do not. Extract every NUP line, its quantity, and its stated minimum. Then recompute Processor counts on current hardware using physical cores multiplied by the Core Factor, and derive the floor after the Processor count is settled, which is the order Oracle's own licensing documentation prescribes. Apply the correct floor per family: 25 NUP per Processor on Database Enterprise Edition, 10 per server on Standard Edition 2, 10 per Processor on most Fusion Middleware including WebLogic Server and OBIEE, 25 on SOA Suite, and 10 per occupied socket on WebLogic Standard Edition. License the higher of the floor and actual authorized headcount, never the lower.

Now price the alternative. At list, Enterprise Edition is $950 per NUP against $47,500 per Processor, a clean 50:1 ratio, so any line already carrying 50 or more real users per Processor is mispriced as NUP and should be modelled as Processor. Standard Edition 2 sits at $350 against $17,500, the same ratio. Flag every internet-facing, pooled, or device-driven system for conversion, because those populations are unbounded and indefensible under an authorization-based metric. Build the named user register for what remains. Then take the support language into your next renewal in writing: the August 3, 2026 price list ties renewals to the Inflationary Adjustment Rate unless an active Contractual Cap Rate exists, in which case the lower of the two applies, and any cap in the ordering document limits the adjustment. That cap is negotiable only before you sign, and at 22 percent of net it compounds against you for the life of the estate. The metric decision analysis covers the crossover modelling in detail.

One escalation trigger. If Oracle has already contacted you about user counts, stop volunteering lists immediately. Settle the definition argument, the multiplexing boundary, the batch-versus-device classification, and the applicable Definitions version, before you produce a single line of data, because every count you hand over becomes the baseline you then have to argue down.

Related reading: The 25 NUP-Per-Processor Minimum for Enterprise Edition, With Worked Server Examples.

Frequently asked questions

Does a user who never logs in still need a Named User Plus licence?

Yes. Oracle's definition counts an individual authorized to use the programs installed on one or more servers regardless of whether that individual is actively using them. Concurrency, session counts, and login frequency are irrelevant to the metric. This is why disabled-but-not-removed accounts and dormant contractor access are the most common audit findings.

How many users before Processor licensing is cheaper than NUP?

On Oracle Database, NUP is priced at exactly one-fiftieth of the Processor price ($950 versus $47,500 on Enterprise Edition on the August 3, 2026 list), so the arithmetic crossover is 50 authorized users per Processor. In practice you should switch well below 50 to absorb growth, contractor churn, and the cost of proving your count every year. Any system with an uncontrolled user population should be Processor regardless of headcount.

Can the 25 NUP per Processor minimum ever be waived or reduced?

Oracle's standard position is no: the minimums table sets a floor and the definitions state all actual users must also be licensed. Reductions are only ever contractual, granted in the ordering document, and they are rare outside large transactions. If you cannot get relief, the answer is usually to reduce licensable cores or move the workload to Processor, not to argue the floor.

Does putting a web server or connection pool in front of the database reduce my NUP count?

No, and attempting it is a reliable way to generate a large audit claim. Where multiplexing hardware or software is used, Oracle requires the count to be measured at the multiplexing front end, so the population is the people reaching that front end, not the pooled database sessions. Automated batching of data from computer to computer is permitted, which is a narrow exception, not a licence to pool interactive users.

Do sensors, robots, and IoT devices count as Named Users Plus?

A non-human operated device is counted as a NUP in addition to all authorized individuals if it can access the programs. Oracle's current definitions explicitly enumerate IoT devices including smart mobiles, fire alarms, door locks, medical sensors, fitness trackers, and security systems. In manufacturing, utilities, and healthcare estates, device counts routinely exceed human headcount, which usually makes Processor the correct metric.

Do database options and management packs need the same NUP quantity as the database?

Yes for options: licence counts for option programs must match the associated database, and NUP options carry their own 25-per-Processor minimum. Management and monitoring packs are the exception worth citing, because for certain packs only the users of the managed program are counted. Get the applicable definitions version into the discussion before accepting Oracle's pack quantities.