NIS2 Article 21 for SCADA and ICS: Mapping IT/OT Convergence to the Purdue Model and CIR Annex 6

Article 21 of the NIS2 Directive does not say “IT systems.” It says “network and information systems” — a phrase broad enough to include the programmable logic controller running your bottling line and the SCADA workstation your operators watch every shift. Most compliance guidance still treats OT as an afterthought, bolted onto an IT-first checklist. That gap is exactly where audits go wrong: a network security policy written for a Windows domain doesn’t hold up when an assessor asks how you segment a 15-year-old PLC that has never received a firmware update.

This guide maps Article 21(2)(e) and its technical Annex — Commission Implementing Regulation (EU) 2024/2690, Section 6 — onto the Purdue Model that most OT teams already use to describe their architecture. It also covers the four problems that make OT compliance genuinely different from IT compliance: asset inventory, unpatchable legacy equipment, incident detection, and firmware supply-chain risk.

The stakes for treating OT as an afterthought are rising. Manufacturing accounted for more than two-thirds of the industrial organisations Dragos recorded as ransomware victims in 2025, out of roughly 3,300 affected organisations tracked globally^[4]. NIS2’s incident-notification clock under Article 23 doesn’t run any slower for an OT breach than an IT one — but an under-monitored OT environment routinely finds out about an incident later than an IT environment would, which shortens the time you have left inside the 24-hour early-warning window once you do notice.

Does NIS2’s Network Security Rule Actually Reach Your OT Environment?

Yes, if your organisation is in scope for NIS2 at all. Article 21(1) requires essential and important entities to manage risk to their network and information systems using an all-hazards approach, and Article 21(2)(e) specifically names “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” as one of the ten mandatory measures^[1]. Nothing in that text carves out operational technology. If your SCADA historian, engineering workstation, or plant-floor network sits inside the entity that’s in scope, it’s inside Article 21’s scope too.

Where the confusion usually starts is CIR 2024/2690 — the regulation that spells out exactly what Article 21(2)(e) means in Section 6 of its Annex, sub-points 6.1 through 6.10^[2]. That regulation formally binds only a narrow list of digital-infrastructure entity types: DNS providers, TLD registries, cloud and data-centre providers, content delivery networks, managed (security) service providers, online marketplaces, search engines, social platforms, and trust service providers. A discrete-manufacturing or energy-sector operator running SCADA is not directly bound by the CIR’s Annex.

That doesn’t make the CIR irrelevant to a manufacturer. It’s the only detailed technical text that exists for the same phrase — “security in network and information systems acquisition, development and maintenance” — so national competent authorities and auditors routinely use its ten sub-points as the reference benchmark for what “reasonable” network security looks like, even for entities the CIR doesn’t formally bind. Treat Section 6 as strong best-practice guidance you should be able to explain a deviation from, not a checklist you’ll be fined line-by-line for missing.

Entity type	Is CIR Annex Section 6 formally binding?	What actually governs you
Cloud, MSP/MSSP, CDN, DNS, trust services	Yes — directly	Article 21(2)(e) + CIR Annex Section 6, sub-point by sub-point
Manufacturing, energy, transport, health, water (SCADA/ICS operators)	No — not formally	Article 21(2)(e)’s general text; CIR Section 6 as interpretive benchmark
Any essential/important entity, regardless of sector	N/A	Article 21(1)’s all-hazards, risk-based standard applies either way

Mapping the Purdue Model to CIR Annex Section 6: A Practical Translation

The Purdue Model splits an industrial environment into six numbered levels — Level 0 physical process, Level 1 PLCs and RTUs, Level 2 SCADA/HMI supervisory control, Level 3 site operations, an industrial DMZ often labelled Level 3.5, and Levels 4–5 covering business IT and the enterprise network^[3]. OT teams already think in these levels. CIR Section 6 doesn’t reference the Purdue Model at all — it was written for generic ICT lifecycles. Translating one onto the other is original synthesis, not an official mapping, but it’s the fastest way to turn ten abstract sub-points into a concrete OT work plan.

CIR sub-point	What it covers	Where it lives on the Purdue Model
6.7 Network security	Protective architecture, documented access controls	Level 3.5 industrial DMZ — the choke point between IT and OT traffic
6.8 Network segmentation	Zones separated by risk assessment	Boundaries between Levels 0–1, 2, 3, and the 3.5 DMZ
6.6 Patch management	Timeframes, trusted sources, exception handling	Levels 1–2 — PLC/RTU firmware and SCADA/HMI software
6.9 Malware protection	Detection and prevention measures	Levels 2–3 — Windows-based HMIs, engineering workstations, historians
6.10 Vulnerability handling and disclosure	Monitoring advisories, impact-based prioritisation	All levels, vendor-dependent for Levels 0–2
6.1–6.2 Acquisition and secure development	Procurement and lifecycle security requirements	Levels 1–2 — PLC/RTU vendor selection and contract terms
6.3–6.4 Configuration and change management	Documented, tested changes	Levels 1–3 — control logic, HMI screens, historian configuration
6.5 Security testing	Risk-based technical assessment	Level 3.5 and above — active testing on Levels 0–2 risks disrupting the physical process

The Level 3.5 DMZ carries more compliance weight than any other zone in this table, because it’s where 6.7, 6.8, and effectively the audit trail for the rest of Section 6 converge. If an assessor asks for one artefact that proves your network security architecture, a documented DMZ design with logged, filtered IT-OT traffic is it.

The OT Asset Inventory Problem: Why an IT Scan Misses Half the Floor

Article 21(2)(e)’s acquisition and lifecycle requirements only apply to assets you know exist. That’s a harder bar to clear in OT than in IT. Standard IT discovery relies on active scanning — sending packets and reading responses — and that’s precisely what a fragile, decades-old PLC can’t reliably absorb. A ping sweep that an IT server ignores can overwhelm a legacy controller’s limited processing headroom and force a reset, so most OT teams default to passive discovery: watching network traffic to build an asset list without ever addressing the device directly.

Passive discovery has its own blind spot — it only sees devices that are actively communicating on the segment being monitored, which is exactly how “shadow OT” accumulates: legacy equipment, contractor-installed test rigs, and vendor remote-access boxes that were never logged in the official asset register in the first place. The practical fix isn’t a bigger scanner. It’s a documented discovery methodology under CIR 6.1–6.3: define the physical and logical survey scope per production line, capture firmware version and vendor-support status as required fields, and re-run the survey after every maintenance window or change — because that’s when undocumented devices most often get added.

The stakes for getting this wrong are rising, not shrinking. Dragos’s 2026 OT Cybersecurity Year in Review found that only around 30% of OT networks in the organisations it assessed have adequate visibility, and 56% of those same organisations cannot see below the IT/OT boundary at all — meaning more than half are effectively blind to everything happening at Levels 0 through 3^[4]. That’s a visibility gap, not just a documentation gap, and it’s the single biggest reason 88% of assessed organisations reported struggling with detection and response in OT environments^[4].

When You Can’t Patch: Compensating Controls Under CIR 6.6 and 6.10

An unpatched PLC is not automatically a compliance failure. An unpatched PLC with no documented reasoning and no compensating control is. CIR 6.6 explicitly anticipates exception handling with documented substantiation^[2], and CISA’s own recommended practice for control-system patch management takes the same position: when a patch can’t be applied because of vendor non-support or the risk of process disruption, the response is a formal, reviewed risk acceptance paired with technical compensating controls — not indefinite silence^[5].

Why you can’t just patch	Compensating control	Maps to
Vendor has stopped issuing firmware updates (end-of-life PLC/RTU)	Network micro-segmentation isolating the asset + application allow-listing on adjacent HMIs[6]	CIR 6.6 exception + 6.8 segmentation
Patch requires planned downtime the process can’t absorb	Scheduled maintenance-window patching + IDS/IPS signature tuned to the known CVE in the interim[5][6]	CIR 6.6 + 6.9
Proprietary protocol (Modbus, DNP3) has no built-in authentication	Protocol-aware monitoring + physical/logical access restriction at the controller	CIR 6.7 network security + 6.10 vulnerability handling
Vulnerability disclosed with no vendor fix timeline	Documented risk acceptance with a fixed review date + a supplier contract clause requiring advance disclosure	CIR 6.10 + Article 21(2)(d) supply chain

The paper trail matters as much as the control itself. An assessor evaluating 6.6 isn’t primarily checking whether every CVE was patched — in OT, that’s often not achievable. They’re checking whether you can produce, for any given unpatched asset, a dated risk decision, the compensating control that offsets it, and a review date that isn’t “never.”

Not every disclosed vulnerability deserves the same response, and treating them all as equally urgent is how patch-management programmes burn out. Dragos’s own OT vulnerability triage found that only a small share of the vulnerabilities it assessed — roughly 3% — required immediate action, around 71% were addressable through a compensating control or the next scheduled maintenance window, and the remainder didn’t warrant remediation effort at all given the asset’s actual exposure^[4]. Applying that same three-tier logic — now, next maintenance cycle, or accepted risk — to your own CIR 6.10 vulnerability register turns an unmanageable CVE list into a workable one, and gives an auditor a documented rationale instead of a blanket “we couldn’t get to it.”

OT Incident Detection: Why Passive Monitoring Is the Default

The same fragility that shapes OT asset discovery shapes OT incident detection. Aggressive, IT-style active security tooling can itself trigger the outage it’s meant to prevent, so the accepted standard is passive monitoring — mirroring network traffic through a SPAN port and analysing it without ever sending packets to a controller^[7]. Industrial traffic also behaves differently from IT traffic in a way that works in the defender’s favour: it’s repetitive and predictable, cycling through the same commands and read/write patterns shift after shift, so a PLC receiving an unexpected write command or a device suddenly talking to a host it’s never contacted before stands out far more clearly than an anomaly would on a general-purpose IT network^[7].

Detection speed compounds directly into compliance exposure. Once your monitoring — passive or otherwise — surfaces reasonable grounds to believe a significant incident is underway, the same notification clock starts as it would for an IT breach; our incident reporting guide covers the exact early-warning and full-report deadlines. An OT environment with no monitoring below the IT/OT boundary doesn’t get a longer clock. It just finds out later, closer to the deadline, with less evidence.

What passive monitoring actually needs to produce for that evidence pack is narrower than a full SOC build-out: a timestamped log of the anomalous command or connection, the asset it touched, and how that maps back to the affected Purdue level. A Level 1 PLC receiving an unscheduled write command is a materially different incident, both operationally and in terms of who needs to be told first, than a Level 3 historian being queried from an unfamiliar host — and a monitoring set-up that can’t tell the two apart will struggle to support the significance judgement you need to make fast enough to hit Article 23’s 24-hour early-warning deadline.

Firmware and Supplier Risk: Where Article 21(2)(e) Meets Article 21(2)(d)

OT supply chains concentrate risk in a way IT supply chains usually don’t: a single PLC or RTU vendor’s firmware update touches every controller of that model across a facility, and OT firmware patch cycles typically run for months behind disclosure — far slower than typical IT patch SLAs — because of the certification and revalidation testing the update has to pass first. A compromised update from a trusted vendor doesn’t need to breach your network; you install it yourself.

This is the point where Article 21(2)(e)’s acquisition and vulnerability-handling obligations (6.1, 6.10) stop being separable from Article 21(2)(d)’s supply-chain security measure. A network security policy that only addresses your own configuration and ignores what your PLC vendor’s update process looks like is treating the two measures as unrelated when the CIR itself links them: 6.1’s acquisition risk management explicitly calls for assurance that the products you’re buying meet the cybersecurity level you need, and that assurance has to extend to how the vendor builds and ships firmware, not just the device’s specifications on delivery. Our supply chain security guide and vendor contract clauses guide cover the specific clauses — vulnerability disclosure timelines, subcontractor cascade requirements, audit rights — that close this gap contractually.

A Phased IT/OT Compliance Roadmap by Role

IT/OT convergence compliance fails most often when one function assumes another owns it. A network security policy that IT wrote alone, without OT engineering sign-off on what’s actually safe to segment or scan, tends to sit unread. Building it as a shared roadmap, with named ownership per phase, is what gets it implemented instead of filed.

The effort ratings below are a practical heuristic, not a sourced benchmark — treat them as a starting estimate to adjust against your own facility count and existing documentation maturity. Asset discovery and segmentation carry the heaviest lift because they require physically walking production lines and coordinating change windows with operations; the later phases largely consume and formalise what those first two phases surface.

Phase	Primary owner	What it delivers	Effort
1. OT asset discovery + documentation	OT/plant engineering, supported by IT security	Passive-discovery asset register with firmware version and vendor-support status per device	High
2. Purdue-level network segmentation review	IT security + OT engineering jointly	Documented zone map, DMZ design, and current vs. target segmentation gap	High
3. Patch/compensating-control policy for legacy OT	OT engineering, reviewed by CISO/IT security	Written exception process with review dates, matching CIR 6.6	Medium
4. OT monitoring deployment (passive)	IT security	SPAN-based visibility below the IT/OT boundary, feeding the same incident process as IT	Medium
5. Vendor/firmware contract review	Procurement + compliance officer	Updated PLC/RTU supplier clauses covering disclosure timelines and audit rights	Medium
6. Board reporting + evidence pack	Compliance officer / CISO	Audit-ready documentation trail across all five phases above	Low

Note what’s absent from this roadmap: a line item to “replace all legacy OT equipment.” NIS2 doesn’t require that, and for most industrial estates it isn’t realistic on any compliance timeline. What Article 21(1)’s proportionality standard actually asks for is documented risk management around the equipment you have — which is why phases 1 and 3 carry more weight than a wholesale hardware refresh would.

Frequently Asked Questions

Does NIS2 Article 21 apply to OT and SCADA, or only to IT systems?
It applies to both. Article 21(2)(e)’s text covers “network and information systems” without carving out operational technology, so if your entity is in NIS2’s scope, your SCADA and ICS environment is in scope for the same ten measures as your IT estate^[1].

Is CIR 2024/2690’s Annex Section 6 legally binding on a manufacturing or energy company?
Not directly. The CIR formally binds only specific digital-infrastructure entity types. For manufacturers and energy operators, Article 21(2)(e)’s general text is the binding obligation; Section 6 functions as the interpretive benchmark auditors reference for what “reasonable” network security looks like.

Do I have to use the Purdue Model specifically?
No. NIS2 doesn’t name any architecture framework. The Purdue Model is useful here because most OT teams already describe their environment in those terms, which makes it a practical vocabulary for mapping CIR sub-points onto real network zones — not a regulatory requirement in itself.

Is an unpatched legacy PLC automatically a compliance gap?
Not if it’s documented. A risk-based exception with a compensating control and a review date, consistent with CIR 6.6’s exception-handling provision, is the accepted approach for equipment that genuinely can’t be patched without unacceptable operational risk.

Who should own IT/OT convergence compliance — IT security or plant engineering?
Both, on different phases. OT engineering understands what’s operationally safe to segment, scan, or monitor; IT security typically owns the network architecture and incident-response tooling. Splitting ownership by phase, as in the roadmap above, avoids the common failure mode of a policy one side wrote without the other’s input.

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. NIS2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
2. Commission Implementing Regulation (EU) 2024/2690, Annex Section 6 — OpenKRITIS itemised mapping
3. What Is the Purdue Model for ICS Security? — Palo Alto Networks
4. Dragos 2026 OT Cybersecurity Year in Review — Dragos, Inc.
5. CISA, Recommended Practice for Patch Management of Control Systems
6. A Strategic Necessity: Compensating Controls in ICS, OT — Claroty / Nexus
7. Combining Passive and Active Detection in OT and IoT — Nozomi Networks