Extended Support for End-of-Life Open Source Software

End-of-life (EOL) software is a product or version that its vendor or maintainers no longer support: no more bug fixes, no more security patches, and usually no more help on community channels. It does not stop working on that date. What stops is the flow of fixes, so any vulnerability discovered afterwards stays unpatched unless someone else backports a fix. End of support and end of life are often used interchangeably; some vendors use end of support for the date fixes stop and end of life for full retirement.

Commercial vendors publish a lifecycle with dates and often sell paid extended support for older versions. Open source projects publish a support window per release line and then simply stop: PostgreSQL patches each major version for five years, Apache Kafka maintains only its three most recent release lines, and Node.js retires each long-term support line about three years after it ships. There is no vendor to buy more time from, which is why independent extended support and backported patches exist.

It is not illegal. It is usually a compliance problem in audited environments. PCI DSS v4.0.1 requirement 6.3.3 requires patches for critical vulnerabilities to be installed within one month of release, which an unpatched EOL version cannot meet, and requirement 12.3.4 requires hardware and software technologies to be reviewed at least once every 12 months, including the vendor's end-of-life plans and a management-approved plan to remediate outdated technologies. SOC 2 audits test vulnerability management against the AICPA Trust Services Criteria, which expect newly discovered vulnerabilities to be detected and acted on, and a version with known, unpatched CVEs is hard to square with that. A documented patch source and upgrade plan is what usually closes the finding.

Yes. Upstream projects stop publishing fixes, but a patch for a newer release can often be backported to the old line. OSSeva, AceMQ's patching platform, does this for Redis and Valkey, PostgreSQL 11 to 13, Kafka 2.8 to 3.7, ActiveMQ, GemFire and Geode, Spring Boot, Spring Framework, Spring Security, Apache Tomcat, Node.js and Apache Pulsar. For RabbitMQ 3.8.x to 3.13.x, AceMQ's Extended LTS support provides backported security patches.

Extended support is a paid continuation of security patches and technical support for a version after its standard support has ended. Commercial vendors sell it for their own products. For open source, it comes from independent providers who backport fixes and support the old version, as OSSeva and AceMQ do. It is meant to cover the time between end of life and a completed upgrade, not to replace the upgrade.

Third-party support is support from a company other than the original vendor or project. For commercial software it usually replaces the vendor's maintenance contract. For open source it is often the only commercial option, because the project itself sells nothing. A good third-party provider covers the version you run, responds under a written SLA and can produce patches, not only advice. AceMQ is a third-party support provider for open source infrastructure, and OSSeva is its patching arm.

Technically, as long as it runs. Safely, as long as someone is patching it and you have a plan to leave. With backported patches and support in place, the right answer is the time the upgrade really needs, which is longer when it touches client libraries, drivers or a framework major version, and should be agreed as an end date up front. Without patches, every month on an EOL version adds known, unfixed vulnerabilities, and the upgrade gets harder as the gap to the current release widens.

Three. Upgrade to a maintained release, which is the right end state but often takes longer than the audit or the change calendar allows. Buy extended support with backported patches, which keeps the version secure while the upgrade is done properly. Or move to third-party support for the technology as a whole. Accepting the risk with no patches is a fourth option that many regulated organizations cannot choose. Many teams combine the first two.