NIS2 and End-of-Life Software: The Patching Obligation You Can't Meet With Dead Components

Last updated: July 17, 2026  ·  For security, infrastructure, and compliance owners at essential and important entities in the EU

Most NIS2 coverage focuses on who is in scope and how fast you must report an incident. But there is a quieter collision inside Directive (EU) 2022/2555 that almost nobody prices in: the directive's risk-management measures assume that when a vulnerability appears, you can do something about it. For most of your estate, that holds — a patch ships, you apply it, the finding closes. For an end-of-life component, there is no patch to apply. "Vulnerability handling" becomes structurally impossible for that component — not hard, not slow, impossible — and every new CVE in it stays open forever.

The nuance that changes everything: NIS2 is a directive, not a regulation. It entered into force January 16, 2023, and member states were required to transpose it into national law by October 17, 2024 — but the obligations reach your company through those national implementing laws, which vary by member state and, in some states, arrived late. Your actual obligations live in the national transposition — check the law of each member state where you operate.

What NIS2 actually asks of the entities that run infrastructure

Under the directive as adopted, NIS2 applies to "essential" and "important" entities across listed sectors — energy, transport, banking, health, drinking water, digital infrastructure, and public administration, among others — generally above size thresholds. The obligations that matter most for lifecycle management:

One caveat, woven in rather than buried in a footer: this article is not legal advice — verify specifics against your national implementing law.

The obligation you cannot meet with dead components

Walk through what "vulnerability handling" means in practice. A CVE lands in a component you run: you assess it, obtain the fix, apply it, close the finding. The whole loop depends on somebody, somewhere, still building fixes for that component. The day the component passes its end-of-life date, the loop doesn't slow down — it breaks. Every new vulnerability joins a queue that nothing ever drains.

Before NIS2, that was a security debt you could quietly carry. Under NIS2, it is a standing gap in measures you are legally required to maintain — a control that exists on paper and cannot execute in practice. And it compounds with the reporting clock: when an incident comes through an unsupported component, the 24-hour early warning and 72-hour notification force a written answer to an uncomfortable question — what was your handling plan for a component with no patches? Cyber insurers already ask the same thing in underwriting questionnaires. NIS2 asks it with a regulator on the other end.

Management accountability makes this a board question

The provision with the longest reach is not the fine — it is the accountability of management bodies for compliance oversight. Responsibility for the risk-management measures does not stop at the CISO's desk. That converts unsupported software from an engineering backlog item into a governance question with a name attached: who signed off on running unsupported software, and on what basis?

There is a defensible answer to that question, and it is not "we didn't know" — not when a real inventory would have surfaced the component in an afternoon. The defensible answer is a documented decision: an inventory, a risk ranking, a migration plan for what can move, and extended-support coverage bridging what cannot move yet. Boards that can produce that paper trail are managing a risk. Boards that cannot are discovering one.

What a real inventory finds in NIS2 sectors

These are the components that surface first when entities in NIS2 sectors run an honest inventory — each date verified against its lifecycle page:

Component EOL Date Status Where it turns up
Windows Server 2012 Oct 10, 2023 EOL Domain controllers and operational back-ends in utilities and health environments, nearly three years past EOL
PHP 7.4 Nov 28, 2022 EOL Public-sector web portals and citizen-facing services still running a runtime unpatched since 2022
Ubuntu 20.04 May 31, 2025 EOL Server fleets and container base images across every sector — standard support ended over a year ago
SQL Server 2016 (SP3) Jul 14, 2026 EOL this week Billing, records, and patient-data databases in banking and health — support ended three days ago

Note the spread: two components that died years ago and got forgotten, one fleet OS that aged out quietly, and one database that crossed the line this week — part of the broader H2 2026 EOL pileup arriving in the same months national regulators are standing up NIS2 enforcement. An entity running all four is not an outlier in these sectors. It is the median.

A compliance-ready EOL process

NIS2 does not prescribe a lifecycle-management method. But "vulnerability handling" plus "management accountability" implies a process with four working parts:

1. Continuous component inventory

Not an annual audit — a living picture of what you run. Upload dependency manifests to the scanner to get lifecycle status across an entire estate at once, or check individual products with the EOL checker. For CI pipelines, gate builds on the API so an EOL component fails loudly before it reaches the infrastructure NIS2 cares about:

curl https://api.endoflife.ai/v1/status/ubuntu/20.04

2. Lifecycle dates tracked against a live source

EOL dates move — vendors extend, accelerate, and clarify them. A spreadsheet snapshot from last quarter is a stale control that falls apart under regulatory questioning. EOL Watch tracks date changes as they happen, and every product page publishes an .ics calendar feed so support deadlines sit in the same calendar as your audit and reporting cycles.

3. Risk-ranked remediation

An inventory with two hundred findings needs an order. The EOL Risk Score ranks components by how dangerous their EOL status actually is — recency, exposure, and exploitation signals — so the migration queue starts with the components most likely to produce exactly the incidents NIS2 makes reportable within 24 hours.

4. A bridge for what cannot migrate in time

Some systems will not migrate inside any reasonable window — the records platform welded to an old database, the operational system certified against one OS release. For those, commercial extended-support vendors can keep security patches flowing after the official EOL date: a patch pipeline exists again, so vulnerability handling can execute again. See the extended support vendor overview for how that market works. It is a bridge, not a destination — but it is the difference between a documented plan and an open-ended gap.

If you also ship products: NIS2 meets the CRA

NIS2 has a sibling, and many companies face both. The EU Cyber Resilience Act governs the products you ship — the software and connected devices you place on the EU market. NIS2 governs the infrastructure you run. A health-tech company that sells a connected device and operates patient-facing services is inside both at once. The remedy is the same on both sides: know your components, know their lifecycle dates, and have a plan for the ones nobody is patching. The inventory you build for one is the inventory you need for the other.

For twenty years, retiring unsupported software has been the task that is always important and never urgent. NIS2 changes its category. In the sectors the directive covers, a component nobody patches is no longer a private engineering debt — it is a gap in legally required measures, with management's name on the oversight. The entities comfortable in that world are the ones that can answer "what unsupported software are you running, and why?" with a document instead of a discovery process.

Frequently Asked Questions

Does NIS2 apply to my company?

Under the directive as adopted, NIS2 applies to "essential" and "important" entities in listed sectors — energy, transport, banking, health, drinking water, digital infrastructure, and public administration, among others — generally above certain size thresholds. But because NIS2 is a directive, the obligations reach you through national implementing laws, which vary by member state and in some states arrived late. The only reliable answer comes from checking the national transposition in each member state where you operate.

What does NIS2 require for patching and vulnerability handling?

Under the directive as adopted, in-scope entities must take cybersecurity risk-management measures that include vulnerability handling and disclosure, and must report significant incidents on a staged timeline: an early warning within 24 hours, a notification within 72 hours, and a final report within a month. Vulnerability handling presumes a working patch pipeline — which is exactly what an end-of-life component no longer has.

Is running end-of-life software a NIS2 violation?

NIS2 does not name end-of-life software directly, and the specifics depend on your national implementing law. But the directive's risk-management measures include vulnerability handling, and for a component whose maintainer has stopped shipping patches, there is no patch to apply — every new vulnerability stays open indefinitely. An unsupported component is therefore a standing gap in required measures, and hard to defend unless it is inventoried, risk-ranked, and covered by a migration or extended-support plan.

What are the penalties under NIS2, and who is accountable?

Under the directive as adopted, fines for essential entities can reach up to EUR 10 million or 2% of global annual turnover, with exact amounts set by national law. Just as important: management bodies carry personal accountability for compliance oversight — which moves "who signed off on running unsupported software?" from the engineering standup to the board agenda. This is not legal advice — verify against your national implementing law.

Related Resources