EOL support for open source, also sold as extended support or long-term support, is a paid service that keeps shipping security patches and bug fixes for a software version after its upstream project has stopped. The project declares the version end of life; the EOL support provider backports fixes for newly disclosed CVEs to that same version and delivers them as drop-in builds, so the system stays patched without an immediate upgrade.
“Long-term support” means two different things. An LTS release is a line the project itself maintains for longer than its other releases, and that support still ends on a published date. Third-party long-term support is what continues after that date, for the version you actually run.
The problem: open source software has a lifespan
Every open source project has a support lifecycle. For a period after initial release — typically 2–5 years depending on the project — the community releases new versions, patches security vulnerabilities, and fixes bugs. Then maintenance ends. The project reaches its end-of-life (EOL) date.
After that date, the upstream project stops releasing anything. The software still runs — but any newly discovered security vulnerabilities (CVEs) will not receive official patches. The version you're running becomes increasingly exposed as researchers find new attack vectors against code that will never be updated.
For an individual developer, this is manageable: upgrade to a newer version. For an enterprise running a deeply integrated middleware stack across hundreds of production systems, it's rarely that simple.
Why enterprises run EOL software
The instinct is to judge enterprises for running EOL software — why not just upgrade? The answer is almost always the same: the cost, risk, and runway required to upgrade a production system at scale is not trivial.
- —A RabbitMQ 3.8 cluster handling 100M messages/day cannot be upgraded in a weekend. The migration requires planning, staging, testing, cutover, and rollback plans.
- —Applications built on Spring Boot 2.7 may have dependencies that don't yet support Spring Boot 3.x — requiring an application-level migration, not just a runtime swap.
- —Kafka clusters running in ZooKeeper mode need a migration to KRaft before upgrading to current versions — a non-trivial architectural change.
- —Compliance deadlines are often the trigger for action — and those deadlines don't align neatly with upstream EOL dates.
Extended support exists precisely for this gap: the period between when the upstream community stops patching and when the enterprise is operationally ready to upgrade.
How extended open source support works
An extended support vendor takes on the responsibility of monitoring new CVEs against the covered technology version, developing patches, testing them, and delivering them to enterprise customers as signed builds.
The process for each covered CVE typically follows this pattern:
- 1
Vulnerability identified
The CVE is published or discovered in the wild against the covered version.
- 2
Impact analysis
The vendor assesses whether the vulnerability affects the specific version lines under contract and under what conditions.
- 3
Patch development
Engineers backport the fix to the covered version — maintaining API and behavioral compatibility so no application changes are required.
- 4
Testing and signing
The patch is tested against production-representative workloads and signed (typically GPG + Sigstore) for supply-chain verifiability.
- 5
Delivery and documentation
The patched build is delivered through the customer's artifact repository, with a remediation report suitable for auditors.
The key property: the application running on the patched runtime does not need to be changed. The binary is a drop-in replacement for the EOL version it patches.
Extended support vs. commercial distributions
Two approaches are commonly confused:
Commercial distribution
Confluent Platform, Broadcom Tanzu
A proprietary fork of the upstream project. You run the vendor's runtime, not community software. Proprietary APIs, connectors, and tooling may be introduced. Moving away from the distribution often requires a migration.
Extended support (backport model)
OSSeva, HeroDevs, TuxCare
Patches are applied to the upstream community codebase. You run real Apache-licensed software. No proprietary runtime, no new APIs, no lock-in. Exiting extended support is a straight upgrade to a newer community version.
The choice between these models often comes down to whether you want the vendor's ecosystem (connectors, management tooling, cloud services) or whether you want to preserve optionality — the ability to upgrade to the next community version without any migration friction.
Community support, commercial support, and EOL support are three different things
These get used interchangeably in procurement conversations and they are not the same product. The distinction decides who is obliged to fix your problem, and when.
| Model | Who fixes it | Which versions | Obligation |
|---|---|---|---|
| Community support | Volunteers and maintainers, at their discretion | The current release lines only | None. There is no contract and no response time. |
| Commercial vendor support | The vendor that sells the distribution | The versions that vendor chooses to build | Contractual, but scoped to their build and their lifecycle |
| EOL / extended support | A third party who backports fixes | The line you are on, after upstream stopped | Contractual, scoped to the versions you actually run |
The row that surprises people is the middle one. A commercial subscription does not automatically cover the version you are running — it covers the versions that vendor currently builds. Teams discover this at renewal, when the answer to “can you patch our 3.11 cluster?” turns out to be “upgrade to 4.x first”.
What “end of life” actually means, and what it does not
End of life is a maintenance decision, not a technical event. Nothing happens to the software on the date. It does not stop running, it does not degrade, and it does not announce itself. That is precisely why EOL versions persist in production for years: there is no failure to trigger a response.
What changes is that the project stops publishing fixes for that line. Advisories keep being disclosed — often against code paths that exist in your version — and the release that fixes them is one you are not running. The exposure grows quietly and monotonically from the date onward, which is the opposite of how most risk behaves and the reason it is consistently underestimated.
Three things typically surface it: a vulnerability scanner flagging the version string, an auditor asking how you patch it, or an incident. The first two are cheaper.
Who provides extended support after EOL?
Three kinds of supplier can patch open source after the upstream project stops, and they differ in which versions they will touch.
- The project itself, through an LTS programme. That covers only the LTS lines it names, and only until their published end dates.
- The vendor of a commercial distribution. That covers the versions the vendor builds, on the vendor's own lifecycle, which may not include the version you run.
- An independent extended support provider, which backports fixes to the upstream version you already run. OSSeva is one: Patch ships signed builds with backported CVE fixes for end-of-life versions, Assure adds compliance attestation and VEX statements, and Operate adds 24/7 managed operations with a 15-minute P1 response.
To compare providers by name, see the extended support vendor comparison and the alternatives to HeroDevs, TuxCare and OpenLogic. For the exact version lines OSSeva patches today, see supported versions.
What to look for in an extended support vendor
Specific version coverage
The vendor should publish a matrix of exactly which versions are covered — not a vague catalog claim. Ask specifically: is version 3.11.x of RabbitMQ covered? When was the last CVE patched against it?
Signed artifacts
Patches should be verifiable. Look for GPG signatures and ideally Sigstore cosign attestations on every delivered build. Unsigned patches from an unknown build pipeline are a supply-chain risk.
Audit documentation
For compliance purposes, you need more than a patched binary. You need a remediation report with CVE ID, CVSS score, affected versions, patch date, and testing summary — documents your auditor can attach to a finding.
Domain depth, not breadth
A vendor covering 400 technologies broadly may not have engineers who know the internals of your specific runtime deeply enough to backport a complex CVE correctly. Ask about the engineering background behind the coverage.
SLA and response commitment
How quickly will a critical CVE be patched after publication? What is the P1 SLA? For critical infrastructure, a 'best effort' commitment is not sufficient.