NIS2 OT Compliance: The Proportionality Argument, Asset Inventory, and Patch Exception Playbook for Industrial Networks

A 20-year-old programmable logic controller doesn’t take a Windows update. It can’t run an endpoint agent, and if you scan it the wrong way, it can trip a safety interlock and shut down a production line. NIS2 doesn’t care. Article 21 applies the same directive to that PLC as it does to a cloud tenant running the latest patch cycle — the difference is that the law also builds in a mechanism, proportionality, that’s supposed to account for exactly this gap. Most compliance content treats OT as a checkbox variant of IT security. It isn’t. The controls are different, the evidence auditors expect is different, and the single most common mistake — assuming the 150-control CIR 2024/2690 Annex applies to a factory floor — sends manufacturing and energy teams chasing requirements that were never written for them.

This guide covers what’s specific to operational technology: how to construct a proportionality argument that survives scrutiny, how to inventory OT assets without tripping the systems you’re trying to protect, how to document a patch exception with compensating controls instead of pretending you can patch a system the vendor abandoned in 2014, and why the 24-hour incident clock is harder to hit in OT than in IT.

This article provides general information only and does not constitute legal advice. NIS2 implementation varies by member state and sector — always verify requirements against your national transposition law and applicable authority guidance.

Does NIS2 Apply to Your OT Environment?

Plain-language summary: if your organisation falls into one of the eleven Annex I sectors or seven Annex II sectors and meets the size thresholds, NIS2 applies to your operational technology the same way it applies to your IT — there’s no OT carve-out in the directive itself.

Energy and manufacturing are the two sectors where OT dominates the risk conversation, and they sit in different tiers. Energy — electricity, district heating/cooling, oil, gas — is one of the eleven Annex I “sectors of high criticality,” which generally makes energy operators essential entities. Manufacturing — specifically medical devices, computers/electronics/optical products, electrical equipment, machinery, motor vehicles, and other transport equipment — sits in the seven Annex II “other critical sectors,” generally making these operators important entities [7]. The distinction matters operationally: essential entities face proactive supervision (competent authorities can inspect before an incident), while important entities are typically supervised reactively (after an incident or a complaint). Note: national transposition may adjust thresholds and supervision detail — confirm with your national competent authority.

Sector	Annex	Typical Entity Category	OT Relevance
Energy (electricity, gas, oil, district heating)	Annex I	Essential	Very high — SCADA, RTUs, protection relays
Manufacturing (machinery, electronics, medical devices, motor vehicles)	Annex II	Important	Very high — PLCs, DCS, MES, robotics
Water / wastewater	Annex I	Essential	High — SCADA, pump/valve control
Digital infrastructure (DNS, cloud, CDN, MSP/MSSP)	Annex I	Essential	Low — mostly IT, but subject to CIR 2024/2690’s detailed Annex (see below)

The Proportionality Argument: Building a Case Auditors Won’t Reject

Plain-language summary: “proportionate” isn’t a synonym for “optional” — it’s a documented judgment call you have to be ready to defend, not a reason to skip a control.

Article 21(1) is explicit about what proportionality weighs: the entity’s size, its degree of exposure to risk, the likelihood and severity of incidents (including societal and economic impact), the state of the art, and the cost of implementation [1]. That’s five factors, not a vague gesture at “reasonableness.” For an OT environment, the constructible argument looks like this:

• Exposure: name the specific asset class and its blast radius — a legacy HMI on an isolated production cell carries different exposure than a SCADA master station with WAN connectivity to a control centre.
• Severity: tie the impact to safety and continuity, not just data confidentiality — OT incidents can stop production or, in worse cases, threaten physical safety, which raises the severity weighting even for a small entity.
• State of the art: compare against IEC 62443 zone/conduit segmentation as the recognised industrial standard, not generic IT frameworks that assume patchable endpoints [8].
• Cost of implementation: document why full remediation (e.g., replacing an end-of-life PLC line) isn’t proportionate against a compensating-control alternative that closes most of the same risk at a fraction of the cost.

The mistake we see most often: treating “proportionate” as a reason not to document anything. Auditors don’t reject organisations for having a gap — they reject organisations that can’t show they weighed the five factors and reached a defensible conclusion. A one-page justification memo per asset class, referencing these five factors explicitly, is the difference between a documented risk decision and an unexplained gap.

The CIR 2024/2690 Scope Boundary Most OT Guides Get Wrong

Plain-language summary: the 150-control technical Annex you’ve probably seen referenced everywhere does not apply to your factory or your substation — it’s written for a specific, narrow slice of digital-infrastructure entities.

Commission Implementing Regulation 2024/2690 is the detailed, 13-section technical Annex that extends Article 21 into more than 150 specific controls. It’s frequently cited as if it’s the universal NIS2 technical standard. It isn’t. Its Article 1 scope applies only to the entity types named in NIS2 Article 21(5): DNS service providers, TLD registries, cloud computing providers, data centre providers, content delivery network providers, managed service and managed security service providers, providers of online marketplaces/search engines/social networking platforms, and trust service providers [3]. If your organisation is a manufacturer or an energy operator and none of those categories describes you, the CIR’s 150 controls are not your binding compliance standard — your obligation is the general Article 21(1)-(2) risk-based, proportionate approach described above.

Why this matters in practice: teams that treat the CIR Annex as universal end up building documentation against controls they’re not legally required to meet, while under-investing in the OT-specific gap analysis the general Article 21 test actually demands. That said, the CIR Annex’s 13 thematic sections — including Section 12, asset management — are useful reference material even where they’re not binding, because ENISA’s companion guidance translates each section into OT-relevant methodology [4][9]. Use it as a design pattern, not a checklist you’re required to complete.

Building an OT Asset Inventory: Passive vs Active Discovery

Plain-language summary: you can’t secure or patch what you can’t see, but the discovery method that works for laptops can shut down a production line — OT asset inventory needs its own methodology.

Germany’s BSI, the national competent authority for NIS2-regulated entities, states plainly that “a functioning asset management forms the basis” for the patch and vulnerability management requirements that follow, and confirms these requirements apply explicitly to OT: “industrial control and automation systems as well as building automation systems” [5]. In August 2025, eight national cybersecurity agencies — led by the U.S. CISA, with BSI among the co-authors — published joint guidance identifying why OT inventory is harder than IT inventory: version status frequently isn’t tracked, assets get folded into “grown” structures without clear naming conventions, product lifecycles run far longer than IT hardware, and most operators simply don’t run a dedicated asset-management system for their OT estate [6].

The practical discovery method splits into two tiers, and the choice isn’t optional — it’s dictated by what the device can tolerate:

• Passive discovery (default for production OT): fingerprint devices from network traffic to map zones and links, flag rogue services, and parse vendor configuration files and topology exports without sending a single packet to the device itself. This is the safe default for anything running a live process.
• Active-light discovery (limited, controlled use): narrowly scoped queries to confirm device identity or firmware version, used only where passive methods can’t resolve a gap, and only outside the live production window where possible. BSI’s own guidance concedes this: for OT devices, vulnerability scanning “can take place outside the production environment” — an explicit acknowledgement that blind active scanning inside a live process is not the expectation [5].

A usable OT asset record captures more than a hostname: device type and function, firmware/OS version, physical location and network zone (mapped to your IEC 62443 zone/conduit model), vendor and support end-of-date, and the compensating controls currently protecting it if it can’t be patched. That last field is what turns an inventory into evidence for the proportionality argument above — and it’s the bridge into patch management.

Patch Management for Systems You Can’t Patch: The Compensating-Control Decision Tree

Plain-language summary: when a vendor patch doesn’t exist, isn’t compatible, or can’t be deployed without an unacceptable outage, the auditor’s question isn’t “why didn’t you patch” — it’s “what did you do instead, and can you prove it.”

Run every known OT vulnerability through this sequence and document the answer at each step:

1. Is a vendor patch available for this exact firmware/OS version? If no — move to compensating controls and document the end-of-support date as your justification (Low effort: check vendor advisory).
2. Can the patch be deployed inside a scheduled maintenance window without violating a safety interlock or SLA? If no — hold the patch, move to compensating controls, and set a re-review date tied to the next maintenance window (Medium effort: coordinate with operations/safety).
3. Can you compensate at the network layer? Tighten IEC 62443 zone/conduit segmentation around the asset, restrict the conduit to only the traffic the process requires, and add monitoring for anomalous connections (Medium effort: firewall/segmentation change).
4. Can you compensate at the host layer? Application allow-listing on the HMI or engineering workstation, disabling unused services, and tightening physical/local access to the device (High effort: requires vendor sign-off on supported configurations in many cases).
5. Sign off residual risk. Where compensating controls reduce but don’t eliminate the exposure, document the residual risk, the compensating controls applied, and get it accepted at the appropriate authority level — this record is what an auditor expects to see instead of a patch log entry.

The order matters: network-layer compensating controls are usually faster and less disruptive to implement than host-layer changes on a live industrial system, which is why they come first in the sequence. Skipping straight to “accept the risk” without working through segmentation and monitoring options first is the pattern that fails Article 21(1)’s cost-of-implementation and state-of-the-art test — a segmentation change is rarely more expensive than the incident it prevents.

OT Incident Reporting: Why the 24-Hour Clock Is Harder to Hit

Plain-language summary: Article 23’s reporting clock doesn’t run slower for OT, but OT environments are frequently the ones least equipped to notice an incident inside that window.

Article 23 sets an identical timeline regardless of sector: an early warning within 24 hours of becoming aware of a significant incident, a fuller incident notification within 72 hours, and a final report no later than one month after the notification [2]. “Significant” means the incident has caused or is capable of causing severe operational disruption or financial loss, or considerable damage to others [2] — a production-halting OT incident clears that bar easily.

The gap is detection, not the deadline. Many OT environments run without centralised logging, without a SOC watching the industrial network, and without the telemetry an IT SOC takes for granted — which means the 24-hour clock can already be running before anyone in security even knows an incident occurred. Closing that gap doesn’t require replacing OT with IT tooling; it requires the passive monitoring described in the asset-inventory section above to double as an early detection layer, and a documented escalation path from operations staff (who notice the process anomaly first) to whoever owns the Article 23 notification.

Who Owns What: Role-Impact for OT Compliance

Plain-language summary: OT compliance fails when it’s treated as a pure IT security project — it needs operations, safety, and the board at the table, not just the CISO.

Role	What They Need From This
CISO / OT Security Lead	The proportionality framework and the patch decision tree — the technical evidence trail auditors will actually ask for.
SME Owner (non-technical)	The scope table above (do I even fall under Annex I or II?) and the plain-language summaries — a starting point that doesn’t require a security background.
Compliance Officer / Legal	The CIR scope-boundary clarification, so effort isn’t wasted meeting a standard that doesn’t legally bind the organisation, and the Article 23 deadline precision.
Board / C-Suite	The penalty exposure below and the residual-risk sign-off step in the patch decision tree — both are board-level accountability points under Article 20.

Penalties and Enforcement Exposure for OT Non-Compliance

Plain-language summary: the maximum fine tiers are the same whether the failure is in IT or OT — an undocumented OT gap carries the same exposure as an undocumented IT one.

Under Article 34, essential entities may face administrative fines of up to €10,000,000 or 2% of total worldwide annual turnover, whichever is higher; important entities face up to €7,000,000 or 1.4% of turnover, whichever is higher. These are maximum levels — actual penalties are subject to national implementing law and supervisory authority discretion, and additional or stricter provisions may apply at member-state level [1]. Note: reporting portals, exact thresholds, and enforcement practice vary by member state — confirm current figures and process with your national competent authority.

Trigger	Exposure	Entity Type
Failure to implement Article 21 risk-management measures (including undocumented OT proportionality decisions)	Up to €10M / 2% turnover	Essential
Failure to implement Article 21 measures	Up to €7M / 1.4% turnover	Important
Failure to meet Article 23 notification deadlines	May reach the same maximum levels, subject to national law	Both

OT Compliance Checklist

Step	Effort
Confirm Annex I/II sector classification and essential/important status	Low
Draft a one-page proportionality justification per major OT asset class	Medium
Confirm whether CIR 2024/2690 legally applies (Art. 3(1)(b)-(e) entity types only)	Low
Build a passive-discovery OT asset inventory (capture firmware, zone, support end-date)	High
Run undocumented vulnerabilities through the compensating-control decision tree	High
Document an OT-specific Article 23 escalation path from operations to the notifying function	Medium
Brief the board on residual-risk sign-offs and Article 34 exposure	Low

Frequently Asked Questions

Does NIS2 apply to OT that’s fully air-gapped?

Air-gapping reduces exposure — one of the five proportionality factors — but it doesn’t remove the obligation. Article 21 still requires a documented, proportionate approach for air-gapped OT; “it’s air-gapped” is the start of a justification, not the whole one.

Do I need to meet all 150 CIR 2024/2690 controls for my factory?

Only if your organisation is one of the specific digital-infrastructure entity types named in Article 21(5) — DNS providers, cloud/CDN/data-centre providers, MSPs/MSSPs, online marketplaces, or trust service providers [3]. A manufacturer or energy operator follows the general Article 21 proportionate approach instead, though the CIR’s structure is useful as design reference.

What if a legacy PLC has no vendor support at all?

Run it through the compensating-control decision tree: network-layer segmentation and monitoring first, host-layer controls where the device supports them, then a documented residual-risk sign-off. “No vendor support” is itself part of the state-of-the-art and cost-of-implementation justification — document it rather than leaving the gap unexplained.

Is active vulnerability scanning ever acceptable in OT?

Narrowly — limited, targeted queries to confirm identity or firmware version, and ideally outside the live production window. Broad active scanning inside a running process is the pattern that causes outages and is not what regulators or national authorities expect as the default method [5].

Sources

• NIS2 Directive Article 21 — Cybersecurity risk-management measures
• NIS2 Directive Article 23 — Reporting obligations
• Advisera — NIS2 CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure
• OpenKRITIS — NIS2 Implementing Act DVO (EU) 2024/2690
• BSI (German national competent authority) — NIS2 Sicherheitsmaßnahmen und Schwachstellenmanagement
• BSI press release — joint CISA-led OT asset inventory guidance
• Advisera — NIS 2 Annex 1: Sectors of High Criticality
• Fortinet — The Purdue Model for ICS Security
• ENISA — NIS2 Technical Implementation Guidance