Cyber Insurance, Legacy Systems & Claim Denial

A cyber policy feels like a settled question right up until the moment you need it. The premium is paid, the certificate is in the folder, the box on the risk register is green. Then a breach happens, the claim goes in — and the denial letter arrives, citing a control you were supposed to have, or an answer on the application that no longer matches reality. For a company running an unsupported system, that letter is not a freak event. It is the predictable end of a gap that was visible the whole time.

This page is educational, not legal or insurance advice. It is about one specific outcome — claim denial — and how legacy systems quietly set it up. (For closing a control an underwriter flags before a claim, see the companion guide on cyber insurance remediation; this page is about the denial itself.)

How a cyber claim gets denied

Insurers rarely deny a claim by saying “your system was too old.” The denial comes through one of a few well-worn mechanisms, and legacy systems feed most of them.

Denial reason	What triggers it
Material misrepresentation	An answer on the application was wrong, such as attesting to MFA that wasn’t in place. The insurer can rescind the policy, treating it as void from inception rather than merely denying the claim.
Unmet attested control	A control the policy required, such as timely patching, MFA, or removal of end-of-life software, wasn’t actually maintained when the breach hit. Industry reporting through 2025 has described a rising share of denials tied to failure to maintain attested controls specifically.
Unsupported-software exclusion	The policy excludes losses that involve end-of-life or unsupported software, or failure to follow the “minimum required practices” the insured described.
Known-unpatched-vulnerability exclusion	The breach exploited a vulnerability that was left unpatched past a window the policy set.
War or nation-state exclusion	The loss is attributed to a hostile state action and barred by a war or cyber-war exclusion, regardless of how strong the controls were.

Three disputes show how these play out. We cite them as illustration, not prediction:

• Travelers v. International Control Services (2022). After ICS suffered a ransomware attack and filed a claim, Travelers moved in federal court to rescind the policy, alleging ICS had attested to using MFA for privileged access when it had not in fact done so. The parties subsequently filed a stipulation to rescind the policy and declare it void from inception. The lesson the brokers drew was blunt: the attestations on a cyber application are conditions, and getting them wrong can void coverage.
• Columbia Casualty v. Cottage Health. A CNA unit sought to avoid coverage for a data-breach settlement by invoking a “minimum required practices” exclusion tied to the security controls the insured had represented in its application. The case turned on procedural grounds, but the structure of the dispute — coverage contested against the controls the insured claimed to maintain — is now a standard feature of the market.
• Merck v. ACE American (the NotPetya dispute). After the 2017 NotPetya attack caused Merck roughly $1.4 billion in losses, its insurers denied under a war exclusion, arguing the malware was a Russian state action against Ukraine. As reported, a New Jersey court ruled in 2022 that the traditional war exclusion did not apply to a cyberattack of that kind, and an appellate panel affirmed in 2023 before the parties settled. That claim ran under an all-risk property policy rather than a standalone cyber policy, but it is why explicit cyber-war and nation-state exclusions are now standard language, wording a current denial can lean on where the older exclusion failed.

The common thread is not age. It is the gap between what the policy assumed and what the system could actually do — and a legacy system is a reliable source of that gap.

Where legacy systems create the denial

An unsupported platform maps onto the denial mechanisms with uncomfortable precision:

What the policy assumes	Where a legacy system creates a denial risk
Critical vulnerabilities patched on an SLA	An unpatchable platform structurally cannot meet any patch deadline — the patch will never ship
End-of-life software removed or restricted	The flagged system is the end-of-life software — there is nothing to patch to
MFA across remote and privileged access	Older platforms often can’t enforce modern access controls, undermining an MFA attestation
Attestations on the application hold true	A control the legacy system can’t deliver puts any attestation about it at risk of misrepresentation

The exposure is well-founded from the insurer’s side. A missing MFA control is one of the most commonly cited reasons a cyber claim is denied — a sign of how directly a missing control bears on whether a claim is paid. Unsupported systems are flagged precisely because they are a leading source of preventable, hard-to-defend incidents, and because they so often sit behind the exact control the policy was counting on.

There is a quieter cost too: non-renewal. An insurer that won’t deny a claim may simply decline to renew, or attach an exclusion that hollows out the coverage, once it learns an unsupported system is in the environment. The risk doesn’t have to materialize as a denial to cost you the protection.

How we close the gap before a claim tests it

The only reliable way to avoid a denial is to close the gap before the breach — and, just as important, to be able to prove the control is real rather than merely attested. Underwriters and claims adjusters credit evidence, not assurances.

If the gap is an unpatchable, end-of-life platform, the durable fix is getting off it — and the practical way to do that without disrupting the business is slice by slice. The flagged system is modernized slice by slice, the control-critical path first, behind a strangler facade so the legacy keeps serving while the supported replacement is built beside it. Each slice is proven to behave identically to the legacy before it carries live traffic, so closing the gap never means risking a regression. AI-accelerated discovery reads the system end to end and captures its actual behavior and dependencies under senior-engineer review, so the work targets the real control gap rather than a guess at it. The output is exactly what a claim would demand: a documented, validated trail of change — the tickets, the scan results, the audit record — that demonstrates the control was real and in place. That is the difference between an attestation you can defend and one that voids your policy.

What we can’t tell you

This is educational, not legal or insurance advice; coverage questions belong to your broker and counsel, and every policy is its own contract. Modernization is not the universal answer to a coverage gap — some attested controls can be satisfied honestly and quickly without touching a legacy system, by enabling MFA, tightening access, or restricting a system’s network exposure, and where that genuinely closes the gap, that is the right move. We’ll be candid about which gaps a stop-gap closes and which only a migration off the platform will. And if the control a claim would turn on has nothing to do with a legacy system, the right fix may not involve us at all. We’ll say so.

Where to start

The first step is to read your policy’s required controls against your actual systems and find where a claim would fail — before a breach finds it for you. A discovery call scopes the controls a claim would test, which gaps are a quick fix, and which need a migration off an unsupported platform, on evidence rather than a pitch. The cyber insurance remediation guide covers closing an underwriter-flagged control on a renewal timeline, and the legacy system liability assessment maps the broader exposure. Reach the team at sales@modernlift.ai.