IEC 62443 SL-2 controls and NIS2 obligations in 3 seconds.

IT and OT cybersecurity share some principles but diverge fundamentally in priorities, constraints and threat models. In IT, the CIA triad (Confidentiality, Integrity, Availability) is typically applied in that order. In OT, availability and safety come first — a SCADA system that goes offline can halt production or create a physical safety hazard. Key differences: (1) Patching: IT systems can be patched regularly with brief downtime; OT systems may run for months or years without maintenance windows, and vendor approval is required before patching. (2) Legacy systems: OT environments frequently contain equipment from the 1990s and 2000s running unsupported operating systems (Windows XP, Windows CE) that cannot be patched. (3) Protocols: OT uses industrial protocols (Modbus, DNP3, Profibus, OPC-UA) not designed with security in mind. (4) Air gaps: historically OT was isolated; IT-OT convergence has eliminated most air gaps, dramatically expanding the attack surface. (5) Impact of attacks: an OT cyberattack can cause physical damage, environmental incidents, safety hazards and production losses measured in millions per day.

IEC 62443 defines four Security Levels that describe the capability of a threat actor and the corresponding countermeasures required: SL-1 (protection against unintentional or accidental violations — human error, casual browsing); SL-2 (protection against intentional violation using simple means with low resources — script kiddies, opportunistic attackers); SL-3 (protection against intentional violation using sophisticated means with moderate resources — organised criminal groups, nation-state-adjacent); SL-4 (protection against state-sponsored actors with extensive resources targeting critical infrastructure). Most industrial operators must achieve SL-2 as the baseline, with critical infrastructure operators targeting SL-2 or SL-3 depending on the zone. IEC 62443-3-3 maps the seven Foundational Requirements (FR1-FR7) to specific System Requirements (SR) for each Security Level, providing the actionable technical controls for each SL.

NIS2 Directive (EU 2022/2555) expanded its scope significantly compared to NIS1, bringing manufacturing companies with revenue over €10M or 50+ employees in certain sub-sectors into scope as “important entities” (and some as “essential entities”). Key obligations for manufacturers: (1) Cybersecurity risk management measures (art. 21): policies on risk analysis, incident handling, business continuity, supply chain security, network security, vulnerability management, cryptography and multi-factor authentication; (2) Incident reporting (art. 23): 24h early warning, 72h full notification, monthly updates for significant incidents; (3) Management body accountability (art. 20): management must approve security measures and can be held personally liable for non-compliance; (4) Fines (art. 34): up to €7M or 1.4% of annual global turnover for important entities, up to €10M or 2% for essential entities. NIS2 was required to be transposed into national law by October 2024.

MITRE ATT&CK for ICS is a knowledge base of adversary tactics, techniques and procedures (TTPs) specifically observed in attacks on Industrial Control Systems. It covers 12 tactics: Initial Access (spear phishing, exploiting internet-facing systems, supply chain compromise), Execution, Persistence (modifying PLC programs, implanting backdoors in firmware), Privilege Escalation, Evasion (masquerading as legitimate OT traffic), Discovery (scanning for OT assets), Lateral Movement (moving from IT to OT network), Collection (historian data theft), Command and Control, Inhibit Response Function (disabling safety systems — the most dangerous ICS tactic), Impair Process Control (modifying setpoints, falsifying sensor readings) and Impact (denial of control, damage to equipment, loss of safety). In practice, OT security teams use ATT&CK for ICS for: threat modelling (which techniques are most likely given our environment?), detection engineering (what logs and alerts would detect technique X?), incident response (what other techniques should we look for after detecting technique Y?), and red team exercises.

The Purdue Model (also called the Purdue Reference Model for CIM — Computer Integrated Manufacturing) defines a hierarchical architecture for industrial control systems: Level 0 (field devices: sensors, actuators, motors), Level 1 (basic control: PLCs, RTUs, DCS), Level 2 (supervisory control: SCADA, HMIs, engineering workstations), Level 3 (site operations: site-level SCADA, historian, batch management), Level 4 (site business: ERP, MES, site IT), Level 5 (enterprise: corporate IT, cloud). Security best practice derived from the Purdue Model requires strict control of traffic flows between levels — particularly between Level 3 and Level 4 (the IT-OT boundary, where a DMZ is mandatory) and no direct connectivity between Level 0-2 and Level 4-5. IEC 62443 formalises this as “zones and conduits”: security zones are groups of assets with similar security requirements, and conduits are the controlled communication paths between zones. NIS2 art. 21(2)(e) mandates network segmentation as a required risk management measure.

An OT incident response plan must address several aspects that differ from IT incident response: (1) Detection: OT monitoring tools (passive network monitoring to avoid disrupting control traffic), anomaly detection on industrial protocols (Modbus, DNP3, OPC-UA), integration with safety system alarms; (2) Triage and classification: criteria for declaring an OT incident significant under NIS2 art. 23, decision tree for OT-IT isolation (when to disconnect the OT network from IT to prevent lateral movement); (3) Evidence collection: how to capture OT forensic evidence (PLC logs, historian data, network captures) without disrupting production — a fundamental difference from IT forensics where systems can be taken offline; (4) Containment: isolating affected PLCs or network segments while maintaining production safety (safety systems must remain operational); (5) NIS2 notification: 24h early warning content, 72h full notification structure, ongoing updates; (6) Recovery: restoring from OT-specific backups, verifying PLC program integrity, testing before reconnection; (7) Post-incident: root cause analysis, ATT&CK for ICS technique mapping, lessons learned and control improvements.