A single Oracle JRE hidden inside a network appliance can convert a 40-server footprint into a 5,000-employee subscription worth $630,000 a year at list

Under the employee metric, scope is decoupled from footprint: Oracle does not price what you deployed, it prices who you employ. That means an unmanaged JRE inside a monitoring agent, a load balancer, or a vendor middleware stack carries the same commercial consequence as a thousand-server rollout, and the October 2026 OTN cliff on JDK 21 will convert quietly-patched appliances into paid installs. Your next move is a discovery sweep of the estate nobody scans, before Oracle's script does it for you.

Prepared by Redress Compliance · August 29, 2026 · Oracle Java advisory. Discovery and audit-defense engagements, 2023 to 2026.

Every Java binary in your estate falls into one of three legal buckets, and the commercial distance between them is enormous. The first is a restricted-use grant inside an Oracle product.

Oracle's own Fusion Middleware licensing documentation states that Java SE shipped with WebLogic is restricted to use with WebLogic Server, Oracle Containers for J2EE, and Coherence, and is included for the sole purpose of enabling client applications to reach WebLogic Suite components.

Coherence is the outlier: it carries a full-use Java SE entitlement.

Oracle's business applications (E-Business Suite, PeopleSoft, JD Edwards) carry version-locked restricted grants tied to the Java version shipped with the release, which means the moment your platform team patches that JRE independently of the application.

The grant no longer covers what is installed.

The second bucket is OEM/ISV redistribution, where the software vendor holds a distribution agreement with Oracle and you are covered as their end user. That cover is real but it is the vendor's, not yours, and it evaporates the second the JRE gets used for anything outside that product.

The third bucket is everything else: unlicensed production installs, where you carry the full employee-metric bill.

Standard SAM discovery finds Java the way it finds Microsoft Office: by looking for an installer footprint. Embedded Java has no installer footprint. In 25 years of running these sweeps, the same seven hiding places recur, and each one defeats discovery for a different technical reason.

• Network and security appliances. Load balancers, WAFs, firewalls, and SAN switches ship a JRE to run their administrative web console. The filesystem is read-only or vendor-locked, agents cannot be installed, and the appliance is usually classified as hardware in the CMDB rather than as a software host.
• Monitoring and APM agents. The agent itself runs on a JVM, often a private one dropped into the agent's own directory tree. No registry key, no package manager entry, and the agent is deployed by the monitoring team rather than through the standard build.
• Backup, storage, and hypervisor management consoles. These carry a bundled JRE for the management server and frequently a second one for the thick client. They sit on infrastructure servers that inventory tooling treats as out of scope.
• ETL, BI, and reporting tools. Java is the runtime, not an add-on. The JRE lives inside the product directory, so registry-based discovery reports the product but never the Java version underneath it.
• Build servers and CI agents. Multiple JDKs are installed side by side by developers, often unzipped from a tarball into a home directory. Nothing is registered, and the hosts turn over constantly.
• Thick-client installers on laptops. Trading platforms, CAD tools, and engineering clients drop a private JRE into a versioned subdirectory. The uninstaller removes the application and leaves the JRE. Desktop and laptop processors are excluded from the 50,000-processor limit, but the installs still evidence Oracle Java use.
• Container base images. A Dockerfile that pulls an Oracle JDK layer creates a licensable install on every running container. Ephemeral workloads are gone before a scheduled scan runs, and image registries are almost never inventoried.

The pattern across all seven is that Oracle Java arrives as somebody else's dependency, on hardware or in artifacts that your software asset management scope was never written to cover.

Fix that by scanning filesystems for java and java.exe binaries and reading their release files, rather than querying installed-software tables, and by extending scope to appliances, images, and build infrastructure.

When you count what turns up, use the processor and environment scoping rules to separate what merely evidences use from what consumes the 50,000-processor allowance.

Before January 2023, an unnoticed JRE inside a load balancer was an accounting nuisance. You counted the processors it ran on, applied the Named User Plus or processor rate, and trued up for a few thousand dollars. The exposure scaled with the finding: a small install produced a small invoice.

That proportionality is what made discovery a hygiene activity, something the SAM team did between more urgent work. The Employee metric destroyed that relationship completely. Oracle no longer prices what you deployed.

It prices who you employ, and the deployment is reduced to a single yes or no question: does Oracle Java run anywhere in your estate for production purposes?

Run Oracle's own arithmetic to see what that switch is worth. Oracle's published price list walks through a 28,000-employee company, 23,000 staff plus 5,000 agents and contractors, at $6.75 per employee per month, arriving at $2,268,000 per year.

Nothing in that calculation references servers, cores, virtual machines, or JVM instances. It references headcount. A company with 40 Java servers and a company with 4,000 Java servers, at identical headcount, pay identically.

And the 5,000-employee organization running Oracle Java on 40 servers pays $630,000 per year at list, which is $15,750 per server, a number that has no relationship to any technical fact about those servers.

The band structure makes the disconnect sharper still. Seven bands run from $15.00 per employee per month at 1 to 999, down to $5.25 at 40,000 to 49,999. At 9,999 employees annual list is $1,259,874. At 10,000 it is $990,000.

Hiring one more person removes $269,874 from the bill, which we cover in detail in the Java band table. If your commercial exposure moves more from an HR headcount reconciliation than from a server decommission, you are no longer managing a technology footprint. You are managing a trigger.

Gartner recorded price increases of two to five times for organizations that moved to the employee model, with some reporting increases up to 700%. Those multiples are not the result of new deployments. In most cases the estate was unchanged; only the metric moved.

That is the definitional feature of a binary risk. The magnitude of the finding does not determine the magnitude of the bill.

Three consequences follow, and they are unpleasant if your remediation program was scoped as a cleanup exercise. First, partial cleanups are commercially worthless. Removing Oracle Java from 380 of 400 hosts saves nothing if the remaining 20 are production.

In a proportional model that was a 95% reduction. In a binary model it is a 0% reduction. Second, the only two defensible end states are zero Oracle Java in the estate, or Oracle Java present exclusively under documented restricted-use grants where you can produce the grant text on demand.

There is no acceptable middle position. Third, discovery is now a strategic function, not a hygiene one, because a discovery program that finds 90% of your Oracle Java has failed at exactly the same rate as one that found none.

That last point defines the asymmetry you are negotiating against. Oracle needs one finding.

One JRE inside a monitoring agent, one Java 8u211-or-later runtime under a backup appliance, one download record from an engineer patching a network device, and the conversation is about headcount rather than hosts.

You need a complete negative across every server, every appliance, every vendor-shipped stack, and every desktop image, sustained continuously, because the October 2026 OTN cliff on JDK 21 will silently reclassify installs that were legitimately free the week before.

Complete negatives are expensive to produce and impossible to prove absolutely. Single findings are cheap.

Price that asymmetry into how you fund discovery. Against a $630,000 annual list exposure at 5,000 employees, a discovery and remediation program costing $150,000 is not overhead. It is the cheapest insurance available, and unlike the subscription it is a one-time cost against a recurring liability.

Buyers who still treat appliance scanning as a low-priority ticket are making an implicit bet that the metric is proportional. It is not.

Third-party products that ship an Oracle JRE are supposed to carry an OEM or ISV redistribution agreement with Oracle that extends to the end customer. Some do.

Many do not, and a datasheet line reading "Java 8 required" or "bundled JRE included" is a technical prerequisite statement, not a license grant.

In our experience, when Oracle LMS raises an appliance finding, the first thing it asks for is the vendor's redistribution entitlement, and the buyer, not the vendor, is the entity named on the audit letter.

Put the question in writing to every vendor whose product contains a JVM: does your redistribution agreement with Oracle cover our production use of the bundled Oracle Java runtime, specifically version X.

And will you confirm that in a countersigned statement? Verbal assurance from an account manager is not evidence.

Related detail sits in our note on who is licensed when a vendor ships Oracle Java inside its product.

Fix the gap at renewal rather than at audit.

Add a clause requiring the vendor to warrant that all third-party runtimes redistributed within the product are licensed for customer production use, to notify you within 30 days of any change in that status, and to indemnify against third-party licensing claims arising from bundled components.

Vendors resist the indemnity and concede the warranty and notification obligations more often than buyers expect, because those cost them nothing if their paperwork is genuinely in order.

This is the single most common breach we find in middleware audits, and it is almost never deliberate.

Oracle's own Fusion Middleware licensing documentation states that Java SE inside WebLogic Suite is restricted for use with WebLogic Server, Oracle Containers for J2EE (OC4J), and Coherence.

And that Java SE is included for the sole purpose of enabling client applications to access WebLogic Suite components.

The moment a development team deploys a custom EAR or WAR onto a domain that also hosts a bundled Oracle application, that restricted grant is no longer being honored on that domain.

Two things break at once: the bundled Java SE entitlement stops covering the JVM, because the JVM is now running something outside the permitted list.

And the restricted-use WebLogic entitlement that came with the application stops covering the server, because a full-use WebLogic license is required for the entire domain, not the individual deployment.

The same logic applies to application-bundled Java shipped with E-Business Suite, PeopleSoft, and JD Edwards, where the grant is version-locked: patch the JVM past the version the application ships and certifies, and the restricted grant no longer describes what is installed.

Oracle knows exactly where to look. Middleware audits routinely include deep inspection of domain configuration files, deployment descriptors, and application server logs for non-bundled deployments, and that inspection is cheap for them because the evidence sits in plain text on the filesystem.

The defensive control is architectural, not contractual. Bundled Oracle application domains should be isolated by policy: no custom deployments, no shared managed servers, no consolidation of a departmental app onto the ERP domain because there was spare capacity.

Enforce this in change management with a named approver, and re-verify quarterly by exporting the deployment list from each domain and comparing it against the list of applications the bundled entitlement actually covers.

If you have already crossed the line, remediate before you disclose, and read our note on who is licensed when a vendor ships Oracle Java inside its product before you accept any Oracle characterization of the exposure.

Five patterns repeat across almost every Java discovery and audit-defense engagement we run. First, download telemetry is the opening exhibit.

Oracle does not begin with a scan, it begins with a list of downloads tied to your corporate domains and IP ranges, and that record persists even where the installation was removed months later. Second, auto-update pipelines silently convert entitlement.

An appliance or agent that patches itself from Oracle's servers moves an estate from NFTC to OTN one unattended update at a time, which is precisely why the October 2026 Critical Patch Update on JDK 21 will convert quietly maintained devices into paid installs without anyone approving a purchase.

Third, private JREs inside vendor application directories evade registry-based scans. Tools that inventory installed programs miss a JRE unpacked into a product folder, which is where monitoring agents, backup consoles, and appliance management interfaces habitually put it.

Fourth, legacy Java SE Advanced perpetual holdings provide audit cover but earn no credit. They are genuinely useful evidence that historic use was licensed, and they are worth nothing as a discount against the subscription rate, so do not let anyone in finance treat them as a trade-in.

Fifth, there is no separate 22 percent support line on the Universal Subscription: the rate is all-in, and budgets that add a support percentage on top are double-counting by roughly a fifth.

In our experience the second and third patterns account for most of the surprise findings, and the third is the one that turns a defensible position into an indefensible one, because you cannot argue a JRE was never used when the vendor's own product requires it to start.

Test your assumptions against the employee band table where one employee is worth $269,874 before you commit to a headcount figure.

Related advisory: the full topic guide.

Does a Java runtime bundled inside a network appliance need an Oracle subscription?

It depends entirely on whether the appliance vendor holds a redistribution or OEM agreement with Oracle that covers your production use. If it does, the vendor is licensed and you are not exposed.

If it does not, and the binary is Oracle JDK or JRE 8u211 or later, or any Oracle Java 11 or later release used in production, you carry the exposure and it is priced on your total employee count, not on the appliance.

Get the answer in writing from the vendor, naming the specific product version and JRE version.

How much does one hidden Oracle JRE actually cost?

Under the Java SE Universal Subscription, price is set by employee count, not by installation count. A 5,000-employee organization pays roughly $630,000 a year at list whether Oracle Java runs on one appliance or on 400 servers.

Oracle's own price list example shows a 28,000-employee company paying $2,268,000 a year. There is no de minimis exception, which is why a single undiscovered install is a full-scope commercial event.

What changes for Oracle Java in October 2026?

All JDK 21 updates through and including September 2026 are available under the No-Fee Terms and Conditions license.

Beginning with the October 2026 Critical Patch Update, Oracle plans to publish JDK 21 updates under the Java SE OTN license, which permits development, testing, prototyping and demonstration but not production use. GraalVM for JDK 21 moves to its OTN equivalent on the same CPU.

Any appliance or server that auto-patches past that date moves from free to licensed without a human decision.

Am I already entitled to Java through WebLogic or E-Business Suite?

Partly, and only for a restricted purpose. Oracle's Fusion Middleware licensing documentation states that Java SE included with WebLogic Suite is restricted to use with WebLogic Server, Oracle Containers for J2EE and Coherence.

Enterprise applications such as E-Business Suite, PeopleSoft and JD Edwards include a restricted-use Java SE license limited to the version required to run that application. Coherence is the notable exception, carrying a full-use Java SE grant.

Using bundled Java for general purposes, or swapping in a different Java version, falls outside the grant.

Why does deploying a custom application on a WebLogic domain break the license?

The Java and WebLogic rights bundled with an Oracle application are restricted to running that application. The moment a custom EAR or WAR runs on the same domain, the deployment is no longer restricted-use and a full WebLogic license is required for the entire domain, not just the custom component.

Oracle middleware audits routinely include deep inspection of WebLogic domains specifically to find non-bundled deployments, so this is a discovered breach rather than a theoretical one.

Can Oracle prove I used Java if I have already removed the installs?

Yes, in practice. Downloading patches or installers from Oracle creates a record that Oracle Java was obtained and used, and that download telemetry, tied to corporate domains and IP ranges, is the standard opening exhibit in a Java audit.

Removing binaries after the fact does not remove that evidence. This is why discovery has to cover what your organization downloaded, not only what is currently installed and running.

Does a credible OpenJDK migration plan actually reduce the price?

It does, measurably.

Benchmark data across more than 80 contracts shows organizations presenting a credible OpenJDK migration plan achieving 28 to 44 percent price reductions, against negotiated rates of roughly $9.50 to $12.80 per employee per month for organizations in the 1,000 to 10,000 employee range.

The plan has to be specific: named target distribution such as Adoptium, Corretto or Zulu, application inventory, and a dated cutover schedule. A stated intention with no schedule is not leverage.