The Risks of End of Life Software and How to Address Them

The thing about nostalgia is that it conveniently omits all the past’s imperfections. Regardless of what car dads will tell you, older isn’t always better. American muscle cars are beloved for their admittedly cool looks, but we’d rather not think about their safety features (spoiler: there weren’t many).

Though we may be fond of our classic cars, the cold, hard truth is that nothing is built to last, including software.

Regardless of your attachment to a piece of software—for sentimental, technical, or (most likely) monetary reasons—every app, plugin, and OS you use will one day be put out to pasture. And that may put you and your company in a precarious position because it’s dangerously easy to keep using software past its EOL date.

Many organizations struggle to muster the will or the budget to get rid of EOL software, and take an “if it ain’t broke, don’t fix it” attitude. But keeping software around when it’s no longer getting security patches is extremely risky–on par with driving one of those pre-seatbelt muscle cars down the highway.

Updating or replacing any part of your tech stack is expensive, difficult, and frustrating, but between that or a data breach, we know what outcome most would prefer.

So let’s explore what it means for software to be at its end of life, why organizations continue to use software past its expiration date, and how you can best manage the risks associated with them.

What Is End of Life (EOL) Software?

End of Life (EOL) software describes the moment a developer or vendor decides to no longer provide technical support, security patches, or updates to their software.

Software has a pretty simple and predictable life cycle. After it’s released to the general public, a piece of software is available until its creator decides to stop selling it. (If the software is free, then you can skip to the next step.) Then, for a variable amount of time, the no-longer-for-sale software will continue to receive security patches and updates until the vendor stops supporting it.

Once a software is no longer supported, it is effectively sunsetted, and using it becomes very dangerous. (There are a few reasons for that but the main one is that if any vulnerabilities are discovered in the software, there’s no one to fix them, so they will remain exposed.)

How Do You Know When Software Has Reached its End of Life?

Unfortunately, it’s difficult to keep track of which software in your tech stack will be next to get a vendor’s ax. Sometimes you’ll get an email from the vendor letting you know about a sunsetting date; sometimes you won’t. (Especially if that vendor is no longer in business.)

If the software is popular enough, it may get a blog post or two on your favorite cybersecurity publication; it also may not. So you’ll have to find other avenues like this aggregator that keeps track of over 200 products’ most recent updates, EOL dates, and technical and security support dates.

One of the more important distinctions to understand about EOL software is that more often than not, it’s a version of a software that is no longer being supported rather than the software as a whole. Firefox, Microsoft Office, and many other applications have kept the same names for years or even decades, but have gone through numerous versions that are no longer supported. To understand how to keep track of these changes, let’s look at the example of macOS.

When Apple releases a new OS–especially one like Ventura, which introduced Rapid Security Responses–admins need to update the OS across their fleet to take advantage of security upgrades. However, upgrading your entire fleet to a new OS may be a tall order and take weeks or months to accomplish.

That’s not the end of the world, as long as the versions across your fleet are still being supported and patched. Yet, as we can see, the same day Apple debuted macOS 14 Sonoma it stopped supporting macOS 11 Big Sur, so anyone still hanging onto that OS needed to update ASAP. Unfortunately, those Big Sur users may not be aware that they can’t put off updating anymore.

You’d think a company like Apple would keep an official accounting of EOL dates for its operating systems—they don’t, leading it to be a community effort to keep track of it. (However, they do provide a list of obsolete hardware products, if you were wondering.)

Operating systems have increasingly frequent updates, but they pale in comparison to web browsers. Firefox updates once a month and the support windows for each previous update are a month long as well.

End of Life Software Risks

Tick, tick, tick. That’s the sound a piece of software starts making once it reaches EOL in your fleet.

The risks of using EOL software include increasing the likelihood of a data breach, the data breach becoming more costly, and increasing your legal liability if you knew about the risk and failed to update.

Once a piece of software reaches its End of Life, it will no longer receive security patches or updates, leaving it to be feverishly picked apart by bad actors looking for vulnerabilities.

For example, SonicWall’s customers were hit by ransomware attacks when its end-of-life VPN appliances were exploited. SonicWall provided its customers an official product life table and warned its customers to update their firmware when they became aware of the threat, but not everyone listened.

In a statement to BleepingComputer, SonicWall took an urgent tone, saying: “The continued use of unpatched firmware or end-of-life devices, regardless of vendor, is an active security risk.”

Using EOL software doesn’t just increase your likelihood of a data breach, it makes a beach more costly. According to a Kaspersky report, data breaches cost 47% (about $389,000) more in organizations that use outdated software. “The cost of a data breach rises by 47% to an estimated $1.225m in enterprises that still deploy outdated technology, compared to $836k where all software and hardware are up-to-date,” states the report. And it’s even worse for SMBs, where outdated technology makes breaches 54% more costly.

These higher costs can be attributed to two factors. For one thing, you have to immediately pay for upgrades to the compromised software. For another, it often takes longer for companies to discover a breach in EOL software, and the longer one goes on, the more costly it becomes.

Why Do Organizations Keep EOL Software?

Resisting change seems like a fool’s errand, unless you’re a proud Luddite. So why do so many companies still have old, rickety, and dangerous software still kicking around?

The reasons why companies don’t replace their EOL software are multifaceted, but as you can (always) assume: money is at the top of the list.

Money

One of the industries with a pervasive EOL software problem is healthcare. A 2022 Gartner Peer Insight survey of IT and security professionals working in healthcare found that nearly half had suffered a breach in the last two years, and named end-of-life systems as a “root cause.”

A 2021 Kaspersky report reveals that more than 73% of healthcare providers use medical equipment that runs on a legacy OS, which creates frightening risks. In 2022, the FBI released a bulletin that unpatched and outdated medical devices were primed for cyberattacks that could force insulin pumps and pacemakers to provide inaccurate readings and drug overdoses. Clearly, the stakes could not be higher. So what could possibly be standing in the way? Sadly, it comes down to cost.

The healthcare sector relies on specialized software and hardware that’s extremely difficult and expensive to replace. Ordr CEO Jim Hyman laid out the problem in an interview with HealthITSecurity: “For an industry that is already under pressure from a budgetary perspective, the thought of replacing a ton of devices that are running outdated systems without patches, unfortunately is just not an option for a lot of these organizations.” Instead, Hyman advocated practicing better security through zero trust and network segmentation.

Vendors haven’t informed them

Sometimes it’s a breakdown in communication between your vendors and their vendors that leaves your organization vulnerable.

Accellion’s legacy file transfer application (FTA) was breached in 2021. TechRepublic reported that Accellion’s software ran on the CentOS 6 operating system, which reached its EOL date on November 30, 2020, just weeks before the attacks started. While Accelion encouraged its customers to migrate to a new product that didn’t run on CentOS, it’s not clear that they made it clear that migration was an urgent security matter.

And with that lapse in communication, large corporations like Kroger and Morgan Stanley fell victim to the outdated product, resulting in sensitive data being exposed. As Karen Walsh, CEO at Allegro Solutions explained, “As CentOS 6 moved to end-of-life, Accellion needed to move their customers to a new platform. In the meantime, these malicious actors used a traditional SQL injection methodology to gain access.”

Oliver Tavakoli, CTO of Vectra, told TechRepublic that the lesson here is to keep a close eye on products approaching legacy status, since they may not be getting adequate vulnerability testing. Furthermore, take requests to migrate to a new product seriously, even if security isn’t explicitly mentioned as a driver. “When the vendor…spends 3 years trying to coax you to their new product, you may want to consider the subtext of that communication,” Takavoli said.

EOL software can be Shadow IT

So far, we’ve assumed that we’re talking about company-managed software sanctioned by the IT and Security teams. But if we’re being realistic, that’s not always the case. There is an epidemic of Shadow IT in the workforce, and which certainly includes EOL software. In fact, our recent Shadow IT report found that 47% of companies allow unmanaged devices–which are functionally invisible to security and IT teams–to access their company resources.

For an example of how wrong that can go, just look at the LastPass breach, which is widely believed to have stemmed from an employee using an outdated (by three years!) version of the media player Plex on his personal computer.

That’s why any strategy for ridding yourself of EOL software must include a device trust solution that can detect these vulnerable programs on employee devices, and stop them from accessing sensitive data until the program is updated or uninstalled.

How To Manage the Risks of EOL Software

If you were hoping for tips on how to keep using your EOL software, we sadly can’t give it to you. The only truly safe strategy is to identify and eliminate software once it’s no longer supported, but we can give you some concrete advice on how to do that.

Monitor EOL status

As we mentioned earlier, it can be quite arduous to keep up with EOL dates and announcements manually. For a more programmatic approach, the wonderful people at the endoflife.date aggregator have created an API to be alerted whenever a software reaches EOL.

While it’s by no means foolproof, if your software is listed on the site, it may be one of your best bets to keep as up-to-date as possible.

Here’s a request example of the endoflife.date API–written in Ruby as we do–if you’d ever like to request and receive an API call to find an EOL answer quickly.

require 'uri'
require 'net/http'

url = URI("https://endoflife.date/api/product.json")

http = Net::HTTP.new(url.host, url.port)
http.use_ssl = true

request = Net::HTTP::Get.new(url)
request["Accept"] = 'application/json'

response = http.request(request)
puts response.read_body

Remove EOL software from your system

Once you know a piece of software is approaching its EOL, start planning your migration to a new version–or potentially, a new application altogether. Depending on how disruptive the changeover will be, you may want to stagger the transition over multiple weeks or even months, but the important thing is to start. Don’t wait until a program is no longer supported to transition off it!

For employee-facing applications, particularly those that require end user input to update, focus on direct communication. Let users know about the coming change, the reasons for it, and set a firm deadline, after which the old software will no longer be permitted.

Ideally, you can get end users to take action themselves, rather than forcibly uninstalling software via MDM, since that can lead to data loss events and general frustration.

Identify and block EOL software on end user devices

Rooting out legacy software on servers or IoT devices isn’t easy, but can still be accomplished with centralized control. It’s much more complex to phase out EOL software when it lives on employee devices. For one thing, updating software via MDM often requires forced restarts, which are unpopular to the point of nonviability. On top of that, as we mentioned, IT has no ability to enforce policy on unmanaged devices.

What’s needed is a programmatic solution that identifies and blocks EOL software without causing havoc for end users and IT. And that calls for device trust.

Device trust is the idea that a device must meet an organization’s minimum security requirements before it can access sensitive data. Kolide’s device trust solution–which we promise we’re only mentioning because it’s the best–lets you write Custom Checks that can stop users from authenticating if they are running an unsupported version of a given piece of software. (Kolide will also instruct users on how to update or uninstall the application so they can authenticate successfully.)

Let’s take Adobe Flash as an example. Since it sunsetted in 2020–pour one out for Flash, those games will live in internet history–it should be long gone from any corporate devices. But just in case it’s not, here’s an example of a SQL query that you can input to Kolide’s Custom Check editor to create a Check that effectively prohibits its presence and alerts your end users to uninstall it:

WITH
forbidden_program_names (forbidden_program_name) AS (
  -- Supply forbidden program names wrapped in parentheses and comma-separated
  -- below. For example: ('Microsoft Teams'),('Zoom')...
  -- Wildcard % characters are supported for partial matches
    VALUES ('Adobe Flash%')
),
-- This section looks for matches of your provided program identifiers or names

-- with those installed on your device

forbidden_programs AS (
  SELECT
  p.name,
  p.version,
  p.identifying_number,
  p.install_location
  FROM forbidden_program_names fpn
  LEFT JOIN programs p ON p.name LIKE fpn.forbidden_program_name
  WHERE name NOT NULL
),

matching_forbidden_programs AS (
  SELECT
  COUNT(*) AS matching_programs_count
  FROM forbidden_programs
),

-- Using LEFT JOINS against the 'time' table we return attestable output even

-- when no matches are found

merge_data AS (
  SELECT
    matching_programs_count,
    fp.*
  FROM time
  LEFT JOIN matching_forbidden_programs
  LEFT JOIN forbidden_programs fp
),

failure_logic AS (
  SELECT *,
    CASE
      WHEN (
        matching_programs_count = 0
      ) THEN 'PASS'
      WHEN (
        matching_programs_count > 0
      ) THEN 'FAIL'
      ELSE 'UNKNOWN'
      END AS KOLIDE_CHECK_STATUS,
    CONCAT(name,' - (',version, ')') AS primary_key

  FROM merge_data
)
SELECT * FROM failure_logic;

When you create a real Check, you will also have to write fix instructions so your end users know what to do and why this issue is important.

The Final Countdown

Although outdated software may be technically functional, that doesn’t mean it’s safe for your organization. Each passing day that End of Life software remains across your fleet is another roll of the dice. And hopefully, this article can help you convince your company’s leadership that this isn’t a gamble worth making.

Want to receive more security insights like this? Subscribe to the Kolidescope newsletter!