Every Oracle Java install that has not been affirmatively disconnected quietly pings Oracle's update servers, and Oracle keeps that record. This page explains what those check-ins reveal, why long-running installs convert to paid liability one automated update at a time, and exactly what to disable before the letter arrives.
Every Oracle Java install that has not been affirmatively disconnected quietly pings Oracle's update servers, and Oracle keeps that record. This page explains what those check-ins reveal, why long-running installs convert to paid liability one automated update at a time, and exactly what to disable before the letter arrives.
Two separate data streams reach Oracle, and buyers routinely confuse them. The first is the download log, which records who pulled a binary. The second, and the one this page is about, is the recurring update check-in that a live install performs on its own schedule. Per reporting from Mondaq (April 23, 2026), Oracle logs the automatic update check-ins made by every installed copy of Oracle Java that has not been affirmatively disconnected from Oracle's servers. That is a distinct evidence source from the download record, and it keeps producing signal for as long as the install remains connected.
The auto-update feature installs a persistent component. Documentation for the Java Auto Updater confirms that each time Java is installed, an Auto Updater component is placed on the machine and started at every reboot. Legacy Oracle JRE installs, especially those predating 2019, carry this behavior by default. When those installs request an update, Oracle can see the source IP or machine reaching its update servers, which effectively confirms that Oracle software is running inside your environment. The Java Control Panel auto-update setting and any manual 'check for updates' click produce the same signal.
The practical point for a licensing negotiation is simple. A download log tells Oracle you once fetched a file. A check-in tells Oracle the software is installed, alive, and still connected today. The second is far harder to explain away as a discarded test. If you have not yet mapped this exposure, start with finding your Oracle Java installs before Oracle points them out.
A download says you touched the file once. A check-in says the software is installed, alive, and still connected to Oracle today.
Oracle does not need a fresh audit to build a picture. Per Mondaq (April 23, 2026), three years of accumulated telemetry, cross-referenced against whatever friendly outreach emails extract from the company directly, now functions as a usable audit foundation. The companies receiving formal letters in 2026 are not chosen at random. They are chosen because the telemetry already points at them.
On the download side, Oracle tracks IP addresses, corporate domain associations, download timestamps, and whatever account information was used at download. Oracle Licensing Experts (September 1, 2025) illustrate the resulting narrative: 'Between 2019 and 2024, someone from yourcompany.com downloaded Java 8 updates 211, 221, 241, and Java 11. Oracle account used: john.doe@yourcompany.com.' Layer a live update check-in on top of that history and Oracle can argue not only that Java entered your environment, but that it is still running now.
The evidentiary consequence is a burden shift. Even where downloads were genuine tests, Oracle assumes Java is in production unless you prove otherwise. That is why the download record and the check-in record deserve separate scrutiny. We cover the download side in detail in what Oracle's Java download logs actually reveal about you and the attribution problem in how one developer's Java download can implicate the whole company.
| Signal source | What Oracle records | What it proves | Buyer difficulty to rebut |
|---|---|---|---|
| Download log | IP, corporate domain, timestamp, java.com account | A binary was fetched from a domain tied to you | Moderate. Can be framed as testing |
| Update check-in | Source IP or machine pinging update servers | An install exists and is currently connected | High. Implies live, ongoing use |
| Java Management Service (JMS) | Detailed inventory of installs and usage you volunteered | Exact estate footprint | Very high. Self-reported |
| Outreach email replies | Employee counts, environment details you disclosed | Metric inputs and confirmation | High. Your own words |
Note the escalating difficulty. The single most damaging thing you can do is add a self-reported layer on top. Enabling the Java Management Service turns Oracle's inference into your confession. We treat that separately in Java Management Service: why enabling it is a volunteer audit.
The reason check-ins are dangerous in 2026, and not merely a privacy annoyance, is the interaction between auto-update and Oracle's No Fee Terms and Conditions (NFTC) license. A long-running install with auto-update enabled pulls new builds automatically. Some of those builds cross a licensing boundary that the install neither knows nor cares about.
The NFTC license for Oracle JDK 17 expired in September 2024, with build 17.0.12 (July 2024) the last free update, per BellSoft (April 28, 2026). Oracle JDK 21 reaches the same cliff on September 16, 2026, with the last free update distributed in July 2026, per Azul (April 27, 2026). After each cliff, per Oracle Java Licensing (May 25, 2026), all updates including security patches move to paid subscription terms.
Redress Compliance (December 19, 2025) states the link plainly: JDK 17 left free terms in October 2024 at update 17.0.13, JDK 21 leaves in September 2026, and patch pipelines pull the post-cliff updates silently. The estate that does not manage its Java versions is buying subscriptions one automated update at a time. That is the trap. An unmanaged auto-updater does not stop at the last free build. It fetches the first paid one, and at that moment your organization is technically consuming a licensable update it never agreed to buy.
The estate that does not manage its Java versions is buying subscriptions one automated update at a time.
| Release | Last free NFTC update | Cliff date | Status after cliff |
|---|---|---|---|
| Oracle JDK 17 | 17.0.12 (July 2024) | September / October 2024 | Paid subscription for all updates |
| Oracle JDK 21 | July 2026 build | September 16, 2026 | Paid subscription including security patches |
Before you assume the cliff even applies to you, confirm what is actually installed. Many estates carry OpenJDK builds that are never subject to Oracle's terms, and the distinction decides whether you owe anything at all. Work through Oracle JDK vs OpenJDK: how to tell which one is actually installed before you engage Oracle on any number.
The check-in exposure matters so much because of how Oracle prices Java. The Java SE Universal Subscription, introduced January 2023 to replace the Named User Plus and Processor metrics that ran 2019 through 2022, counts people, not installs or processors. Per Redress Compliance, the definition reaches every full-time and part-time employee, every temporary worker, and the contractors, agents, and consultants supporting internal business operations. It does not matter how many of them ever touch Java. One qualifying install can price the entire headcount.
So a live check-in from one legacy JRE on one server is not a one-server problem. It is Oracle's hook to price your whole workforce. The 2026 list ladder runs as follows, per Redress Compliance (June 9, 2026) and Oracle's own FAQ.
| Employee band | List price per employee per month (USD) |
|---|---|
| 1 to 999 | 15.00 |
| 1,000 to 2,999 | 12.00 |
| 3,000 to 9,999 | 10.50 |
| 40,000 to 49,999 | 5.25 (published floor) |
| 50,000+ | No published rate |
The scale is not hypothetical. Oracle's own price list worked example prices a 28,000-employee company (23,000 staff plus 5,000 contractors) at 28,000 x USD 6.75 x 12 = USD 2,268,000 per year. Redress Compliance (December 19, 2025) shows a 5,000-employee company running Java on 40 servers paying USD 630,000 per year at list, which is USD 15,750 per server, and a 100-server estate at the same headcount paying exactly the same. Server count is irrelevant. Headcount is everything. For the full breakdown see what Oracle Java really costs in 2026.
When Oracle converts telemetry into an audit finding, the opening number is almost always inflated. Per Redress Compliance (June 9, 2026), Oracle's first finding priced 100 percent of employees even where Java ran on 10 to 20 percent of machines, and download evidence from java.com accounts drove 30 to 50 percent of the claimed exposure. The check-in data feeds the same overreach: proof that installs exist becomes an assumption that the whole payroll must be licensed.
That opening number is negotiable, and heavily. The same analysis records settlements landing 40 to 70 percent below the opening figure once migration to OpenJDK was shown as credible. The leverage is not in disputing that check-ins occurred. Oracle has the logs. The leverage is in reframing scope from headcount to actual need, and in demonstrating a concrete path off Oracle binaries. The Australian bank case is the template: it faced an employee-metric bill across its entire workforce, mapped real use, migrated to OpenJDK, and cut the exposure. See Oracle Java at an Australian bank, from per employee to per need.
Two cost mechanics sharpen the urgency. Backdated licenses carry 22 percent support fees that escalate at 8 percent annually, so the longer a converted install sits unaddressed, the more compounding liability attaches. And enforcement clusters at Oracle's fiscal year-end. Q4 (March to May, fiscal year ends May 31) is the negotiating window where stalled settlements suddenly move. Understand the full sequence in what to expect in an Oracle Java audit, and note the harder posture Oracle now takes under its rebranded license team in GLAS vs LMS: what changed in Java enforcement.
The buyer-side instruction is unambiguous. Legacy Oracle JRE installs that phone home for updates create telemetry Oracle can use, so disable auto-update functionality on any Oracle JRE that remains in your environment. Do this before you download anything else, before you reply to any outreach email, and before you consider JMS (which you should not enable).
Disabling auto-update does not erase the check-ins already logged. What it does is stop the meter, cap the evidence at its current state, and remove the argument that the install is live and consuming updates today. Combine it with a broader footprint reduction program, covered in reducing your detectable Oracle Java footprint the legitimate way.
First, inventory every Oracle Java install and confirm which are Oracle JDK versus OpenJDK, because only the Oracle binaries carry license exposure. Second, disable auto-update everywhere the moment you find an Oracle install, using the registry and Control Panel methods above. Third, freeze versions on anything near a cliff and route your patch pipeline away from post-cliff Oracle builds. Fourth, do not enable JMS and do not answer employee-count questions in an outreach email without advice, because both convert Oracle's inference into your admission.
If a letter has already arrived, the check-in logs are Oracle's leverage and the credible OpenJDK migration is yours. Opening claims in this space overprice by 40 to 70 percent, and the year-end Q4 window is when realistic settlements close. Move deliberately, cap the evidence, and build the migration story before you negotiate scope.
For the full detection picture across download logs, telemetry, and JMS, start at the pillar: how Oracle detects unlicensed Java.
Yes. The update check-in reaches Oracle's servers from the machine or its outbound IP, which confirms an Oracle Java install exists and is currently connected. That is stronger evidence than a download log, because a download only proves a file was once fetched, while a check-in implies the software is live and in use today.
A download log records IP, corporate domain, timestamp, and the java.com account used to fetch a binary. A check-in is the recurring ping a live install makes to Oracle's update servers on its own schedule. Download evidence is easier to frame as testing; check-in evidence implies ongoing production use and is much harder to rebut.
No. Check-ins already logged remain on Oracle's side. Disabling auto-update stops new check-ins, caps the evidence at its current state, and removes the argument that the install is still consuming updates. It is a containment step, not an erasure step, and it should be paired with a footprint reduction and migration plan.
Since January 2023 Oracle prices Java by the Java SE Universal Subscription, an employee metric covering all full-time, part-time, temporary staff, contractors, agents, and consultants. It does not matter how many touch Java. One qualifying install lets Oracle price the whole headcount, which is why a single legacy JRE phoning home is a payroll-scale liability, not a single-server problem.
Oracle's free NFTC license expires per release. JDK 17 left free terms in late 2024 and JDK 21 leaves in September 2026, after which all updates including security patches become paid. An unmanaged auto-updater keeps pulling builds past that boundary, so the estate buys subscriptions one automated update at a time without any human decision.
Market experience from Redress Compliance shows opening findings price 100 percent of employees even where Java runs on 10 to 20 percent of machines, and settlements land 40 to 70 percent below the opening figure once a credible OpenJDK migration is shown. The leverage is not disputing the check-ins but reframing scope from headcount to actual need.
Oracle prices Fusion ERP Cloud per employee, not per user, which inflates true cost. The buyer side guide to module economics and the modernization discount.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
