What will it take to solve end-of-life software issues?
With Windows 10 grabbing headlines with its end of life date lapsing last week, here's a look at the challenges of replacing software and managing the issues.
Published on 22nd October 2025
You might not know it, but old software surrounds us every day. The oldest software products still used today are the SABRE airline booking system and the IRS Individual Master File and Business Master File tax record systems, according to the Guinness World Records listing for software in continuous use.
These software systems were designed and launched in the early 1960s. Yet, while these applications might still be running and doing the job for which they were created, there is a wealth of other software out there that is also old and potentially dangerous.
Older software systems are still in use
Software that is no longer supported or supplied with security updates is termed ‘end of life’. The highest-profile example here is the Microsoft Windows operating system, where versions are replaced, and older ones are no longer supported and don’t receive updates.
According to StatCounter, Windows 11 and Windows 10 are the most widely used systems, at 53.3% and 42.9%, respectively. However, older systems are still in use, with Windows 8 (circa 1% in total), Windows 7 (2%), and even Windows XP (0.44%) still represented. XP went end of life in April 2014; yet, a few installations still hold out across the global desktop install base.
Windows 10 gets its own end-of-life date on 14 October 2025 – for an OS that once had more than one billion devices installed, that level of change is a huge undertaking
But why does this end-of-life software still get used? Why aren’t we all moving to the newest and most secure software as standard? Ideally, this would take place. However, for some projects, the original developer has gone bankrupt or ceased providing updates.
For others, companies don’t want to pay for newer versions when their older systems work just fine. In some circumstances, the software can’t be updated – any change would break the business process, and the cost to rebuild that application is far higher than the revenue it would create. In others, those applications have just been forgotten about.
Managing end-of-life software: What should you know
Whatever the reason, that class of software represents a risk. According to our research, nearly half (48%) of the issues on the CISA Known Exploited Vulnerabilities list are found in outdated and unsupported software, while 20% of critical assets have software installed that includes end-of-support software with known issues rated as ‘high’ or ‘critical’.
Managing this software involves a security-focused approach to asset management, which includes knowing what assets you have, who within the organisation is responsible for each asset or software in the business, and what risks that software might pose. This detail is not typically part of a traditional IT Asset Management tool, yet it is the key to prioritisation of remediation.
For all your software, consider tracking the status over time of those installations across their lifecycle, from general availability through to end-of-life or end-of-support status. Within this, you should also prepare a report on any assets that will reach end-of-life status in the next six or twelve months, allowing sufficient time for migration planning or upgrades.
For software that reaches end-of-life/end-of-support status without being replaced, there is normally a reason. When it comes to the cost of implementing changes, ensure that you have a documented business case and the corresponding implementation budget figure available.
Alongside this, you can track the Value at Risk to the business from that end-of-life software, capturing how much any potential downtime or cyber incident would represent to the business over time. You can then use this Value at Risk figure to determine if and when the cost of migration is lower than the potential risk of maintaining the status quo.
Challenges of shutting down end-of-life software
The biggest challenge here is with critical applications, where revenues are directly tied to the service running. For the business, turning off these systems will encounter more resistance because any downtime represents lost revenue.
The risk of lost revenue is greater than the potential impact, so no changes are made. This is itself a risk. Yet companies will consider other similar single points of failure and plan ahead for them – take a particularly valuable employee responsible for product design, or the CEO, for example. Losing them would represent a serious impact on the business, so they will typically employ key person insurance to mitigate that risk for factors beyond the organisation’s control.
Even with systems that are deemed ‘mission critical’, there are often gaps that you can take advantage of to implement changes. For example, one manufacturer resisted changes to its systems that ran production lines; however, they did have a period during which shift changes would occur, and the lines would come to a halt for a short time.
By exploiting this planned downtime and implementing the change gradually, the IT team were able to update systems and maintain productivity. There are, therefore, ways to plan ahead and reduce that risk.
Overcoming obstacles
What happens when you can’t just replace that software? Typical protection for these systems includes air-gapping and running on unconnected networks, while application firewalls and other security systems can be used to limit interaction to known and trusted devices.
In these circumstances, understanding potential misconfigurations or methods to access the system will be essential to prevent potential attacks and seek alternatives to patching. Deploying the capability to eliminate risk by deploying these countermeasures will be a vital cog in your layered defence strategy.
For businesses, end-of-life software may seem like another security expense, and when significant budget constraints are in place, security issues can be easier to overlook. To address this, you should quantify the extent of that impact in a form that is easy for the business to understand – in terms of money. The business already mitigates other risks in this manner, so you can apply the same approach.
Alongside this, there is the broader impact. While an attack on an asset rated as non-critical might be limited to that specific machine or piece of software, the likelihood is that it could affect the wider network or be used as a starting point for lateral movement.
While the business will understand the risk that exists when systems are compromised, framing it in terms of monetary impact will make it easier to obtain support from business leadership.
The future of software replacement: Reducing dependency to plan ahead
All software has a lifecycle. Even systems responsible for managing flight bookings or tax returns will eventually be replaced.
The challenge is how to avoid getting into situations where the business is so dependent on any one piece of software that the thought of turning it off is itself a risk. Rather than being beholden to this software, you can help the business understand the challenges, the potential impact, and then plan ahead.
Using Value at Risk to calculate the monetary impact makes it easier to argue from a position of strength in business terms, rather than relying solely on technological reasoning.
Source
Image Credit
Marco Guidi via Vecteezy
