NIS2 and End-of-Life Software: The Patching Obligation You Can't Meet With Dead Components
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.
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:
- Risk-management measures. In-scope entities must take cybersecurity risk-management measures, including vulnerability handling and disclosure. This is the clause that quietly assumes a working patch pipeline.
- Staged incident reporting. Significant incidents trigger a timeline: an early warning within 24 hours, a notification within 72 hours, and a final report within a month. You cannot write those reports about a component you did not know you were running.
- Real fines. For essential entities, fines can reach up to EUR 10 million or 2% of global annual turnover, with the exact regime set by national law.
- Personal accountability. Management bodies carry accountability for overseeing compliance with the risk-management measures. This is the provision that moves the whole topic up the org chart.
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.
The Netherlands just made this concrete: the Cyberbeveiligingswet is in force
Added August 15, 2026. The Netherlands transposed NIS2 into national law today. The Cyberbeveiligingswet (Cbw) — adopted by the Dutch Senate on July 7 — entered into force on August 15, 2026, with no transition period. The registration obligation, the duty of care, incident reporting and board-level governance duties all apply from day one.
The numbers attached to it are the directive's floors, now enforceable in Dutch law: fines up to €10 million or 2% of global annual turnover for essential entities (essentiële entiteiten) and €7 million or 1.4% for important entities (belangrijke entiteiten) — plus something the headline figures miss: the competent authority can fine individual board members up to €25,000 for failures of governance oversight, on top of periodic penalty payments for continuing non-compliance.
For the subject of this article, the relevant clause is the duty of care. It requires appropriate technical measures including patching and vulnerability handling — and as the rest of this piece argues, that is the obligation you structurally cannot meet on components whose vendors no longer publish patches. A Dutch essential entity running end-of-life software after today is not waiting for a compliance deadline; it is past one. The defensible position is the same paper trail described below: inventory, risk ranking, migration plan, and documented bridging support for what cannot move yet.
For scope and registration details, the Dutch government's own guidance is at business.gov.nl.
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 – Jul 2026 | Billing, records, and patient-data databases in banking and health — support ended July 14, 2026 |
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 in July 2026 — part of the broaderH2 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.042. 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.
Is NIS2 already enforceable anywhere?
Yes, in several member states — and since August 15, 2026 that includes the Netherlands, whose Cyberbeveiligingswet entered into force on that date with no transition period. Dutch essential entities face fines up to EUR 10 million or 2% of global turnover, important entities up to EUR 7 million or 1.4%, and individual board members can be fined up to EUR 25,000 for governance failures. Registration, duty of care and incident reporting all apply from day one. Other member states are at different stages of transposition, so the enforceable national law — not the directive itself — is what determines your exposure.
Related Resources
- The EU Cyber Resilience Act Has an EOL Problem — the sibling rule for products you ship
- The H2 2026 EOL Pileup: Why the Second Half of 2026 Is Different
- Cyber Insurance and EOL Software: What Underwriters Now Ask
- Dependency Scanner — inventory a whole estate at once
- EOL Checker — look up any product's support status
- EOL Watch — lifecycle date changes, tracked live
- EOL Risk Score — how we rank EOL severity
- Extended Support Vendors — patches for components you cannot migrate yet