Embedded software goes out of support: How to stay safe

Although the history of Microsoft Windows XP seemed to end in April 2014, the operating system was not completely gone; many embedded devices still ran Windows XP Embedded Service Pack 3, and as such they were dependent on its security updates.

Almost two years have passed since Microsoft called it quits on Windows XP support – a change long since announced and long expected, but it was still uncomfortable for many businesses and governmental entities. Although the history of Microsoft Windows XP seemed to end in April 2014, the operating system was not completely gone; many embedded devices still ran Windows XP Embedded Service Pack 3, and as such they were dependent on its security updates.

However, on January 12, 2016, Microsoft ceased supporting Windows XP Embedded Service Pack 3 as well. This is likely to have far-reaching consequences for many businesses.

Why did Microsoft drop the support?

Microsoft had obvious commercial reasons as well as security-related ones. Windows XP, in all of its versions, outlived its intended life cycle. Later versions of Windows have many technical advantages. And so on. Product life cycle is the primary concern here.

Discontinuation of support is a nominal, normal process, but with it may come some technical obstacles that make it difficult to get prepared for the end-of-support date on time. For example, hardware may keep working for much longer than the operating system’s planned life cycle, and replacing the software may be economically unfeasible. So businesses either find workarounds or keep using what they have been using past the expiration date.

Obsolete software isn’t going away, though it should

Obsolete software is a very common problem, and it’s not about consumer OS alone. It is widely known that some still-functioning satellites are running on decades-old hardware and software. There is a serious issue with supervisory control and data acquisition systems  (SCADA) too: They use very old operating systems, and the renewal cycle is very long. The same is true for the banking systems – and not just ATMs. Internal automated banking systems may not be updated for years. As for ATMs, 80% of smaller banks most often prefer to wait for their end of cycle (cycles may be 5–8 years, or longer), and then purchase newer machines with fresh software installed.

Obsolete Windows XP installations aren’t the most egregious example, either. Some really critical systems may run on software that is much older. For example, last November, Paris airport Orly stopped all flights because its air traffic control system crashed. The system couldn’t be fixed immediately because it was running on Windows 3.11: Yes, the 16-bit operating system released on December 31st, 1993.  Orly administration plans to update the software by 2017.

As you might guess, Windows 3.11 is most likely thick with bugs that hackers could have exploited – and that will never get fixed. Fortunately, that wasn’t the case with Orly, but attackers could easily hit on those vulnerabilities, and they wouldn’t need any sophisticated malware or zero-day exploits – many or most of those bugs have long been public.

The case of Windows XP

Windows XP’s end of support affected a great many businesses and government entities, including banks. Windows XP Professional for Embedded Systems – the very system that fell out of support in April 2014, along with consumer versions of XP – ran on most ATMs worldwide.

Many organizations weren’t happy about losing that support. Some of the world’s largest entities chose to pay formidable sums to Microsoft for extended support. The US Navy paid $9.1 million for continued Windows XP support (along with Office, and Exchange 2003), the UK Crown Commercial Service (CCS) paid for extension of XP support, as did Bank of America, JP Morgan, and several other banks. For them, patches keep arriving – or, they did until quite recently.

The reasoning behind not updating

For large organizations, replacing hardware and software is a long, expensive, and painful process. And organizations are reluctant to drop their still-functional tools – custom software and hardware systems – even ones that are long obsolete. As well, replacing software often means replacing the hardware: Compare the system requirements of Windows XP and Windows 10, for example. The latter wouldn’t work on those old Windows XP desktops; it would crawl at best and quite likely wouldn’t start at all.

As certain software drops out of support, organizations have a tough choice. They can either keep using the old software without any support, taking a huge risk and never knowing when criminals might exploit a newfound and never-to-be-fixed vulnerability – or pay Microsoft (or another vendor) a lot of money for the continued support, which not everyone can afford. They could also choose to migrate, which is extremely expensive done all at once. There’s another way, too.


Organizations still using obsolete software and hardware may use third-party security tools, adding a special protective layer against all kinds of vulnerabilities. Simply put, these technologies, generally known as “Dynamic Allowlists,” employ lists of legitimate software and prevent anything else from running in the system.

In fact, at a certain point, allowlists become the only approach to ensure safety of the obsolete systems.

One of the obvious advantages here is the cost. Instead of replacing everything at once, businesses can deploy such technologies for a reasonably low price, usually much less than $100 per device. And after they eventually upgrade, allowlists and “default deny” policies remain very useful as extra safety measures.