NIS2 and OT Cybersecurity in Manufacturing: Governance and Risk

The NIS2 Directive turns cybersecurity into a corporate governance obligation for thousands of European industrial companies: management answers for risk management, not just the IT department. On the shop floor, moreover, the problem has a layer of its own: OT systems (PLCs, SCADA, cell networks) are not protected with the same tools or the same assumptions as office computing. This guide explains what NIS2 demands at a conceptual level, why the OT environment is different, and where to start: asset inventory and segmentation before any technology purchase.

What NIS2 is and who it applies to

NIS2 is Directive (EU) 2022/2555, the second European directive on the security of network and information systems. It replaces the original NIS of 2016 and notably widens its reach: where the first directive focused on essential service operators designated one by one by each Member State, NIS2 defines whole categories of sectors and applies by default to companies above certain size thresholds within them. Being a directive rather than a regulation, it needs national transposition, and the fine print (exact deadlines, the precise sanctions regime, the supervisory authority) depends on how each country incorporates it. What follows is the common conceptual framework, which is stable.

The directive distinguishes two tiers of subjects: essential entities and important entities. The practical difference lies mainly in the intensity of supervision and the sanctions regime, not in the substantive obligations, which are essentially the same for both. The covered sectors include energy, transport, water, health, digital infrastructure and, in the annex of important sectors, the manufacturing of certain product categories, the chemical industry and the food industry, among others. The general size criterion points to medium and large companies: as a rule of thumb, from 50 employees or 10 million euros of turnover within a covered sector it is worth analysing whether you fall within scope. That analysis must be done with the national transposition in hand, not with the bare directive.

There is a nuance many industrial companies overlook: even if a plant is not formally within the scope of NIS2, its customers very probably are. The directive obliges subjects to manage their supply-chain risk, which in practice means a mid-sized manufacturer can receive security questionnaires, contractual clauses and audits from its essential customers even if the rule does not apply to it directly. Regulatory pressure propagates upstream along the value chain.

What NIS2 demands in risk governance

The core of NIS2 is not a shopping list of security products. It is an obligation to manage risk demonstrably. Article 21 of the directive lists the minimum measures every subject must adopt, always under a criterion of proportionality to the risk. Summarised at a conceptual level:

• Risk analysis and security policies for information systems: knowing what you have, which threats affect it and what you have decided to do about it, in writing.
• Incident handling: the ability to detect, respond and notify. NIS2 introduces staged notification deadlines to the competent authority, with an early warning within the first 24 hours of becoming aware of a significant incident.
• Business continuity: backups, disaster recovery and crisis management. In a plant, this includes the uncomfortable question of how long you can produce without the affected systems.
• Supply-chain security: assessing the risk introduced by suppliers and service providers, including the integrators and maintenance contractors who connect to plant equipment.
• Security in the acquisition, development and maintenance of systems, including vulnerability management.
• Cyber hygiene and training, for management too.
• Cryptography, access control, asset management and multi-factor authentication where appropriate.

The deepest change from previous practice concerns accountability. NIS2 establishes that management bodies must approve the risk-management measures, oversee their implementation and can be held liable for non-compliance. They must also be trained in the subject. This takes cybersecurity out of the technical basement and places it on the same plane as financial or occupational risk: a board matter, with documentary evidence that it is treated as such.

Why OT security is not IT security

When an industrial company tackles NIS2, the usual reflex is to extend the IT department's practices to the plant: antivirus, monthly patching, vulnerability scans. That reflex fails because the OT environment (operational technology: PLCs, SCADA, HMIs, drives, robots, cell networks) inverts the classic priorities of information security. In IT the order is confidentiality, integrity, availability. In OT the order flips: first availability and the physical safety of the process, then the integrity of the signals, and confidentiality last. A temperature reading is not a secret; its arriving late or tampered with is a problem.

The practical differences that follow from that inversion deserve a table:

That is why the reference framework on the shop floor is not just ISO/IEC 27001, designed for information security management systems in general, but the IEC 62443 family, written specifically for industrial automation and control systems. IEC 62443 contributes two ideas that NIS2 does not detail but that fit its requirements naturally: the concepts of zones and conduits to segment the network by function and criticality, and security levels (SL) to grade the measures according to each zone's risk instead of applying a one-size-fits-all. A serious OT programme uses NIS2 as the governance mandate and IEC 62443 as the technical manual.

Let us imagine, as a running thread, a plastic injection moulding plant with 25 machines, a cloud ERP and two external integrators who connect via remote desktop for maintenance. It is an ordinary profile. Its real risk is usually not a textbook targeted attack: it is the ransomware that comes in through office email, crosses into the plant network because the two were never separated, and encrypts the machine running the SCADA. Production stops not because the PLCs are compromised, but because nobody can supervise it or load programs. That scenario, far more common than sophisticated sabotage, is exactly what the basic measures in this guide reduce.

First step: OT asset inventory

You cannot govern the risk of what you do not know exists, and NIS2 explicitly requires asset management. In practice, most plants have no reliable inventory of their OT estate: PLCs installed fifteen years ago by an integrator who no longer works with the company, network cards added in an expansion, 4G routers a supplier left connected to a machine for remote support that nobody remembers. Each of those elements is attack surface.

A useful OT inventory records, at a minimum, for each asset:

• Identification: manufacturer, model, firmware or operating system version.
• Process function: which machine or line it controls and what happens if it stops.
• Connectivity: network addresses, protocols it speaks, who it communicates with.
• Access: who can touch it, locally and remotely, and with which credentials.
• Support status: whether the manufacturer still publishes updates.
• Criticality: a simple classification (high, medium, low) based on impact.

The method matters as much as the result. In OT, active discovery (scanning the network the way an IT tool would) is risky: there are old controllers that reboot when they receive an unexpected packet. Sound practice combines passive discovery (listening to traffic on the plant switches), documentary review of electrical schematics and automation projects, and a physical walk-through of the cabinets. In our injection moulding plant, the physical walk-through is what finds the forgotten 4G router; passive listening is what reveals a machine talking to an external IP nobody could explain.

This survey work fits naturally within a wider operational diagnosis: the same visit that maps production flows and data capture can map the estate of connected assets and their access paths. Doing the two exercises separately tends to duplicate effort and produce two incompatible pictures of the same plant.

Second step: network segmentation

With the inventory in hand, the highest-impact measure per euro invested is segmentation. The typical starting point is a flat network: offices, guest wifi, SCADA and PLCs in the same broadcast domain, so that any compromised device can reach any controller. Segmentation breaks that continuity and turns an office incident into an office incident, not a production one.

The classic conceptual model is the Purdue levels, and its modern operational translation is the zones and conduits of IEC 62443. Without getting into complex architectures, three moves concentrate most of the benefit:

1. Separate IT from OT with a firewall that only allows the flows identified in the inventory. Everything not justified, closed. If the ERP needs plant data, that flow is documented and allowed; the rest is not.
2. Create an intermediate zone (industrial DMZ) for the services both worlds need: historians, file exchange servers, data brokers. Neither does IT talk directly to the PLCs nor do the PLCs go out to the internet.
3. Segment within OT by cells or lines, so a problem on one line does not propagate to the others. In the injection moulding plant, each group of machines with its HMI can be a zone; the central SCADA, another.

Third-party remote access deserves a separate mention, which in our example meant two integrators on remote desktop. It is the entry point most cited in real industrial incidents: shared credentials, permanent access that should be occasional, no session logging. The reasonable target is a single entry point, with named accounts, multi-factor authentication, access limited in time and scope, and a record of what is done. The reference architecture to evolve towards, with explicit verification of every access instead of trust by network location, is developed in the pillar on zero trust applied to industrial OT environments, which covers the network architecture and connectivity side with the depth that does not belong here.

Cyber risk on the boardroom agenda

Everything above is technique. NIS2, however, is above all a governance rule, and the most common mistake is treating it as an IT manager's project. The directive asks management to approve and oversee; to do so knowledgeably, cyber risk has to enter the decision-making bodies with the same treatment as any other business risk.

In a mid-sized industrial company, that comes down to a few pieces, but stable ones:

• A named owner for OT security, even if not full-time dedicated. Without an owner, the measures degrade.
• A risk register that management reviews periodically: which scenarios cause concern (SCADA downtime from ransomware, loss of maintenance remote access, tampering with recipes), what probability and impact are assigned to them and what is being done about each one.
• Documented decisions. Accepting a risk is legitimate; what NIS2 does not tolerate is not having considered it. If management decides not to segment an old line because it will be retired in two years, that written decision is worth more than an improvised technical measure.
• A rehearsed response plan: who gets called, how the plant is isolated from the corporate network, how to produce in degraded mode and who notifies the authority within the deadline. A two-hour tabletop exercise once a year uncovers more gaps than many reports.
• Simple indicators that reach management: percentage of assets inventoried, active versus authorised remote accesses, incidents and near misses in the period, plan progress.

The management training the directive requires does not aim to turn the board into technical experts. It aims to ensure they can ask the right questions: what would happen if the plant systems did not start tomorrow, how long would it take to produce again, which suppliers do we depend on to respond and who has access to what. A management team that knows how to ask those questions governs the risk; one that delegates the entire conversation to whichever vendor is at hand does not.

A reasonable roadmap

Complying with NIS2 on the shop floor is not a six-week project, nor does it require starting with a technology purchase. A sensible sequence for a mid-sized industrial company, following the order of this guide:

1. Determine the scope: verify against the national transposition whether the company is an essential entity, an important one or out of scope, and what customers already demand by contract.
2. Inventory the OT estate with passive methods and a physical walk-through, and classify the assets by criticality.
3. Assess the risk against that inventory and take the result to management so it can prioritise and approve.
4. Segment: the IT/OT boundary, an industrial DMZ and control of third-party remote access before any other investment.
5. Prepare the response: an incident plan with the notification deadlines built in, backups of PLC programs and SCADA projects verified with a real restoration, and an annual tabletop exercise.
6. Consolidate the governance: owner, risk register, indicators and periodic management review. That is what turns a one-off project into a system that survives the passage of time.

Our injection moulding plant, after that journey, is not invulnerable. But ransomware in the offices no longer stops production, the integrators come in through a guarded door, management knows which risks it has accepted and why, and when an incident occurs there is a plan instead of improvisation. That, and not a certificate on the wall, is what NIS2 ultimately asks for: that cyber risk be governed.

Frequently asked questions

If your company is assessing what NIS2 requires of it and what state its plant is in, a good starting point is an operational diagnosis that includes surveying the OT estate and its access paths. The Captia Consulting team works on this type of governance and risk programme together with the network architecture side developed in the zero trust OT pillar.