How to Protect End-of-Support Applications on Supported Servers

To protect an application past its end of support on a server that's still supported, start by finding it, because the server's patches won't touch it. Then upgrade it or buy the vendor's extended support if there's any. Where neither works, keep it under a documented exception with compensating controls: limit who can reach it and check what changes on the server it runs on.

Updated 22 October 2026 by Mimic Networks. The outside sources sit at the end, each with its own date.

Why is an unsupported application a risk on a supported server?

Because operating system patches don't fix application code. Microsoft's description of end of support is typical: "there will be no new security updates, non-security updates, or assisted support" (Microsoft Learn). The Python project put it more bluntly when it sunset Python 2 on 1 January 2020: "we will not improve it anymore after that day, even if someone finds a security problem in it" (Python Software Foundation).

These applications are common on servers that are otherwise current. SQL Server 2016 left Microsoft's Extended Support on 14 July 2026 (Microsoft), and SQL Server 2014 is in its final year of Extended Security Updates, which ends in July 2027 (Microsoft Learn). CISA lists the use of unsupported software in critical infrastructure as a bad practice that "significantly elevates risk" (CISA).

How do you find them?

From your software inventory, checked against each vendor's support dates. CIS Safeguard 2.2 asks you to "Ensure that only currently supported software is designated as authorized in the software inventory for enterprise assets," and to review software support "at least monthly, or more frequently" (CIS). Look past the obvious names: runtimes, libraries, database engines and agents that shipped inside another product count too.

What are your options for each one?

1. Upgrade or replace it.That ends the problem instead of managing it. NIST's patch management guide names the case directly: a patch "will never be released because the software is at end-of-life" (NIST SP 800-40 Rev. 4).
2. Buy extended support where the vendor offers it.Microsoft sells Extended Security Updates for some products, SQL Server 2016 among them (Microsoft). They cover security updates only, for a set period.
3. Keep it under a documented exception.CIS Safeguard 2.2 allows unsupported software only when you "document an exception detailing mitigating controls and residual risk acceptance" (CIS). Name an owner and a review date.
4. Apply the compensating controls the exception names.NIST tells organizations to "plan to implement multiple types of long-term risk mitigation methods besides patching to protect vulnerable assets" (NIST SP 800-40 Rev. 4). Restrict who and what can connect to the application, remove internet exposure, run it under an account with only the rights it needs and add a control on the server that limits what an exploit can change.

Where does virtual patching fit?

On the server the application runs on. Virtual patching protects a vulnerable system without changing its code, so it works where no fix is coming. Mimic Networks' Virtual Patching works in two forms, and both require baselining. Disruption blocks the specific mechanism an analyzed vulnerability depends on, so the exploit doesn't succeed. Containment limits what an exploit can do once it lands, so one safeguard can cover a whole family of exploits. It's part of Mimic's known-good enforcement approach.

Mimic profiles the server the application runs on in its authorized state, checks each attempted change against that baseline and stops exploitation at the point of execution. Before a safeguard goes live, Mimic replays it against the host's recorded behavior to show what it would block. The server needs to run Windows Server 2016 or later, or Red Hat Enterprise Linux 8 or later.

What doesn't this cover?

• Misuse of the application's own functions. An attacker who reads data the application is allowed to serve makes no unauthorized change to the server.
• The flaw itself. It stays in the code until you upgrade or replace the application.
• Applications on operating systems older than Windows Server 2016 or Red Hat Enterprise Linux 8.
• Network traffic. Keep the network controls that limit who reaches the application.