When the Vendor Walks Away: Securing Software Nobody's Patching Anymore

Why organizations need a way to keep critical software secure when it can’t be replaced overnight.  

Legacy infrastructure rarely gets replaced on the schedule originally intended. A system may have been expected to run for five years and still be handling critical workloads a decade later because the application built around it is difficult to migrate, the dependencies are tightly coupled or the business cannot justify the disruption involved in replacing something that still works.

For IT and security teams, the situation can be difficult and labor intensive. They may know a system is approaching end-of-life (EOL), but knowing that a platform needs to be replaced does not make the migration any easier. Application changes, dependency testing, infrastructure updates and validation can take months, particularly when the system supports a critical or regulated operation.

The bigger security problem starts when the upstream vendor or maintainer stops providing security updates. The system may continue to run, but the normal way of addressing newly discovered vulnerabilities is gone. If migration is still underway, organizations need another way to reduce that exposure.

The Gap Between EOL and Replacement

For operating systems and major runtimes, organizations usually have advance notice before support ends. Vendors publish lifecycle dates years ahead, and the challenge is what happens when that date arrives and the migration is not finished.

An operating system upgrade, for example, can affect far more than the operating system itself. Applications may depend on specific libraries or runtime versions, infrastructure may rely on particular configurations, and internal processes may have been built around the existing environment. Changing one component can require changes elsewhere, followed by testing to make sure the application continues to work as expected.

Much of the wider software stack offers no such notice. Most open source libraries have no published lifecycle at all. A major version stops receiving security fixes when the maintainers move on to the next one, or stop working on the project altogether, and the only signal may be a commit history that has gone quiet. Security teams often discover that a component is no longer maintained only when a vulnerability is disclosed and no fix follows.

This exposure is not confined to systems that are obviously out of date. An application that is actively developed and fully supported can still carry unmaintained components deep in its dependency tree, pulled in by a library that itself depends on an older version of something else. The application team may never have chosen that component and may have limited ability to replace it without breaking compatibility elsewhere. An organization can find itself running unpatchable code without having made a decision to keep anything past end-of-life.

Meanwhile, vulnerabilities continue to be discovered, and at a faster rate than the systems built to handle them were designed for. 48,185 CVEs were published in 2025, a 20.6 percent increase on the year before, and NIST reported in April 2026 that submissions in the first quarter were running nearly a third higher than the same period in 2025. AI-assisted analysis is a growing part of that picture. In the first month of Anthropic's Project Glasswing, its Mythos Preview model identified more than 6,000 vulnerabilities estimated as high or critical severity in open source projects alone, and several maintainers asked the program to slow down its disclosures because they could not design patches fast enough. Those are projects with active maintainers. Software that no longer has any is receiving the same scrutiny from the same class of tools, and every flaw found there stays open.

The window for responding is closing from the other side as well. Mandiant's M-Trends 2026 report put the mean time to exploit at an estimated minus seven days, meaning exploitation is now routinely observed before a patch is even released, and exploits were the most common initial infection vector for the sixth consecutive year. For software that will never receive a patch, there is no window at all. Security teams still have to assess each new vulnerability and determine what action they can take, even when the normal source of a fix is no longer available. In some environments, the migration can be accelerated. In others, particularly highly specialized systems or applications with deeply nested dependencies, replacing the affected software safely can take considerably longer, while the time attackers need to take advantage of a known flaw keeps shrinking.

When Upstream Support Ends

Organizations running EOL software have several options. They can speed up the migration process, maintain the software themselves, accept the risk of known vulnerabilities or find another trusted source for security updates.

Extended lifecycle support can provide additional time for systems that cannot yet be replaced. Security fixes can be adapted for older versions of operating systems, libraries and other open source components after the original support period has ended.

This can be particularly useful when an EOL component is part of a larger application. Replacing a single library or runtime may require changes throughout the application stack, followed by testing before the updated environment can safely reach production.

Knowing What is Actually Running

Maintaining legacy infrastructure starts with knowing what is actually in the environment. A system that has been running for years may contain software from different sources, installed at different times and running different versions. When a new vulnerability is disclosed, security teams first have to figure out whether the affected component is even there — and, if it is, whether the vulnerability applies to their environment.

Keeping track of what is actually running can be difficult, especially in environments that have been in place for years. In May 2026, CISA warned of multiple software supply-chain intrusion campaigns targeting developer ecosystems, including CI/CD pipelines, code extensions and development workflows. The incidents underscore why organizations need to know what software and dependencies are present in their environments and where those components came from. Without that visibility, security teams can struggle to determine which systems are affected when a vulnerability or supply-chain compromise emerges.

Software inventories, Software Bills of Materials (SBOMs) and supply chain security practices can make that process much easier by giving teams a clearer picture of what is running and where it came from. Vulnerability Exploitability eXchange (VEX) information can add another useful layer of context by showing whether a known vulnerability affects a particular component in a specific environment. That context helps teams separate vulnerabilities that affect their environment from those that do not.

The same visibility matters before software ever reaches production. Knowing where a package came from, how it was built and whether its origin can be verified gives organizations more confidence in what they deploy. Signed packages, trusted sources and build attestations can provide evidence of software integrity that a vulnerability scan alone cannot.

The longer a system stays in service, the more important it is to know exactly what is running on it. Organizations need to know which components they depend on, which vulnerabilities affect them and where those components came from.

Managing the Transition

Eventually, legacy systems will need to be replaced. Security maintenance can extend the time available to complete that work, but it does not eliminate the underlying need for modernization. The real challenge is managing the period between recognizing that a system needs to be replaced and actually being able to replace it safely.

Managing that transition requires a combination of visibility and continued security maintenance. Organizations need to understand what is running in their environments, determine which vulnerabilities require attention and have a way to continue addressing security issues when upstream support is no longer available. Extended lifecycle support can provide continued security maintenance after upstream updates stop, for operating systems and for the libraries and runtimes an application depends on.

For critical infrastructure, the goal is simple: keep systems secure long enough to replace them properly, without forcing organizations to choose between running vulnerable software and rushing a migration before it’s ready.