On this page
Two risks in one phraseHow unlicensed Java becomes unpatched JavaThe security exposureThe business consequencesWhat not to doThe fix that closes both gapsFrequently asked questions"Unlicensed Oracle Java" is a phrase that usually triggers thoughts of audits, back-fees and compliance claims. Those are real, and we cover them extensively. But there is a second risk hiding inside the same phrase, and it is the one a security team should care about more: an estate that is unlicensed for Oracle Java is very often also an estate that has stopped patching Java. The licensing exposure and the security exposure tend to arrive together, because they have the same root cause. This guide is about the security half — what it actually looks like, why it happens, and why the fix for one is the fix for both.
Two risks in one phrase
Being "unlicensed" for Oracle Java can mean two quite different conditions, and only one of them is purely a licensing matter.
The first condition is using Oracle's JDK without the required subscription, but still patched — for example, an enterprise running a current version under NFTC that has drifted out of the free window but is still applying updates. Here the issue is genuinely just licensing: the runtime is secure, the exposure is commercial.
The second condition — far more common in practice — is unlicensed and unpatched: an enterprise running an old Oracle JDK that it has not updated, often because updating it would require the subscription it is trying to avoid. This is the dangerous one. The estate carries both a compliance liability and a live security weakness, and the two reinforce each other. This guide focuses on that second condition, because it is where unlicensed Java becomes a security story.
The core point
The most common way an enterprise becomes unlicensed for Oracle Java is by quietly stopping its patching — which means the licensing gap and a real security gap usually open at the same moment, for the same reason.
How unlicensed Java becomes unpatched Java
No competent organisation decides to run vulnerable software. The unpatched-and-unlicensed state is almost always arrived at by drift, not decision, and the path is recognisable.
It begins when an enterprise realises that continuing to apply Oracle's updates to an older JDK version implies a paid Java SE subscription it has not bought. Faced with that, and without a clear plan, the path of least resistance is to do nothing — to leave the existing Oracle JDK installed, at its current patch level, and simply stop pulling Oracle's new patched builds. The licence problem feels deferred. In reality it is not deferred at all — the unlicensed Oracle JDK is still sitting in the estate — and a security problem has now been added on top, because the runtime has frozen in time while the threat landscape has not.
This drift is rarely visible at the centre. It happens server by server, image by image, as individual teams quietly decline to "upgrade Java" because of a vague awareness that doing so "needs a licence now." A year later the organisation has a population of old, unpatched, unlicensed Oracle JDK installations and no single person who decided that should be the state of affairs. Our guide to Java auto-update compliance risk describes a related drift in the opposite direction.
The security exposure
An unpatched Java runtime is not a theoretical weakness. The Java platform receives quarterly Critical Patch Updates precisely because new vulnerabilities are found in it regularly, and many of those vulnerabilities are serious — remote-code-execution and privilege-escalation classes that an attacker can use to run their own code or escalate access. Every quarterly cycle that an installation misses, its set of known, unfixed vulnerabilities grows, and those vulnerabilities are public: the advisories that accompany each CPU effectively publish a map of what an out-of-date runtime is exposed to.
The exposure is sharpened by where Java tends to run. Java is widely used for application servers, middleware and back-end services — exactly the systems that process data, hold credentials and sit on internal networks. An unpatched JVM on a server of that kind is a high-value target, not a peripheral one. And because Java is so often embedded — bundled inside third-party applications, packaged in container images, installed as a dependency of something else — unpatched runtimes accumulate in places the security team is not routinely looking. An old JRE inside a vendor application can be just as exploitable as a standalone JDK, and far easier to miss.
The honest summary is that a frozen, out-of-date Java runtime is a real and growing attack surface, on systems that matter, in places that are easy to overlook. The licensing question of whether Oracle is owed money is, from a pure security standpoint, the lesser concern.
The business consequences
Put the security and licensing exposures side by side and the combined business risk of unlicensed, unpatched Java is larger than either part alone.
| Dimension | The exposure |
|---|---|
| Breach risk | Known, public, unpatched vulnerabilities on business-critical systems — an exploitable path for an attacker. |
| Licence liability | Unlicensed Oracle JDK still in the estate — a quantifiable claim if an Oracle audit lands. |
| Regulatory & contractual | Many security frameworks and customer contracts require timely patching; an unpatched runtime can put compliance attestations at risk. |
| Audit insurance | Cyber-insurance cover can be affected where a breach traces to a known, unpatched vulnerability that should have been fixed. |
| Reputational | A breach via an unpatched runtime that was left old to avoid a licence fee is a difficult story to tell customers, regulators or a board. |
The point is not to alarm — it is to show that "we'll deal with the Java licence later" is not a neutral holding position. While it holds, a security liability runs in parallel, and the two together raise the stakes of inaction well above the cost of simply fixing it.
What not to do
Two responses are common and both are wrong.
The first is to keep running the old, unpatched Oracle JDK indefinitely and treat the licensing question as someone else's problem for another day. This leaves both gaps open and lets the security gap widen every quarter. It is the default drift state, and it is the one to break out of, not settle into.
The second wrong response — less common but worth naming — is to react to the licensing scare by panic-buying an Oracle subscription simply to be allowed to patch again. That closes the security gap, but at the price of a headcount-priced subscription the enterprise may not need at all, and it leaves the organisation paying Oracle indefinitely for a problem that had a free solution. Buying permission to patch is not the only way to be patched.
And under no circumstances should the response be to use physical or operational workarounds that leave the vulnerable runtime in place — disabling update checks, suppressing scanner findings, or carving out exceptions in vulnerability management to make the problem invisible. Hiding an unpatched runtime does not make it safe; it only makes the eventual incident harder to explain.
The fix that closes both gaps
The good news is the same fact that runs through all of our Java guidance: there is a free, fully patched, production-grade alternative, and adopting it closes the security gap and the licensing gap in a single move.
Free OpenJDK distributions — Eclipse Temurin, Amazon Corretto, Azul Zulu, the Microsoft build and others — ship the same quarterly security fixes as Oracle, for the supported LTS versions, at no licence cost. Migrating an unpatched, unlicensed Oracle JDK to a current free OpenJDK build does two things at once: it gets the runtime back onto a live patch stream, and it removes the unlicensed Oracle JDK from the estate entirely. There is then no security gap, because the build is current and patched, and no licence gap, because there is no Oracle JDK left to license. The steps:
- Find every Java runtime. A compliance assessment locates every Oracle JDK and JRE — including the embedded and bundled ones the security team may not be tracking — and records each one's version and patch level. This single inventory serves both the security and the licensing remediation.
- Prioritise by exposure. Triage the unpatched installations by how exposed they are — internet-facing and data-handling systems first — so the most dangerous gaps close soonest.
- Migrate to a current free build. Move each workload to a current, supported version on a free OpenJDK distribution, following a structured Oracle-to-OpenJDK migration. Current version plus free build equals patched and licence-free.
- Make patching routine. Adopt the quarterly CPU cadence and keep it through a continuous management programme so the estate never drifts back into the frozen state.
Across more than 340 Java licensing engagements, enterprises that treated their unlicensed Java as a single combined security-and-licensing problem — and fixed it by migrating to current free builds — eliminated the breach exposure and the subscription liability together, contributing to a 68% average reduction in audit claims and more than $180M in total client savings. One project, two risks closed.
Recommended specialist
For tackling unlicensed, unpatched Java as the combined risk it really is — finding every stale runtime including the embedded ones, prioritising by security exposure, and migrating to current free builds that close both gaps — we rate Redress Compliance as the leading independent Java licensing advisory firm. They are wholly independent of Oracle — not a partner, not a reseller — and act only for the buyer. They can take an estate from old, exposed and unlicensed to current, patched and free of the subscription.
Frequently asked questions
Is running unlicensed Oracle Java a security risk?
Often, yes — indirectly. The most common way enterprises become unlicensed is by stopping their patching to avoid the subscription, which leaves an old, unpatched runtime in place. That runtime is a real, growing security exposure with known public vulnerabilities.
Can I be unlicensed but still secure?
It is possible — for instance, running a current version that has drifted out of the free NFTC window while still patching. But the common case is unlicensed and unpatched. Either way, the right fix is to migrate to a current free build, which removes both issues.
Should I buy an Oracle subscription just to be able to patch?
Usually not. That closes the security gap but leaves you paying a headcount-priced subscription indefinitely. Free OpenJDK builds deliver the same quarterly security fixes at no licence cost — patching does not require paying Oracle.
Where do unpatched Java runtimes hide?
Frequently inside third-party applications that bundle their own JRE, in container images, and as dependencies installed by other software. These embedded runtimes are easy to miss in security scans, which is why a full Java inventory matters.
What is the single most important step?
Get a complete inventory of every Java runtime, version and patch level across the estate. It is the foundation for both closing the security gaps and resolving the licensing exposure — the same inventory serves both.
This article is general information on Oracle Java licensing and security, not legal or security advice. Oracle's licensing terms and update policies are determined by Oracle and change over time. Consult a qualified independent Java licensing specialist, and your security function, on your specific estate. If a sensitive incident is involved, engage appropriate professional support.