Legacy Systems & Cyber Insurance

For years, cyber insurance was a light-touch product: a short questionnaire, a modest premium, a policy in the drawer. That era is over. As losses mounted across the market, carriers rebuilt how they underwrite — and the new approach treats your security posture as the thing being priced. The questionnaire that used to ask a handful of yes/no questions now reads like a security audit, and one of the things it asks about, directly, is unsupported and end-of-life software.

That makes cyber insurance the second place — alongside the compliance audit of Part 4 — where an unsupported system is formally assessed by someone outside your organization, with money attached to the answer. This part explains how legacy software enters the underwriting conversation, why the questionnaire has quietly become a baseline security standard, and how modernization changes what you can put on the form. As with Part 2, this is a conceptual model, not insurance advice — your broker and your policy are the authorities on your specific coverage.

Why underwriting changed

The shift is straightforward to understand: carriers cannot profitably insure risks they cannot assess, and a wave of losses taught the market that security posture varies enormously between insureds who look similar on paper. So underwriting moved upstream, into the controls. Instead of pricing on industry and revenue alone, carriers now price on whether the controls that actually prevent and contain incidents are present and working.

This has a side effect worth naming plainly, because it is mostly positive: the underwriting questionnaire has become a de facto baseline security standard. The questions carriers converged on — supported and patched systems, multi-factor authentication, access control, logging and monitoring, backups and recovery — are a reasonable summary of hygiene that reduces both the likelihood and the cost of an incident. Whatever you think of the insurance market, the questionnaire is a useful checklist, and an organization that can answer it honestly and well is genuinely in better shape.

Where legacy software enters the conversation

Unsupported software shows up in underwriting through the same mechanism as in compliance: it is the answer to a question the form now asks. Carriers want to know, in various phrasings, whether you run end-of-life or unsupported systems, how you patch, and what compensates where you cannot. Legacy systems collide with several of those questions at once:

• Unsupported runtimes and operating systems — the Windows Server and .NET Framework situation from Part 5 is exactly what these questions are designed to surface.
• Patching cadence — a system that cannot be patched cannot meet a patching-cadence expectation, and saying so honestly is a mark against the posture.
• Access control and segmentation — older systems often lack the granular controls and network segmentation the questionnaire assumes.
• Logging and monitoring — the same gap that produces audit findings produces an unfavorable underwriting answer.

The effect of unfavorable answers varies by carrier and by the system’s actual exposure, and it is not a single lever. Depending on the situation it can show up as a higher premium, a narrower scope of coverage, specific exclusions or sub-limits, additional required controls as a condition of coverage, or — at the sharper end — difficulty placing the coverage at all. The point is not that any one of these is guaranteed, but that an unsupported system is now a priced characteristic rather than an invisible one.

The questionnaire, control by control

Modern cyber-insurance applications converged on a fairly consistent set of controls after the loss years of the early 2020s. The exact wording varies by carrier, but the control areas repeat, and a legacy estate tends to answer several of them the same unflattering way. The table below maps the recurring questions to how an aging estate usually answers today and what modernization changes about that answer. This is a general model, not any single carrier’s form.

Control area	What the questionnaire asks	How a legacy estate often answers	What modernization changes
Supported software	Do you run end-of-life or unsupported systems?	Yes, several in the core	Retires them onto supported platforms
Patching cadence	How fast are critical patches applied?	Slowly or not at all on the legacy core	Restores the ability to patch on a schedule
Multi-factor authentication	Is MFA enforced for remote and privileged access?	Partial, because old systems cannot enforce it	Modern auth makes MFA native
Least-privilege access	Are privileged accounts controlled and separated?	Broad, shared, hard to scope down	Granular roles by default
Logging and monitoring	Do you log and monitor for intrusion?	Sparse or absent on legacy components	Logging built in and exportable to a SIEM
Network segmentation	Is the sensitive estate segmented off?	Flat network, legacy sitting in the blast radius	Segmentation designed into the target architecture
Backup and recovery	Are backups tested and recoverable?	Backups exist, recovery is unproven	Modern, tested recovery paths
Endpoint detection	Is EDR deployed across servers and endpoints?	Unsupported operating systems cannot run current EDR	Supported platforms run current tooling

Read down the third column and you have a plain-language description of why an aging estate underwrites poorly. Read the fourth and you have the agenda modernization is already executing for other reasons. The questionnaire did not invent these controls. It codified the hygiene that reduces both the odds and the cost of an incident, which is why the same list keeps showing up in audits, frameworks, and now insurance forms.

The accuracy issue, stated carefully

There is a second dimension that deserves precision, because it is easy to get wrong in both directions. Insurance coverage rests on the accuracy of what you declare. If a loss later traces back to a system, and there is a gap between what was declared on the application and what was actually true — or between controls that were attested to and controls that were maintained — that gap can complicate or contest a claim.

This is worth stating without drama: it is not unique to legacy software, and it is not a hidden trapdoor. It is the ordinary principle that insurance responds to accurately represented risk. The practical lesson is not “old software voids your policy” — that overstates it and is the kind of alarmism this series avoids. The lesson is narrower and more useful: answer the questions accurately, and keep doing what you attested to. An honestly declared EOL system, with the compensating controls you described actually in place, is a known and insurable risk. An undeclared one, or one where the declared controls quietly lapsed, is where the trouble lives. The specifics of any policy are a matter for your broker and the contract language, not for an article.

How modernization changes the renewal

The reason this part sits in a modernization series is that the questionnaire is answerable — and modernization is largely the work of changing the answers from unfavorable to favorable. Moving off unsupported runtimes restores the ability to patch. Re-architecting onto a modern foundation brings the access control, segmentation, and logging carriers expect. Each of those is a question that flips.

The slice-by-slice approach has a specific advantage here that a big-bang program does not. Because you clear the highest-exposure components first, the underwriting picture can improve progressively — you do not have to wait until the entire estate is modern to give better answers at the next renewal. Retiring the internet-facing, sensitive-data, unpatchable component this year is both the biggest security win and the most material change to the questionnaire, and you can show it as done while the longer program continues. Modernization turns the renewal from a conversation about a posture you cannot change into one about a posture that is measurably improving.

Two honest limits

First, do not modernize for the insurance — modernize because the underlying risk is real, and let the better renewal be a benefit that follows, not the justification. A system that genuinely warrants a documented risk acceptance for compliance probably warrants the same posture with an insurer: declare it accurately, compensate appropriately, and price it in. Chasing a marginally better premium is not a reason to spend a modernization budget. Second, this article cannot tell you how your carrier will treat your system or your claim. Underwriting standards vary, policy language varies, and the market keeps moving. Use this to understand why legacy software has entered the conversation and to prepare honest, well-supported answers — then have the actual coverage conversation with the people who write the policy.

Where this leads

Audits and insurance renewals are both events with dates — and reacting to them under deadline is what produces the rushed decisions this series keeps warning against. The way out of perpetual reaction is to see the dates coming. Part 7, Vendor-Support Clock: Planning Around EOL Dates, is about building the inventory and the calendar that turn end-of-life from a recurring surprise into a managed schedule — so the audit and the renewal find you already moving.