NIS2 in depth: patch and vulnerability management in an OT environment

The maintenance engineer looks at the PLC that controls the finishing oven and says what every security plan pretends not to hear: "You don't touch this. It's been running since 2011 and the supplier doesn't even exist any more." The firmware has a known vulnerability, published, with an assigned CVE. And the factory isn't going to stop to apply a patch to a controller running a line in 24/5 production. The articles on NIS2 technical controls and on OT/IT network architecture say what. In this article, the how — patch and vulnerability management in an OT environment under NIS2 — is resolved in technical and operational detail.

The thesis, for those who have read the previous ones and are still deciding: in OT, the answer to most vulnerabilities isn't the patch — it's the compensation. Whoever walks into a factory with an IT-style patch Tuesday calendar fails within three months. NIS2 doesn't require you to apply every patch. It requires you to know what you have, measure the risk of each item and decide with an auditable record when you don't apply. It's a decision system, not an updating system. Whoever inverts this order spends the year fighting production — and remains vulnerable.

There is a second reason this article exists. Most of the northern factories that fall within the scope of NIS2 discovered it recently, and discovered it badly — with a generic IT consultant proposing a patching agent on every machine. That agent doesn't run on the PLC. It doesn't run on the HMI with embedded Windows XP. It doesn't run on the industrial PC whose manufacturer contractually prohibits any change to the operating system on pain of loss of warranty. The generic IT consultant has never seen a printing finishing oven. We've seen dozens. The difference between an IT approach transplanted into OT and an approach born in OT is the difference between a compliance report and a stopped line.

1. Recommended architecture

A finishing line in the Vale do Ave typically has three generations of technology coexisting: embedded Windows XP PCs in printing machines, mid-2000s PLCs and recent HMIs running Linux. No single system manages patches across these three worlds. The architecture has to be designed in layers — and the founding decision is: the inventory cannot be active in OT during production.

It's worth framing the scale of the problem before designing the solution. A medium-sized Vale do Ave textile factory, with spinning, knitting and finishing, easily reaches 80–150 assets with an IP address on the process network — not counting analogue sensors and dumb actuators. A plastic injection unit with handling robots and temperature-control peripherals exceeds 200. And none of these figures appears in the accounting inventory of the MULTI ERP, because for accounting a finishing line is a fixed asset, a line item. For security it is forty communication points, each with its own firmware, its own supplier, its own lifecycle.

Passive discovery first, active in a window

IT discovery tools perform active scanning — they send packets, interrogate ports. On an old PLC, a simple port scan can freeze the controller. We've seen a plastic injection line stop for 40 minutes because a routine scan saturated the TCP/IP stack of an HMI. The rule is hard:

In OT, you build the inventory by listening to the traffic, not by knocking on the door. Active discovery only in a planned shutdown window, and never directly against the PLC.

The passive discovery layer connects to the SPAN/mirror ports of the industrial switches and reconstructs the inventory from Modbus, PROFINET, EtherNet/IP and S7comm traffic. It extracts manufacturer, model, firmware version and — most valuable of all — the communications map. That map is the basis for zero trust in OT networks: you can only microsegment what you know.

The technical reason why passive discovery works in OT and active discovery does not has to do with the nature of the industrial protocols. Modbus, PROFINET and S7comm were designed in the 1990s and 2000s for closed, deterministic networks where no one spoke off-script. They have no authentication, no encryption, and many PLCs have minimalist TCP/IP stacks that assume they only receive well-formed packets from a known SCADA. A modern vulnerability scanner sends dozens of malformed probes per second to detect services. To a 2006 PLC, that is indistinguishable from a denial-of-service attack — and the result is the same: the watchdog fires and the controller reboots. With the line in production.

The four layers

• Passive OT discovery — one sensor per cell/line, connected to SPAN, with no IP address on the process network (isolated management interface).
• Vulnerability correlation — cross-references the inventory with CVE/ICS-CERT databases and supplier advisories (Siemens ProductCERT, Rockwell, Schneider).
• IT patch management — WSUS/update server for the Windows/Linux PCs and HMIs that the supplier's security policy allows updating.
• Decision record — where the compensation lives: each uncorrected CVE has an entry with a compensating control and approval. This is what the competent authority asks for in a NIS2 audit.

The classic mistake is to buy the discovery platform and never build the fourth layer. You end up with a pretty list of 400 vulnerabilities and zero documented decisions. The audit doesn't ask how many vulnerabilities you have — it asks what you decided about each one.

The Purdue model and where the layers sit

Anyone who designs this architecture without reference to the Purdue model (the de facto standard for industrial network segmentation, the basis of ISA/IEC 62443) ends up with sensors in the wrong place. The model stratifies the factory into levels: level 0 is the physical sensors and actuators; level 1 the controllers (PLC, DCS); level 2 local supervision (SCADA, HMI); level 3 factory operations (MES, historian); and levels 4/5 the corporate IT. Passive discovery lives at levels 1 and 2 — that's where the process traffic worth observing flows. The conventional patch server only legitimately touches levels 2 (the Windows/Linux part) and 3. Confusing these boundaries is the root of most of the incidents we describe in section 5.

The right question isn't "which patching tool do I buy?". It's "what traffic crosses the boundary between level 3 and level 2, and who authorised each flow?". Answer that and half the compliance work is done.

Industrial demilitarised zone: the buffer NIS2 presupposes

Between level 3 and the corporate IT there should be an industrial demilitarised zone (IDMZ). No flow crosses directly from the office network to the process network — it always passes through an intermediate system in this buffer zone. This is where the patch server sits (which downloads updates from the internet and serves them internally without the PLC ever touching the internet), the jump host for remote maintenance access, and the collector that exports the risk posture to Qlik Sense. The IDMZ is not optional in a credible NIS2 architecture. It is the point where segmentation-based compensation — which we will see is the dominant answer in OT — stops being an isolated firewall rule and becomes an architectural decision.

2. Parameters, metrics and thresholds

NIS2 (Directive (EU) 2022/2555, transposed by Decree-Law No. 65/2025) does not set patching SLAs. It sets the obligation to manage risk proportionately. The figures below are the ones we use as an operational reference in industrial OT — they are not generic IT and should not be.

Why 90 days and not 30

A finishing line that only stops on Sunday night, once a month, has a real shutdown window of perhaps six hours a month — shared with mechanical maintenance, cleaning and TPM. Requiring an OT patch within 30 days ignores the physics of the factory. The 90 days recognise reality and, crucially, force compensation in the interval. The patch can wait; the mitigation cannot.

It's worth doing the maths explicitly, because it's the argument that convinces the plant manager. If the line stops for six hours a month, and of those six hours preventive mechanical maintenance absorbs three, technical cleaning one, and quality validation of the first post-restart batch another, that leaves one hour for IT/OT activities. Applying a firmware patch to a PLC, with the subsequent communication test and the rollback prepared, rarely fits in less than ninety minutes per controller. In other words: in a typical factory, you can patch perhaps one controller a month without disrupting production. With thirty PLCs, a complete cycle takes two and a half years. This is why compensation isn't laziness — it's arithmetic.

CVSS lies in OT

The total cost of treating each CVE by its CVSS score is unsustainable. CVSS assumes exploitation over the network — but a PLC in a microsegmented cell, with no route to the corporate network, has an effective risk far below the nominal CVSS. Reorder by real exploitability in your environment: is there a network route? is there a public exploit? does the asset control people's safety? A CVSS 9.8 on an isolated controller behind two firewalls is less urgent than a CVSS 6.5 on an HMI accessible from the office network.

Prioritising by pure CVSS in OT is like prioritising maintenance by the alphabetical order of the machine. Technically it's an order. Operationally it's nonsense.

An effective risk model that survives the audit

The NIS2 auditor will ask how you get from a nominal CVSS to a decision. You need a defensible model, written down, applied consistently. What we use combines four multiplicative factors over the CVSS base: network route (can the attacker reach the asset from a less trusted zone?), exploit availability (is there public code or is it in active kits?), physical safety consequence (does the asset control a process that, if compromised, could hurt people — a press, an oven at 200 °C?), and detection capability (if exploited, would you notice?). The result isn't a more precise number — it's an honest prioritisation that separates the five CVEs that matter from the four hundred that don't matter this week.

Metrics the CEO+CFO+IT trio understands

The factory's self-made IT lead doesn't want a 400-page report. They want three indicators that fit on a Qlik Sense screen and that answer the CEO's question: "are we protected or not?". The ones that work: percentage of OT assets with a documented decision (target 100% of critical ones); number of overdue compensations awaiting reassessment (target zero); and average age of the last inventory reconciliation per cell. These three tell you, without jargon, whether the system is alive or whether it's drawer documentation. A CFO grasps the second metric in five seconds — every overdue compensation is a risk accepted by no one, the worst kind of risk.

3. Practical configuration

Three illustrative examples. They are neither credentials nor real topologies — they are patterns we apply.

Firewall rule as a compensating control

When a PLC has a critical CVE with no patch available, the typical compensation is to reduce the communication surface to the strictly necessary. On an industrial firewall, the explicit rule — default deny, allow only the SCADA↔PLC pair on the protocol port:

# Compensation for CVE-XXXX-YYYY on the line 3 PLC (no supplier patch)
Only the SCADA server talks to the PLC, only over Modbus/TCP (502). Everything else blocked.
set rule "compensa-clp-linha3" from zone OT-SCADA to zone OT-CELULA-3 \
    source 10.20.10.5 destination 10.20.30.11 \
    service tcp/502 action allow log enabled
set rule "deny-celula-3-default" from zone any to zone OT-CELULA-3 \
    action deny log enabled
Reference to the decision record: ticket NIS2-2025-0142

Note the log enabled on both rules. It's not decoration. The log of the allow rule confirms that the SCADA is indeed talking to the PLC as expected — if it stops generating entries, something has changed. The log of the deny rule is your detection system: any entry here means that something tried to reach the cell outside the authorised flow. In an architecture without dedicated passive monitoring, these two logs are the minimum viable detection, and the competent authority will want to see that they are collected and reviewed.

Deep packet inspection of the industrial protocol

The modern industrial firewall does more than filter by IP and port — it inspects the protocol content. A stronger compensation rule doesn't just allow Modbus/TCP to the PLC; it allows only Modbus read functions, blocking unauthorised writes. If the SCADA only needs to read states and the PLC should not receive commands from that source, restricting to the read function codes drastically reduces the surface even with the CVE uncorrected:

# Reinforced compensation: allow only Modbus reads from the data collector
Function codes 3 (Read Holding Registers) and 4 (Read Input Registers)
set rule "leitura-clp-linha3" from zone OT-HISTORIAN to zone OT-CELULA-3 \
    source 10.20.10.9 destination 10.20.30.11 \
    service modbus modbus-function 3,4 action allow log enabled
Writes (function 5,6,15,16) implicitly denied by the default deny

Passive discovery — port mirroring configuration

# Managed industrial switch: mirror cell traffic to the discovery sensor
The sensor does NOT have an IP on the process VLAN — it only receives a copy of the traffic
monitor session 1 source interface Gi1/0/1 - 8 rx
monitor session 1 destination interface Gi1/0/24
Gi1/0/24 connects to the OT discovery sensor (capture interface, no TX)

Decision record entry (schema)

The decision record is the artefact the NIS2 audit wants to see. Keep it versioned and immutable — ideally within the approval workflow of your Document Management, with an eIDAS qualified signature from whoever approves the residual risk.

{
  "cve": "CVE-XXXX-YYYY",
  "ativo": "CLP-LINHA3-ESTUFA",
  "cvss_nominal": 9.1,
  "risco_efetivo": "MEDIO",         // reassessed by real exploitability
  "patch_disponivel": false,
  "decisao": "COMPENSAR",           // PATCH | COMPENSAR | ACEITAR
  "compensacao": "segmentacao + regra firewall NIS2-2025-0142",
  "reavaliar_em": "2025-09-30",
  "aprovado_por": "responsavel_seguranca",
  "assinatura_eidas": "presente"
}

Why the eIDAS signature isn't bureaucracy

A security lead who accepts residual risk over a PLC that controls an oven at 200 °C is assuming a concrete personal and organisational responsibility. NIS2 holds the management body accountable — in the article on governance, the directive makes the administration directly responsible for overseeing the risk management measures, with the possibility of personal liability. The eIDAS qualified signature on the decision record entry does two things: it proves when the decision was taken (timestamp) and by whom, with legal value equivalent to a handwritten signature. In an audit or, worse, a post-incident, the difference between "we decided to compensate in March, signed by the person responsible" and "it's somewhere in a spreadsheet" is the difference between demonstrating due diligence and not being able to prove it.

4. Integrations and dependencies

None of these pieces works in isolation. The value is in the chain — and the chain has specific points of failure.

The dependency no one anticipates: the production shutdown calendar. If the patch system doesn't know the real shutdown window, it schedules updates that production cancels the day before. Integrating the maintenance plan — the same one that feeds the TPM — with the patching calendar eliminates 80% of the friction between security and the shop floor. Without this link, the CISO and the plant manager spend the year arguing by email.

The machine supplier dependency — and its warranty clause

There is a contractual dependency that rarely appears in architecture diagrams and that derails entire projects: the machine supply contract. Many industrial equipment manufacturers — in printing, plastic injection, automated footwear cutting — sell the machine with the control PC as a sealed box. Any change to the operating system, including Microsoft security patches, voids the warranty and, worse, the maintenance contract. The security lead wants to apply the patch; the production director reminds them that if the machine breaks down, the supplier refuses to intervene because "they touched the system". This tension is resolved in one of three ways: negotiate with the supplier a list of authorised patches (the best case, increasingly common under NIS2 pressure on the customer); compensate over the network when the supplier won't cooperate; or replace the equipment in the next investment cycle, requiring support for security updates in the tender specification. Write this clause into every new machine contract. It's the cheapest decision you'll make.

Supplier remote maintenance: the door left wide open

The most common compromise route in industrial OT isn't the exotic CVE — it's the machine supplier's remote maintenance access. The brand's technician connects from another country to diagnose a fault, and to do that someone opened a VPN tunnel three years ago that was never closed again. Often with shared credentials, without MFA, without session logging. This is a vulnerability that has no CVE and appears in no database — but it's the one that incident reports on industrial control systems repeatedly associate with the most serious intrusions. The compensation: all remote access goes through a jump host in the IDMZ, with MFA, recorded session, and activated only on request, with a closed time window. No exceptions for "the supplier needs permanent access". They don't.

The best-configured industrial firewall in the North was bypassed by a technician who connected via TeamViewer installed on a control PC "to be faster next time there's a problem". The attack surface that matters is rarely the one in the vulnerability report.

5. Operational pitfalls

What we've seen break in production, anonymised, with the fix.

• Active scan against a PLC in production. A mould factory ran a "routine" vulnerability scan at 3 p.m. Two controllers rebooted. Fix: passive discovery always; active only during shutdown and never against the controller — against the network around it.
• Automatic Windows patch on a validated HMI. A Microsoft cumulative update broke the communication driver of a printing HMI; the line went blind to the process. Fix: exclude HMIs from automatic WSUS, test in a mirror environment, apply in a window.
• Inventory done once and never reconciled. Eight months later, 30% of the assets had firmware different from what was recorded — maintenance had swapped parts. Fix: continuous passive reconciliation, not a project Excel.
• CVE list without a decision record. An audit asked for the decision on a specific CVE; the answer was "it's on the list". Not enough. Fix: each critical item has a decision that is dated, signed and re-assessable.
• Industrial firewall in "temporary" allow-all mode. The "temporary" lasted three years because no one knew which rules production needed. Fix: derive the rules from the passive discovery communications map — the system itself tells you what's legitimate.
• Compensation without a reassessment date. A firewall rule used as mitigation became eternal; the supplier released a patch and no one applied it. Fix: every compensation has a mandatory reavaliar_em.
• Discovery sensor with an IP on the process network. Installed "to be easier to manage", it became itself an attack surface on the most critical VLAN. Fix: capture interface with no TX, management on a separate VLAN.

Two less obvious pitfalls

There are two failures that only appear in more mature factories, already with a discovery platform installed, and which for that reason deceive those who think themselves safe. The first: the discovery sensor that doesn't see the whole VLAN because the SPAN was misconfigured. The switch mirrors eight ports, but the cell has twelve devices and four are on another cascaded switch with no mirror configured. The inventory looks complete — it covers 100% of what the sensor sees — but a third of the cell is invisible. Fix: validate the SPAN coverage against the number of physical devices counted on the floor, not against what the sensor reports.

The second: the firmware the supplier "fixed" but never communicated via CVE. Many PLC manufacturers fix vulnerabilities silently in a new firmware revision, without publishing an advisory or assigning a CVE. Your vulnerability database cross-references the inventory with known CVEs and flags nothing — but you are running vulnerable firmware for which a fix has existed for two years. Fix: subscribe directly to the ProductCERT bulletins of your main suppliers (Siemens, Rockwell, Schneider) and reconcile the inventory's firmware versions with the latest available revisions, regardless of whether there's a CVE.

The worst OT vulnerability we found wasn't in the PLC. It was in the belief that the 2022 project inventory still described the 2025 factory.

6. Final technical decision

No hedging. The choice changes with size and sector.

The rule that runs across the table: below 30 assets, invest in network architecture before buying a tool; above 200, the manual process fails and you need SIEM. In the middle — most of the northern factories — the combination of passive discovery, firewall compensation and a signed decision record is the optimal point between cost and auditability in an audit. Connect everything to your Business Continuity strategy and test it as we describe in disaster recovery in the factory: a vulnerability management system that has never been exercised is documentation, not defence.

The scoping question: are you an essential or an important entity?

Before sizing any investment, resolve a prior question that many skip: which NIS2 category does your company fall into? The directive distinguishes essential entities from important entities, with different supervision regimes and fines, and the scoping depends on the sector and the size. A good part of manufacturing — including the making of certain products — falls within scope depending on the size criterion (the general threshold sits at companies with at least 50 employees or turnover/balance sheet above 10 million euros). Many northern factories, which always saw themselves as "too small for this", are within scope. Confirm your scoping with the CNCS or with specialist legal support before deciding on the level of investment — because the category determines the rigour of the obligations and the weight of the fines in the event of non-compliance.

The investment order that avoids waste

If budget is limited — and in an industrial SME it always is — the order matters more than the total. First: network segmentation and closing the permanent remote accesses. It's the intervention with the greatest risk reduction per euro, and it doesn't depend on buying any platform. Second: passive inventory, even if just one sensor per critical line, to know what you have. Third: the decision record, even if it starts out structured in Document Management with an eIDAS signature before there's an automated platform. Only afterwards, when the volume justifies it, the dedicated OT discovery platform and the SIEM. Inverting this order — buying the expensive platform first, with the network still flat and the remote accesses open — is the mistake we see funded by poorly designed applications: the subsidy is spent on the visible tool and the architecture, which is what really protects, is left for "phase 2" that never comes.

Funding: what gets through and what stays stuck in the technical report

Industrial cybersecurity is eligible under several PT2030 and PRR instruments, especially when framed within industrial digital transition projects (Industry 4.0) and not as isolated IT expenditure. What usually gets through: investment in segmented network equipment, OT monitoring platforms and implementation services, when linked to a measurable production objective — reducing unplanned stoppages, ensuring continuity, meeting international customer requirements. What stays stuck in the technical report: applications that describe "improving security" without an impact indicator, without a baseline, without a link to the production process. Write the application around OEE and production continuity, with KORA Productivity providing the baseline, and the cybersecurity component enters as an enabler — not as an end in itself. This is the difference between approval and the eternal request for additional clarifications.

7. How INFOS implements it

We work OT patch and vulnerability management within the cybersecurity service and the network architecture, anchored in what we already know about the factory through the MULTI ERP and KORA Productivity on the shop floor — which gives us the real shutdown calendar to schedule without stopping production. The decision record lives in Document Management with an eIDAS signature, and the risk posture is made visible in Qlik Sense for the CEO+CFO+IT trio that decides. We don't sell a list of vulnerabilities. We deliver an auditable decision system for the Portuguese industrial sector.

What sets us apart from a generic security integrator is the starting point. We arrive at your factory already knowing what a collection of 800 SKUs in footwear is, what "month-end" means in a garment maker near Famalicão, and why the warehouse foreman won't step away from the radio for two hours for a rollout. That industrial fluency means the compensation we propose respects the physics of production — rather than fighting it. NIS2 isn't a compliance project you dispatch and file away. It's a living decision system that has to coexist with 2011 ovens, HMIs with embedded XP and a shutdown window of six hours a month. Whoever designs ignoring this delivers a report. Whoever designs respecting this delivers defence that holds up on the day no one is watching.

Sources

• Directive (EU) 2022/2555 (NIS2), Official Journal of the European Union; national transposition by Decree-Law No. 65/2025, Diário da República.
• CNCS — National Cybersecurity Centre / CERT.PT, 2024 incident report.
• IBM, Cost of a Data Breach Report 2024.
• Verizon, Data Breach Investigations Report (DBIR) 2025.
• ISC2, Cybersecurity Workforce Study 2024.
• ENISA / ICS-CERT (CISA), advisories on vulnerabilities in industrial control systems.
• ISA/IEC 62443, series of standards for security of industrial automation and control systems.

Frequently asked questions

What is passive discovery in OT and why is it preferable to active discovery?

Passive discovery observes the existing traffic on the industrial network without sending probes. Active tools send packets that can freeze old PLCs or saturate the TCP/IP stack, stopping production lines. In OT, the inventory is reconstructed from Modbus, PROFINET and S7comm traffic, extracting manufacturer, model and firmware version without operational risk.

Why can a port scan stop a production line?

Old PLCs have minimalist TCP/IP stacks that assume only well-formed packets from known sources. A modern scanner sends dozens of malformed probes per second. To the PLC, this is indistinguishable from a denial-of-service attack, triggering the watchdog that reboots the controller — stopping production.

Does NIS2 require every patch to be applied in an OT environment?

No. NIS2 requires you to know what you have, measure the risk of each vulnerability and decide with an auditable record when you don't apply. Most vulnerabilities in OT are resolved by compensation, not by patch. The regulator assesses the documented decisions, not the number of patches applied.

What is a compensating control in OT vulnerability management?

It's a measure alternative to the patch when the update isn't operationally viable. Examples: network microsegmentation, behavioural monitoring, access restriction. Each uncorrected CVE should have a documented entry with the compensating control and approval — this is what the NIS2 audit verifies.

What is the typical scale of IP assets in a Vale do Ave factory?

A medium textile factory with spinning, knitting and finishing reaches 80–150 assets with an IP address on the process network, not counting analogue sensors. A plastic injection unit exceeds 200. These figures don't appear in the accounting ERP because accounting sees the line as a fixed asset, while security sees forty distinct communication points.

How is the patch management architecture structured in OT?

In four layers: passive discovery per cell/line; vulnerability correlation with CVE/ICS-CERT databases; patch management for Windows/Linux systems that the supplier allows updating; a decision record documenting each uncorrected CVE with compensating controls. The classic mistake is to stop at the first layer, leaving vulnerabilities without an auditable decision.

Why doesn't a generic IT patching agent work in OT?

Agents don't run on PLCs, HMIs with embedded Windows XP or industrial PCs whose manufacturers prohibit changes to the OS on pain of loss of warranty. An approach born in OT, designed in layers and respecting the operational limitations, avoids line stoppages and maintains regulatory compliance.

What is the Purdue model and what is its relevance to vulnerability discovery?

The Purdue model stratifies the factory into levels: sensors/actuators (0), controllers (1), local supervision (2), operations (3) and corporate IT (4/5). Passive discovery operates at levels 1 and 2, where the relevant process traffic flows. Designing the architecture without this reference places sensors in the wrong spot and compromises segmentation.