Oracle JDK 24 EOL September 16, 2025: 3-Month Action Plan

Oracle JDK 24: What Changes on September 16, 2025

On September 16, 2025, Oracle JDK 24 reaches its end of life (EOL). This is not a long-term support (LTS) release, so Oracle will stop providing all public updates, security patches, bug fixes, and technical support for this version on that date. The latest release in this line is 24.0.2, and no further updates will be issued.

After EOL, any unpatched vulnerability discovered in JDK 24 will remain unaddressed by Oracle. Your vendor service-level agreements (SLAs) for JDK 24 will end, and you can no longer rely on Oracle for incident response or hotfixes. For organizations that must keep JDK 24 running beyond September 16, proactive planning is essential.

Why a Full Migration May Not Be Feasible in 3 Months

Migrating an entire estate off JDK 24 before September 16 is a tight timeline. Application compatibility testing, regression runs, and deployment cycles for a new LTS JDK (such as JDK 21 or 17) typically take months. If you have custom or vendor-supplied applications that depend on JDK 24, you may not be able to complete the move before the cutoff.

That does not mean you should do nothing. Focus on the actions that will reduce risk, document your exposure, and ensure you have a path to continue receiving support after EOL.

Week-by-Week Action Checklist

Use the following plan to make the most of the remaining weeks. Adjust start dates based on your current progress.

Weeks 1–2: Discovery and Inventory

• Catalog every JDK 24 instance. Use scanning tools or manual checks to list all servers, containers, and developer workstations running JDK 24.
• Identify the owner and criticality of each application that runs on JDK 24. Classify as "must stay on 24," "can be migrated quickly," or "can be retired."
• Note the version (preferably 24.0.2) and any custom configurations (JVM flags, classpath dependencies).

Weeks 3–4: Isolate and Harden

• Move JDK 24 instances to isolated network segments (e.g., behind firewalls, with restricted inbound/outbound access).
• Apply strict access controls — only administrators who need to maintain the application should have login access.
• Disable unnecessary services (e.g., JMX, remote debugging) that can increase attack surface.
• Review and strengthen security configurations in the JVM (enable Security Manager if possible, restrict permissions).

Weeks 5–6: Document Exposure for Auditors and Insurers

• Create a risk register that lists each JDK 24 instance, its application, and the reason it cannot be migrated before EOL.
• Record compensating controls (network isolation, monitoring, incident response plans) that reduce the risk of an unpatched vulnerability.
• Share the documentation with your compliance, audit, and cyber-insurance teams. They may require evidence of active risk management.

Weeks 7–8: Secure a Support Contract for Day One

• Evaluate third-party support options for Oracle JDK 24. Third-party support providers can continue to deliver security patches, bug fixes, and technical support after the vendor’s EOL date.
• Engage a provider well before September 16 so that you have a signed agreement and onboarding instructions in place.
• Test the third-party support process — submit a mock request to confirm they can respond to your environment’s needs.

Weeks 9–12: Final Verification and Communication

• Confirm that all JDK 24 instances are identified and either migrated, isolated, or covered by a support contract.
• Run a final vulnerability scan on the isolated instances to establish a baseline.
• Notify all stakeholders (IT operations, security, business owners) that JDK 24 will be unsupported after September 16 and that documented controls are in place.

What Happens on September 16, 2025 and Beyond

On the EOL date, Oracle will cease all delivery of:

• Public and private security patches
• Bug fixes and enhancements
• Technical support incident handling
• SLAs for JDK 24

If a critical vulnerability is discovered after EOL, Oracle will not release a fix for JDK 24. Your only options are to:

• Migrate to a supported JDK version (LTS or newer)
• Apply virtual patches through a Web Application Firewall or runtime protection tool
• Rely on a third-party support provider that can create custom patches for JDK 24

Without a support contract, you assume full liability for any exploits that target unpatched JDK 24 installations.

How Third-Party Support Bridges the Gap

If you cannot migrate away from JDK 24 before September 16, a third-party maintenance provider can keep your environment safe and compliant. They will deliver:

• Security patches for critical vulnerabilities
• Bug fixes without waiting for a new JDK release
• Technical support with defined SLAs
• Continued access to an expert team familiar with legacy JDK versions

This approach buys you time to plan a careful migration to a future LTS release without the pressure of an immediate deadline.

Next Steps

Your action plan starts now. Inventory, isolate, document, and secure a support contract. We can help you evaluate third-party support options for Oracle JDK 24. Contact us to discuss a tailored transition plan.

For more details on Oracle’s lifecycle policies, visit the Oracle JDK lifecycle page.