NIS2 Legacy Systems: The 6.6.2 Patching Derogation Doesn’t Cover the Systems You Can’t Patch

Search the NIS2 Directive for the word “legacy” and you get nothing. Not one occurrence across all 46 articles and 144 recitals. “Unsupported”, “end of life” and “outdated” are absent too. The single place the Directive concedes that a fix may not exist is Article 12(2)(c), and it is a field specification for a database, not an obligation on you.

That silence is why the market has settled on one clause — point 6.6.2 of the Implementing Regulation’s Annex, the “patching derogation” — and why almost everyone applies it to the wrong systems. If your problem is that no patch will ever be released, 6.6.2 is not your clause, and quoting it in an exception file is the fastest way to signal you have not read the provision.

Does This Apply to You?

Two conditions have to be true at once: your organisation is in scope of NIS2, and you operate something that cannot take a current security patch.

NIS2 catches you if you are a medium or large enterprise in an Annex I or II sector, plus the size-independent cases in Article 2(2). Commission Implementing Regulation (EU) 2024/2690, which supplies all the operational detail below, was adopted under Article 21(5) — the provision requiring the Commission to lay down technical and methodological requirements “with regard to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online market places, of online search engines and of social networking services platforms, and trust service providers”. If you are outside those eleven categories, the Implementing Regulation does not apply to you directly. It is still the most detailed statement of what Article 21(2) means in practice and national authorities work from it, so treat it as the benchmark you will be measured against.

Then separate the three things people file under “legacy”, because the law treats them differently:

• No patch exists and none is coming. The vendor has ended support: a Windows Server release past its date, an ERP version the supplier has retired, a network appliance out of its maintenance window.
• A patch exists but you have chosen not to apply it. It breaks a dependency, it has a known regression, or it collides with a validated configuration.
• A patch exists and you cannot apply it yet. The change window is months away, or a certification has to be re-run first.

Only the second one is a 6.6.2 question. This article covers the enterprise IT estate. If the asset is a PLC, a DCS or anything else behind an industrial protocol, the operational-technology analysis differs enough that it deserves its own treatment — see our guides to NIS2 in OT environments and ICS security compliance.

What NIS2 Actually Says About Old Systems

In short: the Directive imposes no legacy-specific rule. It reaches your old systems through a general maintenance obligation and a general proportionality test, and it leaves every operational detail to the Implementing Regulation and to you.

Article 21(2)(e) is the hook. It requires measures covering “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. Maintenance is the operative word: an unsupported system is not primarily a patching failure, it is a maintenance state you have entered and have to manage. Article 21(2)(i) adds asset management, which is where the system has to be visible in the first place.

Article 21(1) sets the standard those measures are judged against — “appropriate and proportionate” measures, taking account of “the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation”. Note what it does not say. It does not weigh the difficulty of fixing a problem. Cost of implementation enters as a factor in choosing measures, not as a defence for having none. That distinction decides most of what follows.

The Clause Everyone Cites Is the Wrong One

In short: 6.6.2 is a derogation from one specific limb of 6.6.1 — the duty to apply patches that are available. An unpatchable system has no available patch, so 6.6.2 has nothing to derogate from. Point 6.6.1(d) governs instead, and it is drafted as an obligation, not a permission.

Here is 6.6.1 verbatim. Entities “shall specify and apply procedures … for ensuring that:”

(a) security patches are applied within a reasonable time after they become available; (b) security patches are tested before being applied in production systems; (c) security patches come from trusted sources and are checked for integrity; (d) additional measures are implemented and residual risks are accepted in cases where a patch is not available or not applied pursuant to point 6.6.2.

And 6.6.2:

By way of derogation from point 6.6.1.(a), the relevant entities may choose not to apply security patches when the disadvantages of applying the security patches outweigh the cybersecurity benefits. The relevant entities shall duly document and substantiate the reasons for any such decision.

Read the opening words of each. 6.6.2 derogates from (a), and only from (a). Point (a) is about patches that “become available”. A system whose vendor has ended support has no available patch, so there is no duty under (a) to be relieved of — and no derogation to claim.

Point (d) is the clause that does the work, and it covers both situations expressly: “a patch is not available or not applied pursuant to point 6.6.2″. It sits inside 6.6.1’s “shall … for ensuring that”, which makes it mandatory for entities the Regulation binds. It has two components, and both are required: additional measures and an accepted residual risk. Compensating controls without a signed acceptance is half the requirement. An acceptance without controls is the other half.

Your situation	Governing point	What you must produce
Vendor support ended; no patch will be issued	6.6.1(d), first limb	Additional measures + documented residual-risk acceptance. No derogation to cite
Patch exists; you decided against it	6.6.2, then 6.6.1(d)	Documented and substantiated reasons for the decision, then the same measures and acceptance
Patch exists; deployment delayed	6.6.1(a)	Nothing exceptional yet — “a reasonable time” is undefined, so your own risk-based SLA is the reference

One more detail in 6.6.2 that nobody weighs. The balance is struck between the disadvantages of patching and the “cybersecurity benefits”. “Disadvantages” is unqualified, so operational harm plausibly counts on that side of the scale — but the benefit side is expressly narrowed to security. An argument that patching would breach an availability target is therefore not a like-for-like trade. Whether supervisors will read that asymmetry strictly is untested; there is no enforcement practice on the point yet. Draft the file so it survives the strict reading. For how points 6.6 and 6.10 divide the wider work, see our guide to NIS2 vulnerability and patch management.

The Proportionality Argument, and Exactly Where It Runs Out

In short: proportionality buys you a different set of measures. It does not buy you an indefinite exemption, and both ENISA and at least one national authority say so in terms.

Article 21(1) genuinely does let a smaller entity with lower exposure do less than a large one, and ENISA’s Technical Implementation Guidance offers two risk-acceptance criteria that read directly onto legacy: accepting risks “if the cost of mitigation exceeds the potential impact (e.g. not upgrading legacy systems if the upgrade cost is significantly higher than potential losses)”, and accepting “certain vulnerabilities for a defined period while planning for remediation (e.g. accepting the risk of outdated software for three months until a full upgrade can be completed)”. Together they show the shape of a defensible argument: a cost comparison against a quantified impact, or a bounded period with a remediation plan attached. Neither is open-ended.

ENISA then closes the gap explicitly. Its guidance under point 6.6 says: “Remove unsupported hardware and software from the network in a reasonable and accepted time in line with the entity’s risk assessment.” Under 6.4.3 it adds: “Assess the risks from legacy systems and upgrade existing legacy systems to include security mitigating measures in case appropriate security cannot be achieved.” ENISA states that this part of its document “is not legally binding and is only recommendations” — but it is the agency the Commission and the NIS Cooperation Group asked to explain the Regulation, and an auditor who has read it will expect a removal timeline.

Germany’s BSI, the national competent authority there, goes further in its own baseline standard. IT-Grundschutz building block OPS.1.1.3, requirement A15 — a Basis requirement, the lowest tier — states that where a patch is not applied, the decision and its reasons MUST be documented; that where products no longer supported by the manufacturer are to be used, it MUST be checked whether they can nevertheless be operated securely; and that if they cannot, those products MUST NOT be used any longer. IT-Grundschutz is a national standard, not NIS2 law, and it binds you only where German law or your own commitments make it apply. But it is the clearest published statement of where a competent authority draws the line when the honest answer is that a system cannot be secured at all.

The Exception File a Supervisor Asks to See

In short: Article 32(2)(g) gives supervisors the power to demand “evidence of implementation of cybersecurity policies”. For an unpatchable system that means a specific bundle of documents, and ENISA has published the list.

ENISA’s “examples of evidence” under 6.6.2 name four artefacts: evidence that residual risks from non-patching “are listed and mitigated”; “documented decisions no[t] to patch accompanied by relevant alternative measures”; an up-to-date risk-treatment plan; and incident reports relating to unpatched vulnerabilities, used to check whether the mitigations worked during a real response. That last one is the item nobody prepares, and it is the one that tests whether the file describes reality.

Artefact	Anchor	Owner	Review trigger
Asset record carrying an end-of-support date	Annex 12.4.1; ENISA suggests “asset end of life” as an inventory field	Asset owner	On change, recorded traceably
Residual-risk acceptance naming the system	Annex 6.6.1(d)	Risk owner	At least annually (Annex 2.1.4)
Compensating controls, described and tested	Annex 6.6.1(d)	Security operations	After significant changes or incidents
Substantiated decision not to patch, where a patch existed	Annex 6.6.2	Change authority	Per decision
Policy-exception log with an expiry date	Annex 2.2.1	Compliance	Reported to management bodies, per ENISA at least annually
Migration or decommissioning plan with a date	Article 21(4) corrective measures	Programme owner	On slippage

On controls, ENISA’s own menu under 6.6.2 is short and worth matching: “strict configuration hardening, intrusion detection systems, regular vulnerability scanning, network segmentation or isolation where feasible, access control and monitoring”.

The exception log is the piece most organisations miss. ENISA’s illustration is exactly the legacy case: “if a legacy system does not support encryption, an exception might be granted until the system is replaced“. An exception with no end date is not the artefact the guidance describes. For how this evidence is assembled ahead of a review, see our NIS2 audit preparation plan.

Why This Ends Up on the Board’s Desk

Article 20(1) requires management bodies to “approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements”. A decision to keep running a system that cannot be secured is such a measure. Annex 2.2.1 closes the loop from the other side: “the management bodies shall be informed of the status of network and information security on the basis of the compliance reviews by means of regular reporting”, and ENISA suggests those reports carry “compliance status, including policy exceptions”. Your legacy exceptions are meant to travel up to the people who carry the liability, on a schedule, as a named item rather than a footnote.

Role	What they own here
CISO / IT security manager	Selecting and testing compensating controls; proving they work when an incident touches the system
Compliance officer	The exception log, its expiry dates, and the annual reporting line into the management body
Asset / system owner	End-of-support dates in the inventory; signing the residual-risk acceptance
Management body	Approving the acceptance, funding the replacement, carrying the Article 20(1) liability

If the file is not there, Article 32 gives the supervisor a ladder rather than a single step: a warning under 32(4)(a), then binding instructions with “time-limits for the implementation of such measures” under 32(4)(b), then an order to bring measures into line with Article 21 “in a specified manner and within a specified period” under 32(4)(d). Administrative fines under Article 34 sit on top — a maximum of at least €10 million or 2% of total worldwide annual turnover for essential entities, €7 million or 1.4% for important entities, whichever is higher. For a legacy system the realistic exposure is rarely the fine; it is a replacement deadline set by someone other than you. Our guide to Article 20 board obligations covers the governance side in detail.

Stopping the Next Generation of Legacy

The Implementing Regulation already tells you to prevent this at purchase. Point 6.1.2(b) requires acquisition processes to include “requirements regarding security updates throughout the entire lifetime of the ICT services or ICT products or replacement after the end of the support period“. The exit is supposed to be specified when the system is bought. ENISA’s guidance under 6.1 adds the operational version: support contracts should cover “the date until which the system must be supported”, with continuous alerting, and tenders should favour vendors that publish clear end-of-life information.

From the supplier side, the Cyber Resilience Act — Regulation (EU) 2024/2847, applying from 11 December 2027 — sets a floor. Article 13(8) requires a support period of “at least five years”, or the expected use time where that is shorter, and Article 13(9) keeps each security update available for ten years after issue or the rest of the support period, whichever is longer. That floor applies to products placed on the market under the CRA, not to the estate you already run. Its value to you now is as a procurement question: ask for the declared support period in writing, and put it in the asset register the day the system arrives.

Key Takeaways

• NIS2 never uses the word “legacy”. It reaches old systems through Article 21(2)(e) maintenance and the Article 21(1) proportionality test.
• CIR Annex 6.6.2 derogates from 6.6.1(a) only, and 6.6.1(a) concerns patches that are available. It does not apply to a system that can never be patched.
• 6.6.1(d) is the governing clause, and it is mandatory: additional measures and an accepted residual risk. Both, not either.
• Proportionality buys different measures, not indefinite exemption. ENISA expects unsupported software to be removed “in a reasonable and accepted time”; BSI’s baseline standard bars continued use of products that cannot be operated securely.
• Every exception needs an expiry date, an owner, an annual review and a reporting line to the management body under Article 20(1). Point 6.1.2(b) then requires you to plan replacement after end of support at the point of purchase — where the next decade of legacy is created or avoided.

Frequently Asked Questions

Does NIS2 require us to replace unsupported systems?

No Union-law instrument says so outright. What 6.6.1(d) requires is additional measures plus an accepted residual risk. But ENISA’s non-binding guidance recommends removing unsupported hardware and software “in a reasonable and accepted time in line with the entity’s risk assessment”, and Germany’s BSI baseline standard bars continued use of unsupported products that cannot be operated securely. Not an obligation to replace — a strong expectation that the exception is time-bounded.

How long can we keep an unpatchable system running?

No instrument states a number. The standard is Article 21(1) proportionality plus your own documented risk assessment. The defensible pattern in ENISA’s examples is a bounded period with a remediation plan attached; its illustration uses three months for outdated software pending an upgrade. Treat an exception with no end date as a finding waiting to happen.

Is a documented risk acceptance enough on its own?

No. Point 6.6.1(d) is conjunctive: “additional measures are implemented and residual risks are accepted”. A signed acceptance with no compensating controls satisfies half the clause, and ENISA’s evidence list also asks for proof the mitigations worked when an incident touched the system — which an acceptance form cannot supply.

Can we argue that patching would breach our availability targets?

You can raise it, but be precise about the clause: that argument belongs to 6.6.2, which applies only where a patch exists. The text weighs disadvantages against “the cybersecurity benefits”, so an availability argument is set against a security gain rather than another availability consideration. Document and substantiate the reasoning, and expect the file to be read against the narrower interpretation.

Sources

1. Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures
2. Directive (EU) 2022/2555, Article 20 — Governance
3. Directive (EU) 2022/2555, Article 12 — Coordinated vulnerability disclosure and a European vulnerability database
4. Directive (EU) 2022/2555, Article 32 — Supervisory and enforcement measures in relation to essential entities
5. Directive (EU) 2022/2555, Article 34 — General conditions for imposing administrative fines
6. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 (June 2025) — reprints the Annex to Commission Implementing Regulation (EU) 2024/2690 verbatim, including points 6.6.1, 6.6.2, 6.1.2, 2.2.1 and 12.4
7. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex, ELI: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj (the canonical text; EUR-Lex was rate-limiting automated requests at the time of writing, so all Annex quotations above were taken from source 6, which reproduces them verbatim)
8. Directive (EU) 2022/2555 — EUR-Lex, ELI: eur-lex.europa.eu/eli/dir/2022/2555/oj
9. BSI, IT-Grundschutz-Kompendium, building block OPS.1.1.3 “Patch- und Änderungsmanagement” (Edition 2023), requirement OPS.1.1.3.A15 — bsi.bund.de (de-linked: the BSI download endpoint rejects automated requests)
10. Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13 — Obligations of manufacturers
11. Regulation (EU) 2024/2847, Article 71 — Entry into force and application

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.