NIS2 OT and SCADA Security: Mapping CIR Annex 6 to the Purdue Model for Industrial Compliance

Does NIS2 Apply to Your OT or SCADA Environment?

Plain-language summary: if your organisation is a medium or large entity (50+ staff or €10M+ turnover) in energy, water, health, or one of six manufacturing subsectors, your PLCs, SCADA servers, and safety systems fall inside NIS2’s scope the same way your office IT does.

NIS2 does not carve out an "OT exception." Article 21’s ten risk-management measures apply to "network and information systems" — a definition broad enough to cover a programmable logic controller (PLC) the same way it covers a laptop. The entities most exposed sit in two annexes of the Directive:

Annex	Entity type	OT-heavy sectors	Classification
Annex I	Essential	Energy (electricity, oil, gas, hydrogen, district heating), drinking water, waste water, health, transport, space	Essential (proactive supervision, Article 32)
Annex II	Important	Manufacturing: medical devices, computer/electronic/optical products, electrical equipment, machinery, motor vehicles, other transport equipment (shipbuilding, aerospace, rail)	Important (reactive supervision, Article 33)

A three-question test settles most scoping arguments: (1) Does your organisation sit in one of those sectors? (2) Does it have 50+ employees or exceed €10M annual turnover, or does a member state designate it regardless of size? (3) Does any part of your process — a bottling line, a substation, a water-treatment plant — depend on a PLC, RTU, DCS, or SCADA server to run? If all three are "yes," Article 21 already covers that equipment; the only open question is how to implement it on hardware that was never designed with cybersecurity in mind.

Why the Purdue Model Is the Right Lens for Article 21 in OT

Article 21(2) lists ten measure categories — risk analysis, incident handling, business continuity, supply chain, secure acquisition and maintenance, effectiveness assessment, cyber hygiene, cryptography, HR/access/asset management, and authentication. None of them are written for a specific architecture. Applied flat across an OT estate, that vagueness is where compliance programmes stall: a policy that says "implement MFA" doesn’t tell you whether that applies to the SCADA historian, the PLC, or the 1998-model HMI that can’t run a client certificate.

The Purdue Enterprise Reference Architecture — universally shortened to "the Purdue Model" — fixes that by giving each measure a physical address. It splits an industrial network into five functional levels, from field sensors (Level 0) up to enterprise IT (Level 4), with the rule that traffic between the OT side (Levels 0-3) and the IT side (Level 4+) must cross a demilitarised zone rather than talk directly. Once you know which level a device lives on, "implement MFA" becomes a specific, gradeable decision instead of an abstract instruction.

The Commission’s Implementing Regulation 2024/2690 is the most detailed technical breakdown the EU has published of what Article 21(2) looks like in practice — 13 Annex sections, each expanding one Article 21 letter into concrete sub-requirements. One caveat matters before you use it: the CIR legally binds only ten named digital-infrastructure entity types (DNS providers, TLD registries, cloud and data-centre providers, CDNs, MSPs, MSSPs, online marketplaces, search engines, social platforms, and trust service providers) — not manufacturers, energy operators, or water utilities. Every CIR section number in this article is used by analogy: as the clearest available technical benchmark for what "appropriate" looks like under Article 21, not as a binding requirement your auditor can cite against you directly.

Level 0-1: Field Devices and Controllers — Asset Inventory Without Crashing the Plant

You cannot document a control you haven’t found. Article 21(2)(i)’s asset-management duty (CIR §12.1, by analogy) requires an inventory accurate enough to show which PLCs, RTUs, and sensors exist, what firmware they run, and what they connect to — but the tool that builds an IT asset register will actively damage the OT one.

Legacy PLCs from the 1990s and 2000s run on minimal RAM with small network buffers and limited error handling. An unmanaged vulnerability scan sending roughly 1,000 packets per second can overrun that buffer: the controller freezes, drops communication, enters STOP mode, or reboots on a watchdog timer — on a device that might be running a conveyor or a pump. The fix isn’t avoiding discovery; it’s controlling the rate. Slowing an active query to one request every five seconds lets most legacy controllers respond without incident.

Two safer techniques do most of the inventory work:

• Passive discovery — a SPAN port or network tap mirrors traffic to a monitoring tool that deep-packet-inspects proprietary protocols (Modbus, DNP3, EtherNet/IP) to identify vendor, model, and firmware without sending the device a single packet. It won’t see silent or dormant assets — a disconnected vendor laptop, a backup RTU — but it carries zero operational risk.
• Safe active querying — instead of a generic port scan, the tool speaks the device’s own protocol (a standard CIP request to an Allen-Bradley controller, for example) to ask for its firmware version directly. It fills the passive method’s blind spots at a fraction of active-scanning’s risk.

An auditor doesn’t need to see either technique named in your policy — they need to see the decision documented: which method you used, why, and what the inventory covers versus what it might have missed. That gap statement is often the single most-requested artefact in an OT audit and the one generic IT asset-management policies never think to include. See NIS2 asset management requirements for the base policy structure this OT-specific inventory sits inside.

Level 1: Patch Management — the SLA Relaxation Auditors Actually Accept

Article 21(2)(e)’s vulnerability-handling duty (CIR §6.6, by analogy) does not require patching everything on the same clock. It requires a documented, risk-based process — and for OT, that process has to accommodate equipment that can only be patched during a scheduled production stop, sometimes once or twice a year.

The evidence that matters to an auditor isn’t "we patched fast." It’s three things, recorded per asset: the CVSS-based severity tier, the compensating control in place until the next patch window (network isolation, virtual patching at the firewall, disabling the vulnerable service), and the date of the next scheduled window. A vulnerability rated Critical with no compensating control and no scheduled fix is a genuine gap; the same vulnerability with documented network segmentation and a fix scheduled for the next planned outage is a defensible risk decision. NIS2 vulnerability management under CIR Annex 6 covers the full CVSS-tiered SLA table and CVD procedure requirements this section assumes.

The stakes for getting the underlying data right are higher than most patch-management guidance admits. Dragos’s 2026 OT Cybersecurity Year in Review found that 25% of ICS-CERT and NVD vulnerability entries carried incorrect CVSS scores in 2025, and 26% of advisories shipped with no vendor patch or mitigation at all — meaning a patch-SLA table built purely on public CVSS numbers will misprioritise roughly a quarter of the OT vulnerabilities it covers. Cross-checking severity against vendor advisories and your own exploitability assessment, not just the published score, is what turns the SLA table from a paperwork exercise into a real risk control.

Level 2-3: SCADA and Supervisory Zones — Segmentation and the IT/OT DMZ

Article 21(2)(e)’s network-security and segmentation duties (CIR §6.7-6.8, by analogy) are where "segment your network" has to become an actual architecture decision, and IEC 62443’s zones-and-conduits model is the accepted way to make it one. A zone groups assets that share a security requirement; a conduit is the only permitted path between zones, and it carries the controls — firewall rules, authentication, logging — that justify the crossing.

Mapped onto Purdue levels, the assignment is fairly consistent across implementations: office workstations and business systems at Level 4 sit at Security Level 1 (protection against casual, opportunistic access); remote-access gateways and jump hosts at the DMZ sit at SL2; SCADA servers, HMIs, and PLCs at Levels 2-3 sit at SL3 (protection against a moderately resourced, intentional attacker); safety instrumented systems sit at SL4, the highest tier, reserved for attackers with extended resources and specific intent. The practical rule that falls out of this: no traffic crosses from Level 4 directly into Level 2 or below. Every path runs through the Level 3.5 DMZ, and every conduit through that DMZ is logged.

The most common gap isn’t the absence of a firewall — it’s an OEM or systems-integrator remote-access connection that bypasses it. A vendor VPN set up years ago for "quick support access" into a PLC line is a Level 4-to-Level 1 conduit with no logging and often no expiry, and it is one of the first things a supply-chain-focused auditor asks to see documented under Article 21(2)(d). Treat every third-party remote connection as its own conduit, with its own access log and review date — not as an exception to the segmentation diagram, but as a labelled part of it. See NIS2 network security requirements and NIS2 OT compliance: proportionality and patch exceptions for the segmentation-documentation baseline this level builds on.

Level 3.5/4: Safety Systems and the IT/OT Boundary

Safety Instrumented Systems (SIS) — the controllers whose only job is to shut a process down safely if it goes wrong — deserve their own risk category under Article 21(2)(a), separate from ordinary process control. The clearest illustration of why is also the most cited OT incident in the field: TRITON.

In 2017, malware later named TRITON (or TRISIS) compromised the Schneider Electric Triconex safety system at a Saudi petrochemical plant. The attackers didn’t need a network zero-day to get there — a Windows engineering workstation connected to the SIS had been left with physical keys in a state that allowed program-mode access, a Level 1 access-control failure, not a network one. From that workstation, they installed a zero-day exploit capable of disabling the safety shutdown function itself. The intrusion was only caught because a bug in the malware accidentally tripped the safety system it was trying to disable, causing two unexplained plant shutdowns months apart before anyone found the cause.

Two things generalise from that case to any SIS under NIS2. First, physical access control to the engineering workstation matters as much as the network conduit — a locked keyswitch, not a firewall rule, was the control that failed. Second, an SIS earns Article 21(2)(i)’s access-control and asset-management duties at their strictest setting (CIR §11.5 and §12.1, by analogy) precisely because its failure mode isn’t data loss, it’s a physical safety event. If your gap analysis treats the SIS the same way it treats a production HMI, that’s the first finding worth fixing.

Penalties, Personal Liability, and the Audit Evidence OT Compliance Actually Needs

Article 34 sets the penalty ceiling at €10 million or 2% of worldwide annual turnover for essential entities (most energy, water, and health operators), whichever is higher, and €7 million or 1.4% for important entities (most Annex II manufacturers) — the same ceiling whether the underlying failure sits in a data centre or on a factory floor. Article 20 attaches personal accountability on top: management bodies must approve the cybersecurity risk-management measures and can be held liable for infringements, which is why a board briefing that only covers IT risk leaves a real gap in an OT-heavy organisation.

What changes for OT is the evidence an auditor expects to see, not the fine structure. A generic IT-focused audit pack rarely has a place for a segmentation diagram labelled by Purdue level, a documented patch-exception log naming the compensating control per asset, or a record of which remote-access conduits exist and who reviewed them last quarter. Building that evidence base level by level, rather than trying to retrofit an IT audit checklist onto a plant floor, is the difference between an audit that goes smoothly and one that surfaces the gap for the first time in front of the regulator.

A Level-by-Level Gap Analysis Framework You Can Present to Auditors

Most OT compliance programmes fail not because they skip a measure, but because they can’t show which level it was assessed at. This table gives each Purdue level its Article 21 anchor, the CIR section used by analogy, and a realistic effort estimate for closing a typical gap:

Purdue level	Art. 21(2) measure	CIR ref. (by analogy)	Typical current state	Required state	Effort
0-1: Field devices, PLCs	(i) Asset management	§12.1	Spreadsheet last updated at commissioning	Passive-discovery-verified inventory with firmware versions, refreshed quarterly	Medium
1: Controllers	(e) Vulnerability handling	§6.6	Patches applied "when there’s a shutdown"	CVSS-tiered SLA with documented compensating controls per unpatched asset	Medium
2-3: SCADA, HMI, historians	(e) Network security	§6.7-6.8	Flat network, one firewall at the perimeter	IEC 62443 zones/conduits with a logged DMZ between IT and OT	High
3.5-4: IT/OT boundary, remote access	(d) Supply chain / (j) Authentication	§11.5	Standing OEM VPN, shared credentials, no MFA	Time-boxed conduit per vendor, MFA at the jump host, quarterly access review	High
SIS (safety systems)	(a) / (i) Risk analysis, access control	§2.1 / §11.1	Treated as "just another controller"	Separate risk category, physical key control logged, isolated engineering workstation	Low-Medium

The "effort" column is a genuine trade-off, not a formality: segmentation work at Levels 2-3 usually means a scheduled production outage to insert the DMZ hardware, while the SIS fix is often a procedural change (log the keyswitch, isolate the workstation) that costs almost nothing and closes the highest-consequence gap on the table. Sequencing the low-effort, high-consequence items first is a defensible prioritisation an auditor will recognise even before the segmentation project is complete.

Compliance Checklist and Where to Start This Quarter

Action	Owner	Effort
Confirm Annex I/II scope and entity classification for each site	Compliance officer	Low
Deploy passive discovery (SPAN/TAP) before any active scanning tool	OT/IT security lead	Medium
Document CVSS-tiered patch SLA with compensating controls per legacy asset	IT security lead	Medium
Diagram IT/OT segmentation by Purdue level; identify undocumented vendor VPNs	OT security lead	High
Separate SIS into its own risk category with physical access logging	Plant/process safety lead	Low
Approve the risk-management measures at board level (Article 20)	Board / management body	Low

Compare this against your existing risk register with NIS2 vs. ISO 27001 if your organisation already holds ISO 27001 certification — most of the access-control and asset-management evidence carries over directly. For a narrower deep-dive on legacy protocol patching exceptions (Modbus, DNP3, firmware-level fixes), see NIS2 ICS security: the legacy DCS patching exception, and for the broader proportionality argument behind relaxed OT SLAs, see NIS2 manufacturing compliance.

Frequently Asked Questions

Does CIR 2024/2690 legally apply to my factory or power plant?
No. The CIR legally binds only ten named digital-infrastructure entity types — DNS providers, TLD registries, cloud and data-centre providers, CDNs, MSPs, MSSPs, marketplaces, search engines, social platforms, and trust service providers. Manufacturing, energy, and water entities are governed directly by Article 21(2); this article uses the CIR’s Annex sections as an interpretive benchmark, not a binding checklist.

Is Modbus or DNP3 traffic without encryption automatically a compliance violation?
Not automatically. Article 21(2)(h) requires cryptography "where appropriate" — a risk-based standard, not an absolute mandate. What auditors expect is a documented decision: why encryption isn’t feasible on that specific legacy link, and what compensating control (network isolation, monitoring) exists instead.

Can I run active vulnerability scans on my OT network at all?
Carefully, and rarely as a first choice. Passive discovery and protocol-native safe querying should cover the majority of the inventory. Where active scanning is genuinely needed, rate-limiting it and scheduling it during planned downtime removes most of the crash risk.

What’s the fastest way to reduce OT risk before the full segmentation project is funded?
Audit and time-box every third-party remote-access connection into the OT network, and put the safety instrumented system into its own risk category with physical access logging. Both are procedural, not capital, projects and close two of the highest-consequence gaps on the table above.

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. NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
2. NIS2 CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure — Advisera
3. "The Purdue Model – Introduction to ICS Security Part 2" — SANS Institute
4. "IEC 62443 Zones and Conduits: How to Apply Them in OT" — Trout Software
5. "Active Network Scanning in Operational Technology (OT)" — ACET Solutions
6. "Dragos 2026 OT Report Shows Surge in Threat Groups and Ransomware" — Dragos, Inc.
7. "Triton (malware)" — Wikipedia
8. "NIS2 Applicability: Essential vs Important Entities" — Glocert International
9. "Annex II NIS 2 — Other Critical Sectors" — Luxgap