NIS2 ICS Security: The Legacy DCS Patching Exception Article 21 Doesn’t Explain

A Modbus TCP command has no password field. Neither does DNP3 in its unauthenticated form, and neither does IEC 60870-5-104, the protocol running grid substations across the EU. These three protocols move the instructions that open valves, trip breakers, and stop conveyor belts — and none of them were built to tell a legitimate command from a forged one. That’s not a hypothetical: in 2026 alone, CISA and vendor advisories have flagged unauthenticated Modbus access on live production PLCs as a critical-severity finding [7].

NIS2’s Article 21 doesn’t mention Modbus, DNP3, or PLCs by name. It doesn’t have to — the ten risk-management measures in Article 21(2) apply in full to the manufacturing, energy, and water operators running these systems, exactly as they apply to a bank’s core banking platform. What changes on the plant floor isn’t the law. It’s the evidence an auditor will actually accept, and that’s where most NIS2 guidance for industrial environments stops short. This article names the specific protocol weaknesses behind the compliance language, shows where PLC firmware sits inside Article 21(2)(d)’s supply chain obligation, sets out a legacy-DCS patching exception record that can survive review, and corrects a scope error repeated across most published NIS2/OT content: what Commission Implementing Regulation (CIR) 2024/2690 actually binds, and what it doesn’t.

Who NIS2’s ICS Rules Actually Apply To

Before the technical detail: if your organisation doesn’t meet both the sector and size criteria below, none of what follows is a legal obligation for you — though it may still be good practice.

Sector	Annex	Entity type	Where ICS/OT typically sits
Energy (electricity, gas, district heating)	Annex I	Essential	SCADA, RTUs, IEC 60870-5-104 substation links
Drinking water / waste water	Annex I	Essential	SCADA, PLCs controlling treatment and pumping
Manufacturing (5 sub-sectors)	Annex II	Important	PLCs, DCS, MES, robotics controllers

Size still gates scope: medium entities (50–249 staff, over €10M turnover) and large entities (250+ staff, over €50M turnover) fall in scope in these sectors; most micro and small operators do not, unless they’re a size-independent category. See our full NIS2 scope and entity-size breakdown if you haven’t confirmed your status yet.

ICS/OT gets no separate legal track. Article 21(1) requires “appropriate and proportionate” measures across the whole entity’s network and information systems — IT and OT together [1]. What differs is what “appropriate and proportionate” looks like when the asset in question is a 15-year-old PLC that can’t run an endpoint agent, and that’s a documentation and engineering problem, not a legal exemption.

Four roles read this differently, and a compliance programme that only speaks to one of them will stall:

Role	What they need from this article
OT / plant engineering lead	Which protocols and firmware paths are actually exploitable, and what a defensible patching exception looks like in practice
CISO / IT security manager	How Article 21(2)(e) vulnerability handling maps onto OT asset classes IT tooling can’t reach
Compliance officer	What CIR 2024/2690 legally requires versus what it’s used for by analogy — the distinction auditors will probe
Board / plant director	Why “we haven’t been breached” isn’t evidence of compliance, and what a documented risk-acceptance record protects against

Why ICS Protocols Are a Different Risk Profile Under Article 21(2)(e)

In mid-2026, CISA published an advisory for the Delta Electronics DVP-12SE PLC: its Modbus TCP service accepts read and write commands — to coils, holding registers, and process-control functions — from any device that can reach the port, with no authentication check at all. NIST’s National Vulnerability Database classifies it as CWE-306 (Missing Authentication for Critical Function) and scores it 9.3 out of 10, Critical, under CVSS 4.0 [7]. That’s not a misconfiguration on one vendor’s device. It’s the protocol working as designed.

Modbus, DNP3, and IEC 60870-5-104 were all specified for electrically isolated, single-purpose control networks decades before anyone expected them to sit on routable IP infrastructure. None of the three has a native authentication layer; none encrypts payloads by default; DNP3 was engineered for resilience against line noise, not against a party deliberately forging a command. The result is a category of device where “the network can reach it” and “the network can control it” are the same statement.

Article 21(2)(e) requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” [1]. For an office IT estate, that mostly means a patch cadence and a CVE feed. For an OT estate running protocols with no authentication model to patch, it means something closer to compensating-control engineering: what sits between the protocol and the internet, what can issue a command to that PLC, and how you’d know if something unauthorised tried. A vulnerability-handling policy that only tracks CVEs and ignores protocol-level exposure will not hold up against an auditor who has read the CISA advisory.

The exposure isn’t theoretical. Dragos, which tracks ransomware activity against industrial organisations, recorded 742 ransomware incidents against industrial entities in Q3 2025 alone, with manufacturing accounting for 72% of them — 532 of the 742 [8]. Auditors reviewing OT vulnerability-handling evidence increasingly expect it mapped explicitly to Article 21(2), not left as a generic IT policy with “OT” inserted into the title.

PLC Firmware and the Supply Chain: Article 21(2)(d) in Practice

Article 21(2)(d) obliges entities to address “security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” — and Article 21(3) sharpens that into a concrete assessment duty, requiring entities to weigh “vulnerabilities specific to each direct supplier” and their secure development procedures [1]. Most NIS2 supply-chain guidance reads that as a vendor-contract exercise — due diligence questionnaires, security clauses, audit rights. For an ICS environment, it’s also a firmware-provenance question, and the clearest illustration of why is a decade-old attack that’s still the reference case in ICS security research.

In 2017, attackers targeting a Middle East petrochemical facility went after the plant’s safety instrumented system — the layer of controllers whose only job is to force a safe shutdown when something goes wrong. Researchers who later reverse-engineered the malware, known as TRITON or TRISIS, found the attackers exploited a specific weakness: the proprietary engineering protocol used to program the safety controllers had no authentication mechanism at all, which let them read and manipulate controller memory once they’d reached the engineering workstation. From there they planted a persistent implant at the firmware level, giving them read, write, and execute access to the safety logic regardless of the physical key-switch position on the controller [6]. The attack’s fourth and final stage — the actual destructive payload — was never recovered; the controllers entered a fail-safe shutdown first, and that shutdown is what alerted defenders to the intrusion at all.

The lesson for Article 21(2)(d) isn’t “buy from a bigger vendor.” It’s that the realistic attack path into ICS firmware rarely starts at the PLC — it starts at the engineering workstation, the integrator’s remote-access account, or a compromised update package, and firmware integrity has to be part of the supplier assessment, not an afterthought to it. In practice that means: does the direct supplier sign firmware updates? Is there a documented chain of custody from vendor release to what’s actually loaded on the controller? Who besides your own staff can push a firmware or logic change to a safety-relevant device, and how would you know? Our supply chain security requirements guide covers the contractual side of Article 21(2)(d) in more depth; firmware provenance is the OT-specific extension of the same obligation.

The Legacy DCS Patching Exception: Documentation That Survives an Audit

Many distributed control systems (DCS) running today are 20 years or more past their original commissioning date, and it’s common for their vendor to have stopped issuing security patches years before the hardware itself gets replaced. That’s not a compliance loophole — Article 21(1) explicitly builds proportionality into the standard, weighing “the cost of implementation” and the entity’s actual risk exposure [1] — but a patch you can’t apply has to become a documented exception, not a silent gap.

The Dutch National Cyber Security Centre’s guidance on ICS security treats end-of-life equipment as its own managed category rather than an ad hoc exception: it recommends a formal update and patch policy that explicitly names unsupported systems and defines how they’re handled, rather than leaving legacy assets to fall outside the policy’s scope entirely [4]. Separately, NCSC-NL’s guidance on industrial risk-assessment methods points to Consequence-Driven Cyber-Informed Engineering (CCE), a framework developed by Idaho National Laboratory that starts from the assumption that your most critical systems may already be compromised, and asks what you’ve done to limit the consequence of that rather than relying solely on prevention [5]. For a DCS you genuinely cannot patch, that’s the more honest question: not “is this system secure,” but “what happens if it isn’t, and have you limited the blast radius.”

A risk-acceptance record that will hold up under review needs, at minimum:

• The specific system, its function, and why it can’t be patched (vendor end-of-support date, safety-recertification cost, incompatible OS dependency — named, not implied)
• The compensating controls actually in place — segmentation, monitoring, restricted physical/remote access — described specifically enough that a third party could verify them
• A named owner accountable for the exception, not a department
• A review date, typically annual or tied to the next planned maintenance window — not “ongoing” or left blank
• Sign-off from whoever owns risk acceptance in your governance structure, documented at the time, not reconstructed after the fact

The common failure mode CISA and NCSC-NL both flag is treating a compensating-control decision as permanent once it’s written down. An exception without a review date isn’t a risk acceptance — it’s an unmanaged gap with a memo attached. See our vulnerability and patch management requirements guide for the broader Article 21(2)(e) documentation structure this exception record sits inside.

Air-Gap or Network Segmentation? Making the Actual Decision

The honest version of this debate isn’t “which one is more secure” — it’s which one your operation can actually sustain. A true air gap, with no routable connection between the OT network and anything else, is genuinely harder to compromise remotely, and it remains standard practice for the highest-consequence systems: safety instrumented systems, protection relays, anything where an intrusion could cause physical harm. But full air-gapping is increasingly incompatible with how modern plants actually run — remote vendor support, predictive-maintenance data, and centralised monitoring all depend on some data path leaving the OT network, and a full air gap that gets bridged informally (a technician’s laptop, a USB drive, an undocumented modem) is often worse than a properly monitored connection, because nobody’s watching it.

IEC 62443’s zones-and-conduits model gives the more common answer a structure: group assets into zones sharing a similar security requirement, and treat every path between zones — a conduit — as a place where a security policy is actively enforced, not just a cable. Applied to a typical plant, that usually means the safety layer and the most critical process controllers stay fully isolated or as close to it as the process allows, while less critical zones — supervisory SCADA, historian data, engineering workstations — sit behind monitored, tightly-scoped conduits rather than a flat network. Because Article 21(2) doesn’t specify a particular network architecture, a documented zones-and-conduits assessment — which systems sit in which zone, and why each conduit’s controls are proportionate to what crosses it — is generally treated as stronger audit evidence for the network-security elements of the measure than a segmentation diagram with no rationale attached, though it doesn’t substitute for the entity’s own documented risk assessment of where its zone boundaries actually sit.

The decision that matters isn’t air-gap-versus-segmentation as a binary. It’s which systems justify the operational cost of true isolation, and for everything else, whether your conduits are actually monitored or just assumed to be secure because they’re “internal.”

What CIR 2024/2690 Actually Requires of ICS Operators (And What It Doesn’t)

This is worth stating precisely, because it’s misrepresented across a lot of published NIS2/OT content. Commission Implementing Regulation 2024/2690 sets out detailed technical and methodological requirements for cybersecurity risk-management measures — but its legal scope is limited to a specific list of entity types: DNS service providers and TLD registries, cloud computing providers, data centre services, content delivery networks, managed service and managed security service providers, online marketplaces, search engines and social networking platforms, and trust service providers [2][3]. Manufacturing, energy, and water operators — the entities actually running the ICS environments this article covers — are not on that list. CIR 2024/2690 does not legally bind them.

What it does do is offer the most granular technical breakdown of what “vulnerability handling and disclosure” or “security in acquisition, development and maintenance” can look like in practice — its Annex point 6, for instance, spells out secure development practices, configuration management, security testing, and patch management as concrete sub-requirements under exactly the kind of language Article 21(2)(e) uses in general terms [1][2]. Because NIS2 doesn’t provide equivalent technical granularity for the broader population of Essential and Important entities, ICS operators and their compliance advisers frequently use the CIR Annex structure as an interpretive reference — a way to demonstrate what “appropriate and proportionate” evidence looks like — without it being a binding source of obligation for their sector. If a vendor or consultant tells you CIR 2024/2690 “requires” a specific OT control, ask them to point to the entity-scope clause; for a manufacturing or energy operator, it almost certainly doesn’t, though building your documentation to its structure is still a reasonable and common choice.

Who Owns What: A Role-Impact Matrix for OT Compliance

Article 21(2) measure	OT/plant engineering owns	CISO/IT owns	Compliance officer owns
(d) Supply chain	Firmware update verification, integrator remote-access review	Vendor risk assessment process	Contractual security clauses, audit trail
(e) Vulnerability handling	Protocol/asset-level exposure assessment, compensating controls	CVE monitoring, patch scheduling for patchable assets	Legacy-exception documentation and review-date tracking
(i) Access control	Physical and engineering-workstation access	Remote-access architecture, credential management	Access-review evidence for audit

Key Takeaways

• Article 21 applies to the whole entity, IT and OT together — there’s no separate legal track for the plant floor, only different evidence of “appropriate and proportionate.”
• Name the actual protocol and firmware risks (Modbus/DNP3/IEC 60870 authentication gaps, firmware provenance) instead of writing a generic IT vulnerability policy with “OT” inserted into the title.
• Every legacy-system patching exception needs a named owner, specific compensating controls, and a review date — or it’s not a risk acceptance, it’s an unmanaged gap.

Frequently Asked Questions

Does NIS2 require replacing legacy PLCs or DCS equipment that can’t be patched?

No. Article 21(1) builds proportionality into the standard, including cost of implementation [1]. What it requires is a documented, reviewed compensating-control record for systems you can’t patch — not replacement on a fixed timeline.

Is air-gapping enough to satisfy Article 21 on its own?

For the highest-consequence systems it’s a reasonable and common choice, but Article 21(2) covers ten separate measures — incident handling, supply chain, access control, and more — that a network architecture decision alone doesn’t address.

Does CIR 2024/2690 legally apply to my manufacturing or energy plant?

No — its binding scope covers digital-infrastructure entities (DNS, cloud, CDN, MSP/MSSP, marketplaces, trust services) [2][3]. Manufacturing, energy, and water operators fall under Article 21 directly; the CIR Annex is a useful structuring reference for that evidence, not a binding source of obligation for these sectors.

What counts as a “direct supplier” for PLC firmware under Article 21(2)(d)?

Typically the PLC/DCS vendor itself and any systems integrator with ongoing remote-access or firmware-update rights to your control systems — anyone whose compromise could put unauthorised code on your controllers.

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.

Sources

1. Directive (EU) 2022/2555 (NIS2), Article 21 — nis-2-directive.com, Article 21 summary
2. Commission Implementing Regulation (EU) 2024/2690 — nisd2.eu, CIR 2024/2690 technical measures overview
3. OpenKRITIS, “NIS2 Implementing Act DVO (EU) 2024/2690” — entity-scope reference, https://www.openkritis.de/massnahmen/implementing-acts-it-nis2-mapping.html
4. NCSC-NL (Dutch National Cyber Security Centre), “Aan de slag met ICS Security” — ncsc.nl, ICS security framework
5. NCSC-NL, “CCE and other risk assessment methods for Industrial Systems” — ncsc.nl, industrial risk-assessment methods
6. Midnight Blue, “Analyzing the TRITON industrial malware” — midnightblue.nl, TRITON technical analysis
7. CVE-2026-12819, Delta Electronics DVP-12SE PLC — NIST National Vulnerability Database
8. Dragos, “Industrial Ransomware Analysis: Q3 2025” — dragos.com, Q3 2025 ransomware data