Cyber Insurance and End-of-Life Software: What's Excluded in 2026

Cyber insurance applications used to ask whether you ran retired software as a matter of record-keeping. The question is now underwritten.

Answer it accurately and you may draw a higher premium, a coinsurance endorsement, or a decline. Answer it inaccurately and you have handed the carrier a rescission defense it can raise years later, after a breach, at the point where the coverage was supposed to matter.

There is a third answer. It is worth understanding before the renewal window opens.

‍

How the application became an audit

The market entered a hard cycle in 2021 after two years of ransomware-driven loss escalation. Fitch Ratings put the industry direct loss ratio for standalone cyber at roughly 73 percent in 2020, against a five-year average of 42 percent across 2015 through 2019. Average paid losses per closed standalone claim ran $145,000 in 2019 and $358,000 in 2020. Several carriers exited new business. The ones that stayed repriced and rewrote their underwriting requirements.

Capacity returned in late 2022. The underwriting framework built during the hard cycle did not go away.

Applications issued before 2022 typically ran twenty to thirty yes/no questions on MFA, backups, and incident response. Current applications run forty to sixty and ask for documentary evidence instead of attestation, paired with an external attack-surface scan before bind. In a meaningful share of programs the scanning continues through the policy period.

The practical effect is that policyholder statements are no longer taken at face value. Answers on patch cadence get validated against observable public-facing exposure. Answers on unsupported-software inventory get cross-referenced against what the scan actually finds. A material mismatch produces either an exclusion attached at bind or a misrepresentation defense available at claim time. The application has become a security audit with a contract attached, and the part of the stack it examines hardest is the part you cannot modernize quickly.

Two loss events set this posture. The Microsoft Exchange ProxyLogon chain in March 2021 produced widespread compromise across organizations running unpatched or unsupported Exchange installations. Log4Shell in December 2021 demonstrated that a single transitive dependency in a minimally maintained component could generate simultaneous claims across an entire underwriting portfolio. Both are why the scan exists.

‍

What the loss data says about EOL specifically

Coalition's 2023 Cyber Claims Report found that policyholders running end-of-life software, regardless of organization size, were three times more likely to suffer an incident. The same report put policyholders with even one unresolved critical vulnerability at 33 percent more likely to experience a claim.

That is not a modeling artifact. It is a distinct risk class, and it gets priced as one.

The cost of ignoring the scan is documented. Coalition reported that 614 businesses declined to remediate critical issues identified during pre-bind assessment, went on to suffer ransomware attacks in 2024, and generated $307 million in aggregate losses, averaging roughly $500,000 per business. Those organizations were told where the exposure was.

Rates, meanwhile, have been soft. The Council of Insurance Agents and Brokers reported an average cyber rate decrease of 3.3 percent in Q4 2025, with conditions pointing to flat or slightly higher pricing through 2026. The softening is masking continued contractual tightening for policyholders with documented EOL exposure. The restriction moved out of the premium and into the wording, where it is harder to see and considerably harder to negotiate away.

‍

Anatomy of the exclusion

The most explicit carrier-published treatment is Chubb's Neglected Software Exploit endorsement, introduced in 2021 and attached to the Cyber Enterprise Risk Management policy.

The definition has two independent triggers. One is a patch clock: a CVE listed in the National Vulnerability Database with an available fix that the insured did not apply within the stated window. The other has nothing to do with patching. It captures software that has been withdrawn, is no longer available, is no longer supported by, or has reached end-of-life or end-of-support status with the vendor that developed it. In the ERM v2.2 wording this sits at Definition 3.47. The numbering shifts by an increment across regional editions of the same policy, appearing as 3.46 in the international wording, so check the form number on your own schedule.

The second trigger has no patch to apply and no clock to reset. Vendor support status is the trigger. Internal patching discipline does not reach it, because upstream stopped shipping.

Chubb positions the endorsement as rewarding hygiene rather than penalizing failure. The published factsheet describes full coverage for 45 days, after which risk sharing between insured and insurer is gradually re-weighted, with the shift landing at the 46, 90, 180, and 365-day marks. A Chubb endorsement schedule filed in a municipal procurement record shows the bands populated:

Percentages, sublimits, and excesses are negotiated in the Schedule and yours will differ. The band structure is what carries over.

Which raises a question worth resolving in writing with your broker before you need the answer. When a loss triggers the end-of-life prong rather than the patch-delay prong, which band applies? There is no patch date to measure from. The reasonable reading is that indefinitely unsupported software occupies the most punitive band from day one, at whatever percentage was negotiated privately. Get that in email.

‍

The carriers say so themselves

In its August 2021 claims report, Coalition CEO Joshua Motta differentiated his company in terms that establish the practice he was differentiating from: Coalition had not pulled back on coverage, sublimited ransomware, added coinsurance, or added exclusions for end-of-life software. Cybersecurity Dive reported the contrast as being with what others in the market were doing.

Stephanie Snyder Frenier of CAC Specialty, writing in Risk & Insurance, described the same structure from the broker's side: several carriers introducing specific exclusions for unsupported software and unpatched vulnerabilities, some adding coinsurance that shifts risk incrementally to the buyer as time passes.

Frenier and Motta are describing the same market from opposite sides of the table.

‍

Three mechanisms, operating in parallel

The named exclusion is one path to a denial. There are three, they are independent, and a well-constructed denial deploys all three in the alternative.

The named exclusion or coinsurance penalty. The carrier identifies the retired component, references the endorsement, applies the band. No proof of negligence, misrepresentation, or causation is required beyond the exposure itself.

Rescission for misrepresentation. This one does not require the policy to contain any exclusion at all. It operates through the carrier's right to void a policy ab initio where the application contained material misrepresentations. In Travelers Property Casualty Co. of America v. International Control Services, No. 22-cv-2145 (C.D. Ill. 2022), Travelers pleaded that it would not have issued the policy had it known MFA was not deployed as certified. The court entered a stipulated rescission order in August 2022 declaring the policy null and void from its inception.

The policyholder did not lose the claim. It lost the policy, retroactively, for the entire period. The same defense reaches any application answer of comparable materiality, including the end-of-life inventory questions now standard on carrier proposal forms.

The minimum required practices warranty. This sits between the other two and requires neither a named exclusion nor proof of misrepresentation. CNA's NetProtect360 form, at issue in Columbia Casualty Co. v. Cottage Health System (C.D. Cal. 2015), combined three components: a warranty in the policy conditions requiring the insured to maintain the controls identified in its application, an exclusion triggering on any failure of that warranty, and an application question establishing what had been warranted. The accompanying CNA self-assessment asked whether the applicant checks for security patches weekly and implements them within thirty days. Any policyholder who answered yes at bind, and whose breach traces to an unpatched or unsupported component, faces the exclusion before the merits of the loss are reached.

Hamilton, Ontario shows the scale. A February 2024 ransomware attack hit the city, and its insurer denied the claim because multi-factor authentication had not been fully implemented at the time of the attack. A third-party review found the denial consistent with the policy. Recovery costs reached $18.3 million, and councillors learned the insurer had asked for MFA in late 2022.

That was MFA rather than EOL software. The mechanism is the one described above: a control the policy required, incompletely implemented, and an eight-figure recovery bill landing on the balance sheet.

‍

Betterment, which is standard rather than rare

Named exclusions for end-of-life software remain relatively uncommon in standalone forms. Betterment exclusions are not. The clause sits in the loss or damages definition of nearly every cyber policy sold in the United States, and its function is to deny the cost of replacing the system that caused the loss with a current, supported equivalent.

AIG's CyberEdge specimen excludes updating, upgrading, enhancing, or replacing a system beyond the level that existed before the insured event. Near-identical formulations appear in AXA XL's CyberRiskConnect and At-Bay's form. CFC's Cyber Private Enterprise policy is the exception, carving back up to 25 percent above the cost of restoring the original where the rebuild follows a hacking attack or malware infection.

The dominant pattern funds a remediation that restores the same end-of-life posture the policyholder occupied before the breach, and excludes the migration that would prevent the next one.

‍

Why frameworks are the hardest category to clear

Conditional renewal letters, which brokers call cure notices, typically allow thirty days for a remediation plan and twelve months for execution. That works for a legacy database. It does not work for an application framework.

The wave keeps advancing:

• AngularJS reached end of long-term support on December 31, 2021
• Spring Framework 5.3.x and 6.0.x exited open-source support on August 31, 2024, with 6.1 ending June 30, 2025 and 6.2 ending June 30, 2026
• Node.js 16 reached EOL in September 2023, followed by Node.js 18 on April 30, 2025 and Node.js 20 on April 30, 2026
• Java 8 exited Oracle's free public updates in January 2019
• Bootstrap 3 exited support on July 24, 2019

Retiring a framework means application-layer rewrites, routinely eighteen to thirty-six months and seven-figure budgets. Both numbers exceed the cure window, and the budget frequently exceeds the premium reset the migration was meant to avoid. Spring 5.3 is the clearest case: every supported generation requires Java 17 as a hard minimum, so a team on Java 8 or 11 faces a JDK migration before the framework migration can start.

Two problems compound it. Transitive dependencies mean a current Spring version can still import an unmaintained library through two or three intermediate hops, which is the same exposure as running the retired framework directly from the underwriter's position. And SBOM is necessary rather than sufficient: it answers what is present, not what is being done to keep the unsupported components secure, which is the underwriter's next question. Inventory alone converts an unknown exposure into a documented one and hands the underwriter a list.

A useful diagnostic before any of this: can your security team produce, inside three business days, a complete list of production components whose vendor has stopped issuing security patches? In most enterprise environments the answer is no, and the reason is the finding.

‍

What "vendor-supported" can mean now

The application questions assume support is binary. Either the original publisher maintains the software or it is end-of-life. A secondary market for ongoing vendor-equivalent maintenance now exists, and underwriters increasingly accept documented evidence of it as the affirmative answer.

Three artifacts carry that weight:

1. A signed support agreement naming the components in scope. This converts the inventory entry from end-of-life to vendor-supported, and it is what the broker attaches to the submission.
2. Documented CVE remediation evidence, as a published patch log or advisory feed with dated entries. This answers the patch cadence question with records rather than assertions.
3. A vendor attestation letter confirming scope and cadence, drafted so the broker can hand it to an underwriter directly.

The same three documents work against all three denial mechanisms. They remove the trigger for the named exclusion, because the components are supported. They remove the misrepresentation hook, because the application answer is accurate and evidenced. They satisfy the warranted-control standard, because the patching commitment is contractual and logged.

What makes that credible to an underwriter is that the arrangement is no longer informal. Upstream projects and their foundations have started sanctioning it directly. The Node.js project names commercial EOL support providers on its own end-of-life page, and HeroDevs coverage for Node.js was established through the OpenJS Foundation's Ecosystem Sustainability Program. Vue's official LTS page points teams remaining on Vue 2 past its December 2023 EOL to the same place. And in June 2026 the Commonhaus Foundation launched the Open Source Sustainability Initiative with HeroDevs as founding Gold Partner, initially covering Hibernate, Jackson, and Quarkus. Commonhaus describes the program's purpose in terms an underwriter would recognize: when a project declares a version end-of-life, maintainers get a set of vetted partners to point to for the users who cannot upgrade yet.

That is the difference between asserting a component is supported and demonstrating it. The upstream project agrees.

HeroDevs Never-Ending Support produces the artifact set as a default deliverable rather than an add-on, with continuous CVE remediation through a private secure registry, ongoing compatibility maintenance, and documentation built for the renewal file. Coverage for the frameworks named above sits at AngularJS, Spring, Node.js, and Vue 2.

‍

Taking action

Coverage cannot be meaningfully expanded once a policy is bound. Mid-term changes are close to unobtainable. The window that determines the next twelve months opens roughly ninety days before renewal and closes when the application is submitted, typically thirty to forty-five days out.

The T-90 to T-60 work is technical. The T-45 to T-0 work is contractual and communicative. The calendar repeats, and the next cycle opens the day the current one closes.

Two documents belong on the desk of every Risk officer before the next renewal: the unsupported-software language in the current policy, and the underwriting questionnaire to be completed at renewal. Read side by side, the gap between them is the exposure, and it is quantifiable well before it becomes a claim.

The economics are asymmetric. Being wrong costs a denied or rescinded claim in the seven or eight figures, plus coverage at renewal, plus the board-level event that follows a disclosed breach turning out to be uninsured. Being right costs a support contract priced at a fraction of one year of the premium delta.

That asymmetry explains why these contracts increasingly get signed by Risk rather than Engineering. A vendor support agreement an engineering leader could not justify on hygiene grounds gets approved by Risk as a defensive move against a premium reset an order of magnitude larger. Same spend, different budget line, and this one has a number attached to the downside.

‍

This article is general information, not legal or insurance advice. Policy wording varies materially between carriers and between forms from the same carrier. Review your specific policy, endorsements, and application with your broker and counsel.