How to Build a Software EOL Management Program (That Survives an Audit)
Most of what we publish answers one question: is this specific version dead? This article answers the harder one that follows: what do you do about all of it? Because the honest pattern across everything we have documented this year — the 2026 mid-year report counted 178 vulnerabilities added to CISA's actively-exploited catalog in seven months, 29 of them at least three years old — is that end-of-life software is not a series of incidents. It is a permanent condition of running software, and the organizations that handle it well do not handle it heroically. They run a software end-of-life management process: a standing program with an inventory, a dating source, a ranking method, decision rules, gates, and evidence.
This is that program, in six steps. It is deliberately built on our own published research — the discovery patterns, the drift study, the risk model, the pricing reference, the compliance analyses — so every step comes with receipts you can follow and check. If you want the one-page version to hand your team, the whole thing condenses into a policy document, and we made that too:
Step 1 — Inventory: find where EOL software actually hides
Every EOL program that fails, fails here first — not because organizations have no inventory, but because they have one inventory, and end-of-life software concentrates precisely in the places single inventories do not reach. Across our deadline coverage, the same six hiding places keep producing the machines nobody knew they had:
- Appliances and vendor VMs. Firewall managers, NAS units, badge systems, monitoring collectors — the OS inside an appliance is invisible unless the vendor tells you, and many never will. Our Debian 11 countdown documented this as the largest class of at-risk Bullseye installs before the August 31, 2026 wall.
- Container base images. A
FROM debian:bullseyeline keeps pulling and building forever after patches stop — every rebuild just bakes in the same aging package set. This is the FROM-line audit problem, and it hides EOL operating systems inside images your scanner calls application artifacts. - CI runners and build agents. Imaged once, cloned many times, updated never — the classic home of a golden image from years ago still doing production-adjacent work today.
- The pinned server. The box that stayed behind because some application "needed testing" before the upgrade — a task that has been six weeks away for three years.
- Managed cloud services. An RDS database or EKS cluster past its version's standard support does not appear in any on-prem inventory — it appears on the invoice, because AWS enrolls it in paid extended support automatically. Per our pricing reference, the bill is often the notification.
- The management tooling itself. The console that patches your fleet is also software with a lifecycle. Our MSP patch-billing audit covers the August 2026 N-able N-central case — an actively exploited RMM console whose fix only installed on supported versions.
Sources: your CMDB and SBOMs where they exist, dependency files everywhere else — the stack scanner turns requirements.txt, package.json, Gemfile, or composer.json into a lifecycle report directly, and the legacy software inventory guide covers assembling the rest.
One more trap before you trust the list you build: a version string is not a support status. Our product research keeps finding products where the number teams report answers the wrong question:
- "We run RHEL 8.6" sounds supported, because RHEL 8 is. But Red Hat patches only the newest minor release in each major — per our RHEL minor-version analysis, a stock 8.6 box has received zero patches since November 9, 2022 unless it carried a paid EUS entitlement.
- "We run AIX 7.3" is not a status either: AIX support expires per Technology Level — the second field of
oslevel -s— and per our AIX analysis, 7.3 TL2 stops receiving fixes November 30, 2026 while 7.3 TL4 runs to the end of 2028. Same release, two years apart. - IBM MQ estates need
dspmqveron every host: per our MQ analysis, anything reporting 9.2 or lower has been in paid-extension-or-unsupported territory since September 30, 2025. - GitLab has no long-lived versions at all — per our GitLab 19.0 coverage, each release's security-patch window is about 91 days wide, so "which GitLab?" has to be re-asked quarterly, not annually.
Step 2 — Map to lifecycle truth: dates are claims, not facts
Once you know what you run, every entry needs a date — and here is the finding that shapes this entire step: the dates move. In July 2026 we cross-checked 54 products against their vendors' official lifecycle documentation for the EOL dates drift study. The results: 33 verified exactly, 12 dates needed correction, 7 products turned out to have no vendor-published per-version dates at all (every calendar date in circulation for them is a downstream derivation), and 3 needed structural review. All six upstream correction PRs we filed from that audit were merged by the endoflife.date maintainers on July 21, 2026 — so the ecosystem inherited the fixes, not just our pages.
And 2026 kept proving the point after the study shipped. Per the mid-year report: Microsoft moved the Windows 10 consumer ESU deadline a full year — to October 12, 2027 — on June 25, 2026, announced via an editor's note appended to an existing blog post. AWS edited its Lambda runtime deprecation schedule in place, shifting block-function-create to February 1, 2027 — so well-read third-party guides that faithfully quoted the earlier schedule became silently wrong. A spreadsheet of EOL dates exported last year contains every revision, slip, and correction that happened since, and shows none of them.
checker-db.json, is regenerated from lifecycle data at every build), script recurring checks through the API (free tier: 500 requests/day across 480+ products), and put the products you run on EOL Watch so approaching — and moving — dates come to you. Our accuracy page documents what is vendor-verified and publishes every correction with its source.
Step 3 — Prioritize: rank by risk, not by outrage
A real inventory mapped to real dates usually surfaces more EOL findings than any team can fix this quarter — which is where programs stall unless the ranking is mechanical. Use a scoring model, and use it consistently. Ours is published in full at /risk-score and unpacked in the Risk Score explainer; the method matters more than the brand:
- EOL recency — up to 40 points. Days since (or until) the end-of-life date. Unpatched exposure compounds: years past EOL outweigh weeks.
- Attack surface — up to 30 points. How widely deployed and network-exposed the category is. An internet-facing runtime outranks a niche desktop utility of the same age.
- CISA KEV exposure — up to 20 points. Whether vulnerabilities being exploited in the wild right now intersect the product.
- Extended-support availability — up to 10 points. A commercial patch stream reduces risk; no path at all means every future CVE is permanent.
Every score is recalculated at every site build, so the ranking can never drift from the data behind it. Two products that died the same day can score very differently — and that difference is your work order.
Above the scoring model sits a tier no formula should be allowed to soften: software that is simultaneously actively exploited (in CISA's KEV catalog), past end of life, and confirmed by the vendor's own advisory to be getting no fix, ever. We maintain that list — human-verified, entry by entry — as the Exploited & Unpatchable feed. Three current entries show what the worst case looks like in practice: JetBrains TeamCity's CVE-2026-63077 (KEV-listed August 5, 2026 — the fix exists only in the two current lines, leaving nine EOL release lines permanently exposed to unauthenticated RCE); FortiOS CVE-2025-68686, where Fortinet's advisory lists all 7.0 and 6.4 versions as affected and gives their only remediation as "Migrate to a fixed release"; and Roundcube's CVE-2025-49113, fixed only in 1.5.10 and 1.6.11, leaving the EOL 1.2–1.4 lines inside NVD's affected range with no patch ever coming. Systems in this tier jump every queue — the decision in Step 4 is not whether to act on them, only which exit to take.
Step 4 — Decide per system: migrate, bridge, or accept — in writing
For every finding, there are exactly three legitimate outcomes, and one illegitimate one (silence). The three: migrate to a supported version, buy extended support so patches keep flowing from someone who still produces them, or document the acceptance — a recorded decision with a named approver, compensating controls, and an expiry date, not a shrug. Our incident-response guide walks the single-system version of this decision; at program scale, the question that picks between them is the horizon question:
Price the bridge honestly, because the pricing is designed to escalate. Per our cross-vendor pricing reference — every figure traced to a vendor price page or our verified coverage — Windows 10 commercial ESU runs $61 per device in year one and doubles each year (about $427 per device for the full three-year run); AWS bills EKS extended support at 6x the standard rate and RDS Extended Support doubles per vCPU-hour in year three; Ubuntu Pro lists at $25 per desktop and $500 per server per year; and at the other extreme Oracle waives the Java SE 17 Extended Support fee entirely through September 2029. Some products have no extended support at any price — SharePoint 2016/2019 got no ESU program at all. When the answer is a third-party ELS vendor, most enterprise pricing is quote-based; our matching service returns the real options for your product, including "no vendor covers this" when that is the truth.
Whichever exit you take, the paper matters as much as the decision: a migration has a date, a bridge has a contract, an acceptance has a signature. That paper is what Step 6 turns into audit evidence.
Step 5 — Gate: stop new EOL debt at the door
A program that only remediates is a treadmill. The compounding wins come from three gates that keep new end-of-life debt from entering the estate at all:
The procurement gate. Require published end-of-life dates as a condition of purchase — if a vendor cannot tell you when support ends, they are telling you something. This ask is getting easier to standardize: per our OpenEoX analysis, an OASIS technical committee including Cisco, Microsoft, Oracle, Red Hat, IBM, the NSA and CISA (which co-chairs it) is standardizing machine-readable lifecycle disclosure, with mandatory end_of_life and end_of_security_support fields in the draft Core Schema. Procurement language that asks for "lifecycle dates in a machine-readable format, OpenEoX-compatible where available" is both reasonable today and future-proof.
The CI gate. Make the pipeline refuse what the policy forbids. Our integrations ship both halves: the EOL Runtime Check GitHub Action scans version pins (.nvmrc, .python-version, go.mod, Dockerfile FROM lines, package.json engines and more) and fails the build on EOL runtimes with annotations, and the VS Code extension red-underlines EOL version pins as they are typed — moving the gate from the pipeline to the editor. Both check live data through the API, so the gate inherits corrections instead of drift.
The base-image rule. Every Dockerfile FROM line names an OS with a support clock; rebase on the same schedule as your servers, and treat a base image past its OS's EOL date as a build failure, not a footnote. Per the Debian 11 countdown, docker build keeps succeeding forever after the patches stop — success is exactly what it looks like.
Step 6 — Evidence: the audit map
Everything above produces artifacts — an inventory, a dated mapping, a ranked register, signed decisions, gate configs. This step is knowing which framework asks for which artifact, because unsupported software stopped being only a security question some time ago. Each row below links our full analysis of that framework, and each claim matches it:
| Framework | Who it binds | What it demands about unsupported software | Key dates | Our analysis |
|---|---|---|---|---|
| EU CRA Regulation (EU) 2024/2847 |
Manufacturers placing products with digital elements on the EU market, wherever based | Handle vulnerabilities and provide security updates for a declared support period, and know and document product components (Art. 13) — a component nobody patches undermines that promise. Report actively exploited vulnerabilities (Art. 14). Penalties for the most serious infringements up to €15M or 2.5% of global turnover. | In force Dec 10, 2024; Art. 14 reporting applies Sep 11, 2026; main obligations Dec 11, 2027 | The CRA's EOL problem |
| NIS2 Directive (EU) 2022/2555 |
"Essential" and "important" entities in listed sectors, via national implementing laws | Risk-management measures including vulnerability handling — structurally impossible for a component with no patch pipeline. Staged incident reporting: early warning in 24h, notification in 72h, final report in a month. Fines for essential entities up to €10M or 2% of global turnover, and management bodies carry personal accountability. | Obligations arrive through national transposition — check each member state where you operate | NIS2 and EOL software |
| DORA Regulation (EU) 2022/2554 |
EU financial entities (banks, insurers, investment firms, payment institutions) plus critical ICT third-party providers | The first EU-wide law naming legacy ICT systems explicitly as a risk category to identify and account for — an EOL component is its purest form. Extended support counts as a documented compensating control, not an exemption: the framework still needs the migration plan and residual risk. | In force Jan 16, 2023; applies since Jan 17, 2025 — current law, not a future deadline | DORA and legacy ICT |
| CISA BOD 26-04 & 26-02 US federal directives |
Federal civilian executive branch agencies; a public blueprint auditors and insurers increasingly borrow | 26-04: remediate by composite risk, not severity score — the top tier in 3 calendar days; for EOL software, patching is permanently unavailable, so migration or paid support are the only exits. 26-02: end-of-support edge devices identified and remediated against CISA's EOS Edge Device List — EOS devices should not reside on federal networks at all. | 26-02 issued Feb 5, 2026 (three-month remediation window); 26-04 issued Jun 10, 2026, superseding BOD 22-01 and 19-02 | The 2026 directives, plainly |
| PCI DSS 4.0.1 Req. 12.3.4 and 6.3.3 |
Any entity storing, processing, or transmitting cardholder data | Review all in-scope hardware and software at least every 12 months to confirm it still receives vendor security fixes, document vendor EOL announcements, and maintain a remediation plan for outdated technology approved by senior management (12.3.4). Protect components from known vulnerabilities via timely patching (6.3.3). | 12.3.4 moved from best practice to mandatory March 31, 2025 — now fully assessed | Frameworks that require lifecycle tracking |
Notice what every row has in common: none of them are satisfied by being lucky. They are satisfied by artifacts — the inventory, the annual review, the ranked register, the approved plan, the signed acceptance. An auditor does not need to exploit anything to write up unsupported software; the vendor's published dates make the finding for them. A program that runs Steps 1–5 produces the evidence as a byproduct. That is the whole trick.
The program in one page
| Step | What it produces | Cadence |
|---|---|---|
| 1. Inventory — six hiding places, version-string traps checked | A versioned inventory that includes appliances, images, runners, cloud services, and tooling | Continuous; full sweep quarterly |
| 2. Lifecycle truth — map to a re-verifying source | Every entry dated, with drift caught automatically | Automated (API / EOL Watch) |
| 3. Prioritize — score by recency, surface, KEV, support availability | A ranked register; the exploited-and-unpatchable tier at the top | Recomputed as data changes |
| 4. Decide — migrate / bridge / accept, per system, in writing | Dated migrations, priced bridges, signed acceptances with expiry | Per finding; review quarterly |
| 5. Gate — procurement language, CI checks, base-image rules | New EOL debt blocked at the door | Standing controls |
| 6. Evidence — the audit map | Framework-ready artifacts, produced as a byproduct | Annual review minimum (PCI: every 12 months) |
Two ways to make this real this week. If you want to run it yourself: download the free EOL policy template — no signup, use and share freely — adapt the bracketed sections, and you have the written policy that Steps 1–6 execute. If you want the tooling-assisted path: the EOL management page lays out the track–score–plan–bridge loop with our free tools wired into each stage, and extended-support matching covers the bridging decisions you cannot migrate your way out of.
Frequently Asked Questions
What is a software end-of-life management process?
A software end-of-life management process is the repeatable loop an organization runs to keep unsupported software from accumulating unmanaged: inventory everything that runs, map each version to a verified end-of-life date, prioritize what is already past EOL by measurable risk, decide per system between migration, extended support, and documented risk acceptance, gate new EOL debt at procurement and CI, and keep the evidence that auditors ask for. It is a standing program rather than a one-time project, because support windows close every month and the dates themselves change — when we cross-checked 54 products against vendor documentation in July 2026, 12 dates needed correction.
How do I track end-of-life software across an organization?
Start from more than one inventory source, because EOL software hides where single sources do not look: appliances and vendor VMs, container base images, CI runners and build agents, pinned servers, managed cloud services, and the management tooling itself. Then check what you find against live lifecycle data rather than a copied spreadsheet — our checker covers 480+ products, the free API tier allows 500 requests per day for scripted checks, and the stack scanner turns dependency files into a lifecycle report. Re-verify on a schedule: EOL dates drift, and a frozen export silently inherits every revision that happens after it.
What should a software end-of-life policy include?
A workable end-of-life policy names an owner, requires a maintained inventory with versions, designates a verified source for lifecycle dates, defines a risk-ranking method for anything past or approaching EOL, sets the three allowed outcomes for an unsupported system — migrate, buy extended support, or accept the risk in writing with a named approver and an expiry date — and adds a procurement gate requiring published end-of-life dates before new software enters the estate. Our free EOL policy template covers all of these sections and requires no signup to download, use, or share.
How do you prioritize end-of-life software remediation?
Rank by measurable risk, not by age alone. The EOL Risk Score we publish for every tracked product weighs EOL recency at up to 40 points, attack surface at up to 30, CISA KEV exposure at up to 20, and extended-support availability at up to 10, recalculated at every site build. Above any scoring model sits the worst-case tier: software that is actively exploited per the CISA KEV catalog, past end of life, and confirmed by its vendor to be getting no fix — those systems are permanently vulnerable and jump every queue. Internet-facing systems and audit-scoped systems come next; everything else is sequenced by score.
Related
- Free EOL policy template — the written policy behind this program; no signup, use and share freely
- EOL Management: Track, Score, Plan, Bridge — the tooling-assisted loop for running the program
- My Software Is EOL — What Do I Do Now? — the single-system incident version of Step 4
- Is Your MSP Billing You to Patch Software That Has No Patches? — the outsourced-fleet version of Steps 1 and 6
- EOL Dates Drift — the 54-product verification study behind Step 2
- What Extended Support Actually Costs — the pricing reference behind Step 4
- Exploited & Unpatchable — the worst-case tier from Step 3, as a living feed