Every estate has one. The server nobody dares to touch, the appliance whose vendor stopped answering, the production system whose control software certifies nothing newer. This week we published the dates for four categories of them: FortiGate hardware, the Windows Server estate, Server 2016 specifically and WatchGuard Fireboxes. This article answers the question that sits above all of them: when something in your infrastructure is end-of-life and cannot be replaced right now, what does NIS2 actually require you to do about it?
The public debate offers two bad answers. Vendors say: replace everything, immediately. Sceptics say: NIS2 doesn’t literally ban old software, so relax. Both miss how the law works. NIS2 does not prohibit end-of-life systems; it prohibits unmanaged ones. The difference between the two is a process you can document, and this guide walks through it.
What Article 21 actually demands
Article 21 of the NIS2 directive requires “appropriate and proportionate” technical and organisational measures, referenced against the state of the art. Its ten measure categories touch end-of-life assets repeatedly, and the Commission’s implementing regulation (EU 2024/2690) turns them into auditable controls:
| Article 21 measure | What it means for an EOL system |
|---|---|
| Risk analysis and system security (21.2.a) | Every unsupported asset is a quantifiable vulnerability: it must be formally assessed, and residual risk needs written management approval |
| Maintenance and vulnerability handling (21.2.e) | When vendor patches stop, the implementing regulation (§6.10.3) requires an active mitigation plan or a substantiated alternative risk treatment |
| Cyber hygiene (21.2.g) | Deprecated protocols disabled, default credentials gone, hardened baselines on every legacy interface |
| Access control and asset management (21.2.i) | An inventory that tracks lifecycle status per asset, plus least-privilege access to anything unsupported |
| MFA and network segmentation (21.2.j) | Legacy platforms without native MFA must sit behind an identity-aware proxy that enforces it before connections arrive |
| Business continuity (21.2.c) | EOL systems may not create unrecoverable failure: immutable backups and tested recovery apply to them first |
Read together, the statute’s position is coherent: proportionality (Article 21.1) acknowledges that instant modernisation of every IT and OT asset is impossible, and the implementing regulation explicitly accepts compensating measures where patching cannot happen. The same legacy server is non-compliant on a flat corporate network and defensible inside a documented, isolated enclave. The law regulates the management, not the birth year of the software.
The Belgian layer: CCB, CyFun and the board
Belgium transposed NIS2 through the law of 26 April 2024, in force since 18 October 2024, with the Centre for Cybersecurity Belgium (CCB) as supervisor. Essential entities face proactive audits and fines up to €10 million or 2% of worldwide turnover; important entities face incident-triggered supervision and up to €7 million or 1.4%. Full implementation of the designated CyFun controls is expected by 18 April 2027, a deadline that is now inside most budget horizons.
CyFun, the CCB’s assurance framework, is where end-of-life management becomes concrete. Its asset-management controls require inventories that record vendor support lifecycles; its bluntest line states that unsupported hardware without exception documentation is designated as unauthorised, to be quarantined, disconnected or replaced. Its protect-tier controls (segmentation, access control, maintenance with structured exception workflows) map exactly onto the compensating-controls logic above, which is why we anchored our earlier guides to them, from the NIS2 compliance checklist to the mapping of NIS2 security measures to SASE controls.
Article 20 puts names under all of this: management bodies must approve the risk measures, oversee implementation, and can be held personally liable for gross negligence, up to temporary bans from executive functions. A knowingly unmanaged EOL system is exactly the fact pattern that liability was written for; we covered the governance side in what boardroom liability means in Belgium.
How big the problem really is
The numbers say EOL systems are not a corner case but a primary attack surface. ENISA’s Threat Landscape 2025, built on 4,875 validated European incidents, puts vulnerability exploitation at 21.3% of initial access (second only to phishing at 60%) and ransomware at 81.1% of cybercrime events. VulnCheck’s exploitation research adds the lifecycle dimension: over 40% of actively exploited vulnerabilities in 2025 involved products at or past end of life, roughly two-thirds of botnet-building flaws sat in unmaintained devices, and, critically, only about a quarter of exploited EOL edge flaws ever appeared in CISA’s KEV catalogue. You cannot patch-list your way around an unsupported estate; three-quarters of what hits it is not on the list.
The insurance data completes the picture. Coalition’s claims analysis found organisations running unsupported software three times as likely to suffer an incident, and a single unresolved critical vulnerability raising claim likelihood by a third. Across the market roughly one in five cyber claims is denied or only partially paid, and 82% of denied-claim disputes involve missing or incomplete MFA, precisely the control legacy platforms lack natively. Underwriting has shifted from questionnaires to evidence: policies now carry explicit EOL exclusions unless the insured maintained a written exception supported by compensating controls.
The defensible process, step by step
1. Inventory with lifecycle status. Every asset (hardware, OS, software, embedded devices) recorded with owner, criticality and vendor support dates. If your inventory cannot answer “what goes end-of-life in the next 18 months?”, start here; nothing downstream works without it.
2. Risk-assess each EOL asset. Three questions per system: how exposed is it (internet-facing, DMZ, internal)? Are there known CVEs with public exploit code for it? What breaks, costs and must be reported if it is compromised? Write the answers down; this document is half of your audit defence.
3. Route it through the decision tree.
- Can it be replaced or modernised now? Yes → execute the migration and verify secure disposal. No ↓
- Are extended security updates (ESU) commercially available? Yes → buy the patch stream and isolate the asset; ESU narrows the gap but never covers everything and always ends. No ↓
- Can rigorous compensating controls be engineered? Yes → isolate (next step) and document formal risk acceptance. No ↓
- None of the above → disconnect it. An unpatchable, un-isolatable, critical-flaw system has no defensible place on a network.
4. Apply compensating controls, in order of effect. Tier one is network isolation: the asset moves into a dedicated zero-trust segment with no direct internet route in either direction, cloaked behind identity-gated access so nothing connects without authentication and MFA. Tier two is protocol discipline: deprecated protocols (SMBv1, raw RDP, unencrypted legacy services) stripped or brokered at the boundary. Tier three is hardening and watching: minimal local services, endpoint protection in lockdown mode, and all traffic to and from the enclave logged off-host with anomaly detection. This is the same architecture whether the asset is a Windows server, an IP camera or building management system, or a fleet of Windows 10 endpoints.
5. Build the evidence dossier. Five documents per asset: the inventory entry; the risk assessment; the business justification for retention; the compensating-controls specification with network diagrams and policy exports; and a board-signed risk acceptance with a review date within twelve months. This dossier is what a CCB auditor requests, and what an insurer’s forensic team looks for before deciding whether your claim gets paid.
What auditors and insurers actually check
Supervision under NIS2 is technical, not administrative. A CyFun-based review cross-references your device inventory against vendor EOL databases, asks for the exception documentation on anything unsupported, and verifies that claimed isolation is real: firewall policies exported, segment traversal tested, MFA enforced at the proxy. Insurers have converged on the same method, replacing self-attestation with perimeter scans and exportable evidence. The pattern in both cases rewards the same behaviour: organisations that can show a managed, isolated, documented legacy estate keep their certification and their coverage; organisations with the identical technology and no paper trail lose both. Documentation is not the security; it is the difference between an engineering decision and negligence with the same hardware.
The pushback, answered
“NIS2 doesn’t literally ban EOL software, so this is optional.” Correct premise, wrong conclusion. The duty of care standard means knowingly running an unmitigated, publicly vulnerable system breaches Article 21 even though no article names your software version. Permissible and unmanaged are different things; the whole framework above exists because the first is real and the second is sanctionable.
“Our auditor never asked about legacy servers.” Under NIS1, probably true: fragmented enforcement, policy-level reviews. The CyFun regime asks for evidence of implementation (inventories, segmentation, access control) and the 2027 conformity deadline is what changes the audit you had into the audit you will get.
“Documentation is theatre; paperwork stops no attackers.” Half right. Documentation without isolation is theatre. But the dossier is not meant to stop attackers; the controls do that. The dossier determines what happens afterwards: whether the incident reads as managed risk or gross negligence, whether the fine lands on the entity or the directors, whether the claim is paid. Both halves are load-bearing.
“We’re 120 people; NIS2 is for the big players.” The size-cap rule says otherwise: 50 employees or €10 million turnover in one of 18 sectors makes you an important entity. And even below the thresholds, Article 21’s supply-chain measure pulls you in indirectly: your essential-entity customers are now obliged to audit your lifecycle management as part of their own compliance.
Make the unpatchable defensible
You will not replace everything before its date; nobody does. What you can do is close the gap between what you run and what you can defend: inventory the estate, risk-assess the stragglers, route each one through the decision tree, isolate what stays, and sign the paper. The isolation tier is where Jimber does the heavy lifting: our EU-sovereign platform’s ZTNA network isolation puts unpatchable systems behind identity-gated, MFA-enforced access with no inbound exposure, and generates the access logs your dossier needs, deployed in days at a predictable flat rate. Book a demo and bring your inventory’s worst page; we will show you what defensible looks like for it.
Frequently asked questions
Does NIS2 ban end-of-life or unsupported software?
No. NIS2 mandates appropriate, proportionate risk management reflecting the state of the art. Running unsupported systems unmanaged on an open network violates that duty of care, but retaining them within a documented framework of isolation, restricted access and formal risk acceptance remains legally defensible.
What counts as a defensible compensating control for an unpatchable system?
A measure that reduces the unpatched risk to an acceptable, evidenced level: network micro-segmentation or full isolation, removal of direct internet exposure, identity-gated access with MFA enforced in front of the asset, protocol filtering, and continuous monitoring, all documented against the implementing regulation’s controls.
Who is personally liable when an EOL system causes an incident?
Under NIS2 Article 20 and the Belgian law of 26 April 2024, the management body. Boards must approve and oversee cybersecurity measures; gross negligence, such as knowingly operating unmitigated unsupported systems, can trigger personal sanctions up to temporary bans from managerial functions.
Can my cyber insurer refuse a claim because of end-of-life software?
Yes. Policies increasingly carry explicit EOL exclusions, and insurers treat undeclared legacy systems as material misrepresentation. Claims data shows 82% of denied-claim disputes involve missing or incomplete MFA. A documented exception with verified compensating controls is what keeps coverage enforceable.
What must I document to keep an EOL system compliant?
Five things: the asset-inventory entry with lifecycle status; a formal risk assessment; a business justification for delayed replacement; the technical specification of active compensating controls, including diagrams and policy exports; and a signed executive risk acceptance with a review date no more than twelve months out.
Does network isolation satisfy a CCB auditor, or is replacement mandatory?
Isolation is an explicitly recognised compensating control under the implementing regulation and CyFun’s protect controls. It must be technically enforced (firewall or gateway policies preventing lateral traffic and direct internet exposure) and paired with exception documentation; on that basis, replacement is not mandatory.
What is the difference between essential and important entities in Belgium?
Essential entities (larger organisations in critical sectors) face proactive, systematic CCB audits and fines up to €10 million or 2% of worldwide turnover. Important entities, typically mid-market from 50 staff or €10 million turnover, face incident-triggered supervision with fines up to €7 million or 1.4%.
Is monitoring the CISA KEV catalogue enough for legacy assets?
No. KEV-listed flaws demand immediate action, but research shows only about a quarter of actively exploited vulnerabilities in end-of-life edge devices ever reach the catalogue. Unsupported assets must be treated as vulnerable by default and isolated proactively rather than patch-listed reactively.
