The compliance and insurance risk hiding in your unsupported systems

Cyber insurance: the question you now have to answer

Cyber-insurance underwriting has tightened sharply. Application and renewal forms now ask, in plain language, whether you run any unsupported or end-of-life operating systems and software. That question exists because unpatched legacy systems are a common root cause of the claims insurers pay out on.

Answering it carelessly cuts three ways. Say yes and you can expect a higher premium or a specific exclusion for those systems. Say no when the answer is really yes, and you have misrepresented your risk, which is exactly the kind of gap an insurer can use to reduce or deny a payout after an incident. And if an end-of-life system turns out to be the entry point for an attack, the presence of known-unsupported software makes the "reasonable security" argument much harder to win. The honest, defensible position is to know precisely what you run and to have a dated plan to remove it.

How the major frameworks treat unsupported software

No serious framework says "it still boots, so it is fine." They converge on the same expectation: systems should be supported and patched, and anything that cannot be must be isolated, documented and time-limited.

• PCI DSS. Systems in scope must run supported software with security patches applied. Where a component cannot be patched, the standard expects it to be documented and protected with compensating controls, not quietly left in production.
• Cyber Essentials (UK). The bluntest of the lot. Devices running software that is no longer supported or no longer receiving security updates fail certification unless that software is removed or fully segregated. There is no partial credit.
• HIPAA Security Rule (US). Requires reasonable and appropriate safeguards for systems handling health data. An unsupported operating system holding patient records is difficult to defend as reasonable, and features in real enforcement findings.
• ISO 27001. Its controls for asset management and technical vulnerability management assume you know what you run and keep it remediated. Unsupported software that can never be patched directly undercuts those controls.
• NIS2 (EU). Raises the bar on risk management and holds management personally accountable for it. Known, undocumented end-of-life systems are exactly the kind of unmanaged risk it is designed to surface.

Why this is really an inventory problem

Almost every one of these obligations reduces to a single practical requirement: know what you run and know when its support ends. You cannot document, isolate or plan around a system you have forgotten about, and the forgotten ones are precisely the systems that reach end-of-life unnoticed. A current inventory with a support-end date against every item is not paperwork. It is the evidence that turns "we think we are fine" into "here is exactly what we run, here is what is unsupported, and here is the dated plan to fix it," which is the answer both auditors and insurers actually want.

What to do about it

• Inventory everything, with end-of-support dates. Operating systems, databases, network hardware and firmware. The date is the part most inventories are missing and the part every assessor asks for.
• Flag what is already unsupported or close to it. Set a warning window so systems surface before, not after, they lose support. This is the core of practical lifecycle management.
• Isolate and compensate where you cannot replace yet. Segment the system, restrict access, and apply extra monitoring. Buy Extended Security Updates where the vendor offers them.
• Document the risk and the plan. A dated remediation plan is what an auditor accepts and what supports an honest insurance declaration.
• Replace on a schedule, not in a panic. Tie refreshes to the budget cycle so unsupported systems are retired before they become findings.

Keep reading

For the operational side of the same problem, see what actually happens when hardware goes end-of-life and the running list of upcoming end-of-support deadlines. New to the terminology? Start with EOL vs EOS vs EOSL.