The Cyber-Insurance Question You Can't Answer: "Do You Run Unsupported Software?"
The renewal questionnaire arrives, and somewhere between the questions about multi-factor authentication and backup testing sits a deceptively simple one: "Does your organization use any software or operating systems that are end-of-life or no longer supported by the vendor?" It usually wants a yes-or-no, sometimes with a text box for detail. And for most organizations, the honest answer is: we don't actually know.
That's a problem, because this isn't a survey. Answers on a cyber-insurance questionnaire typically become part of the application, and the application typically becomes part of the policy record. Misrepresentation on an application — even an unintentional one — can jeopardize coverage, and insurers have contested claims where security attestations were later found to be inaccurate. Policies, wordings, and jurisdictions differ widely, so nothing here is legal advice, and your own policy terms are the only ones that matter: read them, and ask your broker how your insurer treats application accuracy. But the practical takeaway is consistent — the risky move is not answering "yes." It's answering blind.
Why Nobody Can Answer This Question Honestly
Most organizations genuinely do not know what unsupported software is running in their environment, and the reasons are structural rather than negligent:
- Shadow IT. The marketing team's self-hosted analytics box, the file-transfer server a departed employee set up, the workload someone spun up in a corporate cloud account outside the standard image. None of it appears in the CMDB.
- Transitive dependencies. Your application may be current while the runtime underneath it is not. A modern web application running on an end-of-life PHP or Node.js version is unsupported at the layer attackers actually target.
- Appliances and embedded systems. Firewalls, NAS devices, badge systems, and conference-room hardware all run operating systems with lifecycles their owners rarely track. The vendor's logo on the box says nothing about whether the Linux underneath still gets patches.
- The CVE blind spot. This is the subtle one. Vulnerability scanners report known CVEs. But software that is past end of life stops receiving patches — and often stops receiving the vendor attention that produces advisories in the first place. A clean scan and a dead operating system can coexist comfortably. Your scanner is answering "what known vulnerabilities do you have?" while the insurer is asking "what software would never be patched if a vulnerability appeared tomorrow?" Those are different questions. (We've written more about this in The CVE Blind Spot.)
So when the questionnaire lands, the person filling it out typically has three inputs: a vulnerability scan that wasn't designed to answer the question, an asset inventory of uncertain freshness, and a gut feeling. That's not a foundation you want underneath an attestation.
What "Unsupported" Actually Spans
The category is broader — and more recent — than most executives assume. These are not obscure legacy systems; they are products that were mainstream defaults within the last five years:
| Product | End of Life | Status | Where it hides |
|---|---|---|---|
| Windows 10 (22H2) | October 14, 2025 | EOL | Desktops, kiosks, warehouse and lab machines that "still work fine" |
| CentOS 7 | June 30, 2024 | EOL | Long-lived servers, internal tools, vendor appliances built on it |
| PHP 7.4 | November 28, 2022 | EOL | Websites, intranets, and CMS installs that predate the current team |
Windows 10 is the one most likely to surprise the boardroom: an operating system that was on the majority of corporate desktops until very recently has been out of standard support since October 2025. If any machine in the fleet hasn't moved to Windows 11 or onto a paid extended-update program, the honest questionnaire answer is already "yes."
The Fine Print Caught Up: Exclusions, Sublimits, and Rescission
For years, the questionnaire was where end-of-life software met your insurance. That era is ending: the same question is now migrating from the application into the policy wording itself. Three documented mechanisms — a named policy peril, an application-keyed exclusion, and outright rescission — show how the answer you give (or can't give) plays out after a breach. All three are verifiable at the source.
The named peril: end-of-life software written into the policy definition
Chubb's Cyber Enterprise Risk Management form — the V2.2 international specimen is publicly posted by the Lloyd's Market Association — defines a Neglected Software Exploit as the exploitation of a vulnerability in software, firmware, or hardware that, as of the first known date of exploitation, "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," or that carries a published CVE whose patch was available but not applied. Losses arising from that peril don't flow through the policy like ordinary losses: the schedule carries a separate Neglected Software Exploit sublimit, its own excess, and a co-insurance percentage set against day-range bands — 0–45, 46–90, 91–180, 181–365, and longer than 365 days. In plain terms: the longer the software has been dead or the patch has sat unapplied, the more of the loss the policy is built to leave with you. This is not an insurer arguing an exclusion after the fact — it is end-of-life status as a defined, rated peril with its own line on the schedule.
The application-keyed exclusion: Columbia Casualty v. Cottage Health
In 2015, Columbia Casualty (a CNA company) sued its own insured, Cottage Health System, to claw back roughly $4.1 million it had paid defending and settling a data-breach class action. The complaint invoked an exclusion for "Failure to Follow Minimum Required Practices": the policy made it a condition of coverage that the hospital "continuously implement" the risk controls it had described in its insurance application. The case was ultimately dismissed on procedural grounds — the policy's dispute-resolution clause — rather than decided on the merits. But the structure it exposed is the durable lesson: on that policy form, the application's security answers functioned as a warranty, with an exclusion keyed to any failure to live up to them. Your questionnaire answer about unsupported software can be exactly that kind of answer.
The rescission: Travelers v. International Control Services
In 2022 the theory stopped being theoretical. After International Control Services suffered a ransomware attack and claimed on its cyber policy, Travelers sued in federal court alleging the application had misrepresented the company's use of multi-factor authentication. Within two months, the parties stipulated to a judgment rescinding the policy — void from inception. Not a denied claim: an unwound policy, as if it had never existed. The misrepresentation there concerned MFA, not end-of-life software — but the mechanism does not care which application question was answered wrong, and the EOL question sits on the same application.
The 4-Step Honest-Answer Playbook
The good news: converting "we don't know" into a defensible answer is a bounded project, not a transformation program. Four steps.
Step 1 — Build the inventory
Start with what can be enumerated mechanically. The free endoflife.ai scanner reads dependency files and operating-system versions and flags anything past — or approaching — its end-of-life date. Run it against your repositories and your server estate first; that covers the layers a questionnaire is most concerned with and produces a written artifact you can date-stamp.
Step 2 — Resolve the ambiguous cases
Every environment has products the scan can't see or can't classify: the appliance firmware, the database version someone reads off a login banner, the framework a contractor mentioned. Check each one against the checker or, if you want this wired into your own tooling, the API. Each product's page also carries its EOL Risk Score, which helps you triage which findings deserve budget conversations first.
Step 3 — For what's dead: migrate or bridge
Anything past end of life gets one of two treatments. Either it's migrated — the permanent fix — or, where migration can't land before renewal, it's bridged with commercial extended support, which keeps security patches flowing for EOL versions while the migration completes. This is the step that changes the character of your questionnaire answer: "yes, with compensating support coverage and a migration deadline" is a managed risk an underwriter can price. "Yes, unmanaged" — or worse, a "no" you can't back up — is not.
Step 4 — Put every remaining date on the calendar
The reason this question hurts every year is that lifecycles move and inventories rot. Every product page on endoflife.ai offers an .ics calendar reminder for its end-of-life date — subscribe your team to every date that survives steps 1–3, or use EOL Watch to get notified as dates approach and change. Done once, next year's renewal question becomes a five-minute lookup instead of a scramble.
One Inventory, Three Audiences
The insurance questionnaire is not the only place this question shows up. PCI DSS assessments probe whether system components are protected from known vulnerabilities and kept current, and SOC 2 auditors routinely examine how an organization identifies and remediates aging, unpatched software as part of its vulnerability-management story. The framing differs, but the underlying question — do you know what you run, and is it still receiving patches? — is the same one your insurer is asking. Which means the inventory you build in the playbook above isn't a single-purpose insurance exercise: the same date-stamped artifact serves the renewal, the PCI assessment, and the SOC 2 audit. We cover the audit side in more depth in EOL Risk Scores and Compliance and The Compliance Risks CISOs Inherit.
The CFO Postscript
For the finance leader countersigning the application: this is one of the few security questions where the fix is cheap relative to the exposure. An inventory scan is free, extended-support bridges are a known line item, and migrations were already on the roadmap — the questionnaire just moved up their deadline. What you're buying with the playbook isn't just a cleaner renewal; it's the ability to sign an attestation you know to be true. Whatever your policy's terms turn out to mean, that position is never the wrong one to be in.
Frequently Asked Questions
What counts as "unsupported software" on a cyber-insurance questionnaire?
Wording varies by insurer, but the question generally targets software that no longer receives security patches from its maintainer — end-of-life operating systems, retired language runtimes and frameworks, and appliances whose vendors have ended support. Examples include Windows 10 22H2 (EOL October 14, 2025), CentOS 7 (June 30, 2024), and PHP 7.4 (November 28, 2022). If the scope is unclear, ask your broker or insurer how they define it.
Is it worse to answer "yes" to running end-of-life software, or to answer inaccurately?
An accurate answer with a documented plan is generally the safer position. Applications typically become part of the policy record, and insurers have contested claims where security attestations were later found to be inaccurate. Policies and outcomes vary — read your own terms and talk to your broker — but a truthful "yes, with a migration plan and compensating support coverage" is a very different answer from an unverified "no".
Does commercial extended support change how you answer the question?
It can change the substance of your answer. Software past its maintainer's end-of-life date that is covered by a commercial extended-support contract is still receiving security patches — so instead of "yes, unmanaged," you can disclose "yes, with compensating support coverage in place while migration completes." Whether an insurer treats that differently is up to the insurer; disclose it accurately and let them assess it.
Can an insurer actually deny or claw back a claim over end-of-life software?
The mechanisms exist and have been used, though outcomes always depend on the specific policy and facts. Chubb's Cyber ERM form defines a "Neglected Software Exploit" — explicitly including software at "end-of-life or end-of-support status" — as a separately sublimited, co-insured peril. In Columbia Casualty v. Cottage Health (2015), an insurer sued to recover breach payouts under an exclusion keyed to the security practices described in the application. And in Travelers v. International Control Services (2022), a policy was rescinded — void from inception — by stipulated judgment after an application misrepresentation came to light following a ransomware claim. Read your own policy wording and ask your broker which of these structures it carries.
How do I find end-of-life software in my environment before renewal?
Scan dependency files and OS versions with the free scanner, check ambiguous products with the checker or the API, and cross-reference against per-version EOL pages. Then subscribe to the .ics reminders on each product page — or use EOL Watch — so the inventory stays current for next year's renewal.