NIS2 Compliance for Manufacturing: Securing OT, Legacy Machines, and On-Premise Systems

The Network and Information Security Directive 2 (NIS2), which replaces the original NIS Directive, marks a significant step forward in how the European Union addresses cybersecurity across sectors including manufacturing. For CISOs, IT Directors, and Network Engineers, compliance is more than a checkmark — NIS2 mandates a robust, ongoing process that touches operational technology (OT), legacy equipment, and crucial on-premise infrastructure. This blog post critically examines practical implications for manufacturing environments, focusing on technical strategies rather than vendor narratives or shallow recommendations.

NIS2: Historical Context and Key Requirements

The original NIS Directive (2016) was Europe’s response to accelerating cyber-dependence. However, its effectiveness was uneven due to fragmented national implementations and sectoral gaps. That brings us to NIS2 (2023), which is considerably stricter: it broadens sector coverage, imposes minimum harmonized cybersecurity measures, and introduces personal liability for management. Notably, manufacturing entities — including automotive, electrical, and machinery sectors — are newly in scope under the “important entities” category.

• Risk Assessment & Policies: Manufacturers must adopt policies for risk analysis, information system security, and incident response, specifically tailored to OT/ICS settings.

• Vulnerability & Patch Management: Regularly identify, assess, and mitigate vulnerabilities, which presents unique challenges with legacy machinery.

• Incident Reporting: Expanded and stricter timelines — first alert within 24 hours, detailed report within 72 hours.

• Supply Chain Security: Demonstrable due diligence for IT and OT vendor solutions, both cloud-based and on-premises.

The Legacy Machine Dilemma: A Technical Reality Check

What Are Legacy Systems in Manufacturing?

Legacy systems typically refer to OT assets still crucial for production — PLCs, SCADA nodes, CNC machines, and HMIs — running software that predates today’s IT security paradigms. Many ICS/PLC devices still operate by serial protocols (Modbus, Profibus, proprietary RS232/RS485), run outdated firmware, and lack basic cryptographic support.

Key Technical Challenges

• Lack of Patchability:
  

  Many legacy PLCs and controllers are “firmware-stagnant” — i.e., discontinued vendor support and/or updates require a complete hardware swap.

• Prevalence of Insecure Protocols:
  

  Factory floors often rely on clear-text communications or protocols without authentication, e.g., old Modbus TCP or DNP3.

• No Built-in Security Controls:
  

  Devices rarely support native identity management, auditing, or encrypted telemetry.

Segmentation and Isolation: Not a Panacea, But Essential

The axiom “if it can’t be patched, segment it” remains true but incomplete. Robust network segmentation — via internal firewalls, VLANs, or unidirectional gateways (“data diodes”) — can reduce blast radius. Yet, improper or insufficient segmentation can create a false sense of security. Rigorous traffic whitelisting using L3/L4 firewalls, and where feasible, deep packet inspection, is recommended. Also, consider network access control lists (ACLs) and static routing to minimize accidental exposure.

Annotation:

Defense-in-depth in OT comes from the tradition of “concentric rings” — a concept seen in traditional IT (perimeter firewalls, DMZs), but complicated in manufacturing by non-IP protocols and the need for real-time process integrity.

On-Premise Systems: Visibility, Detection, and Policy Enforcement

The “Visibility First” Challenge

Most manufacturers rely on on-premises industrial LANs, frequently air-gapped, but “air gaps” are increasingly illusory — think: remote maintenance via dial-up modems, transient engineering laptops, or shadow IT. The primary failure: lack of asset and network visibility.

Steps Toward Baseline Visibility

1. Passive Asset Discovery: Use network taps or SPAN ports to catalog all networked assets without risking disruption. Passive asset discovery frameworks (e.g., Zeek, Wireshark-based tools, or specialized ICS monitoring solutions) remain foundational — but never, under any circumstances, run active port scans on an OT subnet unless you've tested it extensively in a sandbox. Some devices will freeze or crash.

2. Network Flow Analysis: Ingest NetFlow, sFlow, or equivalent telemetry for real-time understanding of talkers/listeners and “normal” traffic patterns to inform anomaly detection.

3. Centralized Log Collection: Where supported, centralize logs from both IT and OT gateways. Industrial protocols typically lack standard logging — so, supplement with environment monitoring and syslog from supporting computers/servers.

Policy, Access, and Change Control

• Jump Hosts/Bastion Servers: All OT remote access (even internal) should go through tightly monitored jump hosts with multi-factor authentication and session recording.

• Strict Change Management: Every change to automation (PLC ladder logic updates, SCADA configuration, firmware uploads) must be authorized via a change management system. This is an area where NIS2 will bite in post-incident regulatory reviews.

• Least Privilege Everywhere: RBAC even for temporary maintenance access, logging 'who did what, when, and why'.

IT/OT Collaboration: Mind the Gap

Why IT Tools and Mindsets Don’t Fit OT Neatly

The historical separation of IT and OT didn’t emerge by accident. Manufacturing engineers, focused on uptime and safety, often viewed cybersecurity as a source of downtime risk — and IT professionals, in turn, often failed to appreciate industrial process realities. But under NIS2, this gap must be bridged, not just for audits but to ensure practical, sustainable controls.

• Maintenance Windows: OT doesn’t enjoy regular, extended patch cycles — equipment might run for years between scheduled maintenance shutdowns. Solution: Design compensating controls such as increased monitoring or temporary segmentation during high-risk periods.

• Incident Response: Runbook templates that blend both IT (forensic image, triage) and OT (process halt, safety verification) are needed.

• Unified Communications Bridge: Regular, technical joint sessions between IT security and plant engineers, focused on process-specific threat modeling, are crucial.

Historical Note:

The “convergence” of IT and OT security — discussed in academia and industry since the late 2000s — really took off with high-profile incidents like Stuxnet and subsequent ransomware events (e.g., WannaCry, NotPetya) that traversed poorly segmented networks. Today, NIS2 codifies, in effect, what engineers should have been doing all along.

Toward Secure Connectivity: Lessons for NIS2 Implementation

Secure Remote Access (SRA)

Enabling secure vendor support or remote diagnostics remains non-negotiable, but traditional VPNs are seldom enough. NIS2 expects that all external and third-party access to critical OT assets is mediated, monitored, and can be forensically reconstructed.

• Zero Trust Principles: Apply strict authentication, authorization, and continuous session validation. For industrial environments, this may require protocol tunneling or virtual desktop infrastructure to keep raw OT traffic off WAN links.

• One-Time Access: Every “emergency” remote session should be granted just-in-time, with expiry, strong MFA, and monitored by plant staff. No “set and forget” credentials.

Legacy Integration and Protocol Mediation

• Protocol Breakers and Proxies: Where direct adaptation isn’t feasible, deploy protocol proxies or application-layer gateways. For example, a Modbus proxy enforcing whitelist rules, or integrating with a firewall that understands industrial payloads (see e.g., Palo Alto Networks, Claroty, or open-source equivalents).

• Data Diodes: Physical unidirectional gateways remain the gold standard for strictly one-way process telemetry transfer (e.g., for reporting to IT or cloud analytics).

Annotation:

Data diode technologies — experientially common in nuclear and energy sectors — are making their way into general manufacturing, though cost and complexity often limit deployment to the most critical zones.

Recommendations and Hard Truths

• You cannot reliably patch most legacy OT. Compensate via segmentation, strict access control, real-time monitoring, and documented, tested incident response playbooks.

• Asset inventory is the perpetual weak point. Without real-time inventory — down to device type, firmware, and interface — compliance and security are impossible.

• Prepare for regulatory scrutiny. NIS2 penalties are real: management can be held personally liable. Document every exception, every risk acceptance, and every network diagram with dates and rationales.

• Engage your engineers, not just your “IT guys”. Only multidisciplinary teams can establish controls that are both effective and operationally realistic.

Conclusion

NIS2 compliance is less about “solutions” and more about rigorous, methodical attention to detail. It requires embedding secure network architecture, layered controls, and robust process documentation — particularly for legacy and OT environments. The honest reality is that compliance will stress existing budgets and patience; but the technical steps — passive discovery, real segmentation, session mediation, and active cross-discipline teamwork — are as much about good engineering as they are about satisfying audits.

Further Reading

• ENISA — Guidance for NIS2

• NIST SP 800-82 — Guide to Industrial Control Systems (ICS) Security

• ISA/IEC 62443 Standard

Questions or war stories? Feedback from factory floors and ops rooms always welcome in the comment section below.