Is Your MSP Billing You to Patch Software That Has No Patches?

Last updated: July 16, 2026  ·  A 20-minute self-audit for anyone who pays a monthly fee for "patch management"

If your business pays a managed service provider a monthly fee, the invoice almost certainly includes a line like patch management and security updates. Here is a question worth twenty minutes: how much of the software on that invoice can still be patched at all?

Because there is a hard technical fact underneath the billing relationship. When an operating system or runtime passes its vendor's end-of-life date, the vendor stops shipping security updates. Not "ships them slower." Stops. Patching an end-of-life system is not difficult — it is impossible, because there is nothing to patch with. If part of your fleet is EOL, then for that part of the fleet, the patch-management service is, definitionally, not happening. The line item keeps billing anyway.

To be clear up front: this is not an anti-MSP article. Many MSPs are excellent, and the good ones will welcome everything on this page. The point is accountability — knowing which systems can still be patched, which cannot, and what you are actually paying for on each.

Why This Happens Without Anyone Lying

Almost no MSP sets out to bill for a service it cannot deliver. The gap opens up mechanically, in three ways.

The tooling hides it. MSPs run patching through RMM (remote monitoring and management) platforms. On most of them, a server that installed every available update last night and a server whose vendor stopped producing updates three years ago report the same status: no patches available. Both rows show green. The dashboard cannot distinguish "fully patched" from "nothing left to patch with," so a fleet can rot quietly behind green checkmarks.

Estates get inherited, not audited. Most MSPs take over environments built by a predecessor, an in-house tech who left, or fifteen years of accumulated decisions. Onboarding covers backups, credentials, and monitoring agents; re-checking every OS and runtime against vendor lifecycle calendars rarely makes the list, and once the contract is running, nobody re-audits the baseline.

EOL dates keep arriving. A fleet that was fully supported when the contract was signed does not stay that way. Support windows close every single month, and unless someone is actively watching the calendar, systems cross the line silently.

What Commonly Lurks in an SMB Fleet Right Now

These are not exotic edge cases. As of July 2026, every one of the following is past end of life or on a hard deadline, and every one is routinely found in small and mid-size business environments:

Software End of Life Status Where you'll find it
Windows 10 (22H2) October 14, 2025 EOL Desktops and laptops across the office — the single largest SMB exposure right now
Windows Server 2012 / 2012 R2 Extended support ended Oct 10, 2023; final paid ESU year ends Oct 13, 2026 ESU cliff The old file server or line-of-business app box in the back room
PHP 7.4 November 28, 2022 EOL The company WordPress site — EOL for over three and a half years
Ubuntu 20.04 LTS May 31, 2025 EOL Web servers, internal tools, that VM someone spun up in 2021
SQL Server 2016 (SP3) July 14, 2026 EOL — days old Behind accounting, ERP, and practice-management software — crossed the line this very week
Note the last row. SQL Server 2016's extended support ended two days before this article was updated. If it is in your fleet, your MSP's dashboard almost certainly still shows it green — exactly the visibility gap this audit closes.

The 20-Minute Self-Audit (No Technical Skill Required)

You do not need to log into a server or understand a CVE to do this. You need an email and a web browser.

  1. Ask your MSP for the inventory they bill against. Request the list of operating systems and software covered under your patch-management agreement, with versions. You are the paying client; you are entitled to it, and any competent MSP can export it from their RMM in minutes.
  2. Check the list yourself. Paste it into the free EOL checker, or if you have technical staff, run dependency files through the scanner.
  3. For anything flagged EOL, ask in writing: "What does the patch-management line item cover for this specific system?" Written, not verbal — you may want the paper trail later.
  4. Expect one of three legitimate answers. (1) We're migrating it — with a date. (2) It's covered by extended support — a real, paid arrangement under which a vendor still produces patches for it (see extended support options). (3) We've documented it as accepted risk — with your signature on the acceptance, because it is your risk. The one illegitimate answer is silence while the billing continues.

Questions for Your Next QBR

Every MSP relationship should include a quarterly business review. Put these on the agenda, verbatim:

A Good MSP Will Thank You for This

Here is the part that surprises people: this conversation is good news for a well-run MSP. Every EOL system you surface together becomes a legitimate, billable migration project for them and honest coverage for you — silent risk converted into scheduled work. The MSPs that resent the question are telling you something about the relationship. The genuinely bad outcome for everyone is discovering the EOL fleet after an incident, when a cyber-insurance claim reviewer compares your "all systems patched" attestation against what was actually running (see how insurers treat EOL software).

Twenty minutes, one email, one free checker. Either you confirm your MSP is on top of it, or you find the gap before an attacker or an adjuster does. There is no version of this audit that leaves you worse off.

Frequently Asked Questions

Can an MSP patch end-of-life software?

No — not in the normal sense. Once a vendor declares an OS or runtime end of life, it stops publishing security updates. There is nothing for the MSP's tooling to download and apply. The only real options for an EOL system are migrating it, purchasing extended support from a vendor that still produces patches for it, or formally documenting the accepted risk.

Is my MSP deliberately overbilling me for patching EOL systems?

Usually not. Most RMM platforms report "no patches available" identically for a fully patched system and an end-of-life one, so the dashboard stays green either way. MSPs also frequently inherit sprawling estates, and nobody re-audits the baseline. The problem is typically visibility, not malice — which is exactly why it is worth raising directly, and in writing.

How do I find out which of our systems are past end of life?

Ask your MSP for the software and OS inventory they bill against — as the paying client you are entitled to it. Then paste the list into the free checker, or run dependency files through the scanner. Anything flagged EOL is a system the vendor no longer ships patches for.

What should my MSP do about systems that are past end of life?

Three legitimate answers: migrate the system to a supported version, buy extended support so patches keep flowing, or document the risk you have jointly agreed to accept. The one illegitimate answer is continuing to bill for patch management on that system while saying nothing.

Related Resources