Unsupported software now has a price — and it's written into your cyber insurance policy

Carriers are writing end-of-life exclusions into 2026 policies. The practical deadline for a platform decision may now be your renewal date, not your vendor's calendar.

For years, the argument for retiring end-of-life systems rested on risk that felt abstract: unpatched vulnerabilities, compliance findings, the slow accumulation of technical debt. Vendors published end-of-support dates, and businesses — rationally, in the short term — kept running what worked.

That calculus is changing, and not because of the vendors. It's changing because of your cyber insurance carrier.

Across 2026 renewals, carriers are writing end-of-life and unpatched-system exclusions directly into policies. The plain meaning: if a loss traces back to software that no longer receives vendor support, coverage may not apply — even if every other control in your environment is exemplary. Industry guidance now lists EOL exclusions alongside war exclusions and social-engineering carve-outs as standard language to scrutinize before signing.1

The examples carriers cite are the systems we see every week in mid-market environments: a Windows server past its support window still running a line-of-business application, an aging on-premise mail server, an ERP on a database version the vendor stopped patching years ago.2

And the underwriting process has grown teeth. Carriers increasingly require documentation rather than checkbox attestations — deployment reports, patch records, evidence of tested backups. Organizations that can't demonstrate their controls face premium increases of 50–200%, or no coverage at all.3

Your platform's end-of-support date arrives once. Your insurance renewal arrives every year.

Here's the shift worth sitting with: the end-of-support date arrives once. The renewal arrives annually.

We've long argued that the published EOL date is the wrong deadline — that the real deadline is the start-engagement-by date, the point at which you must begin selection and implementation to complete a transition before support ends. That remains true. But the insurance market has now introduced a second forcing function that can arrive even earlier: the first renewal questionnaire that asks, specifically and in writing, whether any system in your environment is past end of support.

Answer yes, and you're negotiating exclusions, sub-limits, or co-insurance on the exact systems most likely to be involved in an incident. Answer inaccurately, and you've handed the carrier grounds to contest a claim when you need the policy most.

For a business running core operations on any platform with a published sunset date, the practical deadline may no longer be set by the software vendor at all. It may be set by whichever comes first: the start-engagement-by date, or the renewal at which your broker can no longer place coverage on acceptable terms.

To be fair, staying on a supported-but-aging platform and paying the resulting premium can be a defensible short-term position — if it's priced deliberately, with the exclusion language understood and the transition funded on a known schedule. What no longer works is drifting past end of support and assuming the policy reads the way it did three renewals ago.

The exclusions aren't arbitrary. Carriers are pricing what incident-response data keeps confirming: legacy systems excluded from security policy are consistently where breaches begin. Forensic casework in the mid-market shows that when credential-driven breaches occur, the entry point is disproportionately the exception — the service account without MFA, the legacy system carved out of the standard because retrofitting it was too hard.4 Ransomware operators have industrialized this: aging edge devices and unpatched infrastructure are now the reliable way in, and mid-market companies are increasingly the preferred target.5

The insurance market is simply making that risk legible on an invoice.

Do you actually know what's past end of support in your environment? Most companies don't — not comprehensively. The inventory has to include not just operating systems but the ERP, the database underneath it, the field service platform, and the integration layer nobody has touched since the person who built it left. Our free EOL Radar exists for exactly this: a plain view of when the systems mid-market companies actually run lose vendor support.

Does your renewal date fall before your realistic replacement date? If a platform you depend on goes end-of-support in 2027 and your policy renews next spring, the conversation with your broker happens first. Knowing that sequence in advance is the difference between negotiating from a plan and negotiating from exposure.

Can you document a transition in progress? Carriers distinguish between an unsupported system with no plan and one inside a funded, scheduled migration. A credible roadmap — with a selection process underway and dates attached — is itself an underwriting asset.

The vendors set the calendar. The attackers set the risk. Now the carriers are setting the price. For mid-market leadership teams, the useful reframe is this: an end-of-life platform is no longer just an IT liability quietly accruing on someone else's roadmap. It's a line item your insurer is about to reprice — annually, in writing, whether you've planned for it or not.

If a system you depend on is approaching its support horizon, the time to work backward from that date is now. That's a conversation worth having with someone who has sat in the chair. Start with the EOL Radar, and if continuity documentation is the gap your broker flags, the Business Resiliency Scorecard shows you where you stand in ten minutes.