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 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.
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.