End-of-Life Software: The Vulnerabilities No Patch Will Fix
Most vulnerability programs are built around one assumption: when a flaw is found, the vendor will ship a fix and your job is to install it fast. End-of-life (EOL) software breaks that assumption. Once a product reaches end of support, new vulnerabilities keep being discovered, but the patches stop. Your scanner may still flag the CVE. There is just nothing to deploy.
This guide explains why unsupported technology deserves its own process, what CISA's 2026 directive on end-of-support edge devices teaches every organization, and how to manage the systems you cannot retire tomorrow.
What "end of life" actually means
Vendors use several terms (end of sale, end of support, end of life, end of service), and the dates differ by product. For security, the date that matters is the last day the vendor publishes security fixes. After that:
- New vulnerabilities still get found and disclosed.
- The vendor no longer releases patches for them.
- Your patch process has nothing to install, so the finding stays open indefinitely.
Windows 10 is the best-known example. Microsoft ended support on October 14, 2025: no more bug fixes, security fixes or technical support. Organizations can buy Extended Security Updates (ESU) for up to three years, which deliver critical and important security updates only. ESU buys time; it is not a strategy.
Why attackers like unsupported devices
In February 2026, CISA issued Binding Operational Directive 26-02, "Mitigating Risk From End-of-Support Edge Devices." It binds U.S. federal civilian agencies, but CISA encourages every network defender to follow it. Its reasoning applies far beyond government:
- Edge devices sit where attackers want to be. Firewalls, routers, switches, VPN gateways, load balancers and wireless access points face the internet and are often integrated with identity systems.
- They are especially exposed to new flaws. CISA says EOS devices are "especially vulnerable to cyber exploits targeting newly discovered, unpatched vulnerabilities," and that it is aware of widespread exploitation campaigns by advanced threat actors targeting them.
- They become a way in. In a joint alert, CISA, the FBI and the UK's NCSC warned that unsupported edge devices can serve as entry points into modern, supported environments.
The CISA Known Exploited Vulnerabilities (KEV) catalog shows what this looks like in practice. For some exploited flaws in end-of-life routers, the "required action" is not to patch, because there is no patch: it is to disconnect or discontinue the product. When Zyxel confirmed exploitation of flaws in legacy DSL routers in early 2025, its advice was to replace them with newer products. If you rely on KEV to prioritize, read our guide to the KEV catalog and remember that some entries can only be closed by removing the device.
What BOD 26-02 asks for, and why it is a good template
The directive turns a vague goal ("get rid of old stuff") into a sequence with deadlines:
| Timeline | Action |
|---|---|
| Immediately | Update supported devices that run end-of-support software to a supported version. |
| 3 months | Inventory every device on CISA's end-of-support list. |
| 12 months | Start decommissioning devices that were already unsupported when the directive was issued, and inventory those that will reach end of support within a year. |
| 18 months | Finish removing all identified end-of-support edge devices. |
| 24 months | Establish continuous discovery and a lifecycle process that retires devices before or as they reach end of support. |
You do not need to be a federal agency to borrow the structure: fix what can be fixed now, know what you have, set a removal date, and make the problem stop recurring.
A practical EOL program in six steps
1. Inventory software and firmware versions, not just hosts
You cannot track support dates for things you do not know you run. Your inventory needs product, version and location for operating systems, applications, network appliances and firmware. Devices that agents cannot reach, such as appliances and network gear, need agentless discovery; we covered the trade-offs in agent vs. agentless scanning.
2. Map each item to its support date
Record the vendor's end-of-support date for every product and version. Treat dates in the next 12 months as a planning trigger, not a surprise. PCI DSS 4.0 requirement 12.3.4 already expects this: hardware and software technologies must be reviewed at least once every 12 months, including whether they still receive security fixes promptly, and with a plan approved by senior management to remediate outdated technologies, including those with announced end-of-life plans.
3. Rank by exposure first
Not every unsupported system carries the same risk. An unsupported VPN gateway on the internet is a different problem from an isolated lab server. Start with internet-facing and edge devices, then systems that hold sensitive data or connect to identity. See why internet exposure changes priority.
4. Upgrade where you can, replace where you must
Many "EOL" findings are really old versions of supported products. Those are normal patching work, and they belong in your regular patch management process. True end-of-life hardware needs a funded replacement project with a date.
5. Contain what has to stay
Some systems cannot be replaced quickly: industrial controllers, medical equipment, a legacy application nobody can rewrite this year. For those, reduce exposure: remove internet access, segment the network, restrict who can reach management interfaces, monitor more closely, and consider paid extended support where it exists.
6. Make the exception explicit
Every unsupported system that stays should have an owner, a documented reason, compensating controls and an expiry date for the decision. That is a formal risk acceptance, not a forgotten ticket; our guide to vulnerability risk acceptance explains how to keep those decisions honest.
Frequently asked questions
Is a CVE on an unsupported product less urgent because there is no fix? No. It is often more urgent, because the only remediations are compensating controls or replacement, and both take longer than installing a patch.
Does paying for extended support solve the problem? It closes the gap for the period you pay for and for the updates the vendor chooses to ship. Use that time to migrate.
What about open source components that are no longer maintained? The same logic applies. A library or runtime with no active maintainer will not receive fixes for new vulnerabilities, so track it like any other end-of-life technology and plan the upgrade.
How priorIQ.ai helps
ScannerIQ combines native agents with agentless scanners across network zones to inventory endpoints, software and identities, and enriches findings with NVD, CISA KEV and EPSS. CloudIQ classifies which cloud resources are actually exposed to the internet. PriorIQ Core brings it together in a single software and device inventory, ranks open findings by real risk, and records exceptions in Risk Accepted & Decisions, so an unsupported system that has to stay is a tracked decision with an owner instead of an invisible one. Request a demo.