The attack on the Ukrainian power grid in December 2015 cut off electricity to 230,000 residents of three western oblasts. The attackers — the Sandworm group — used spear phishing to gain access to the corporate network, escalated privileges via Active Directory, accessed the operator’s dispatch network, and finally manually opened breakers at 30 substations from the HMI console. The attack was the first publicly documented, successful cyber attack on an element of an electrical power grid. It lasted 6 hours. After Ukraine, European regulators introduced defensive regulations for transmission system operators — and discovered that most plants at that time did not have isolated IT networks from control networks.
Ten years later we are in a different world. NIS2 has entered into force, the CER (Critical Entity Resilience) directive classifies critical infrastructure operators, national cybersecurity laws have been amended with hard penalties, IEC 62443 is becoming the certification benchmark for integrators and manufacturers, and CSIRTs report year-over-year three-digit growth in events involving critical infrastructure. Volt Typhoon, the group attacking American critical infrastructure in 2023–2024, demonstrated that today’s attackers no longer need Stuxnet — default passwords, unsegmented VLANs, and Active Directory shared between the office and the production floor are enough.
This article is a complete guide to IT/OT/ICS cybersecurity prepared for decision-makers in industry, the energy sector, water utilities, oil, gas, transport, healthcare, and public administration. We show the differences between the IT world and the OT world, the anatomy of an ICS/SCADA system, the IEC 62443 standards stack, NIS2 requirements, a six-step implementation roadmap, a competency map by role on the team, and concrete case studies. Every decision is grounded in references to recognized sources (NIST SP 800-82r3, MITRE ATT&CK for ICS, ENISA Threat Landscape, EY NIS2 reports), and every competency required in the roadmap is mapped to specific EITT training courses.
For those managing risk and compliance, this material is a starting point for a conversation with the board about the OT cybersecurity budget. For automation engineers entering the cyber world — a structured introduction. For CISOs looking at how to extend an existing IT SOC with an OT layer — an operational manual. Reading time: 25–35 minutes.
How does OT cybersecurity differ from IT cybersecurity
The most serious mistake of industrial cybersecurity deployments is the assumption that an IT team knows enough to secure a production floor. This mistake has already cost European industry several publicly known incidents in 2022–2024 whose details have not been disclosed, but which resulted in production line halts lasting 4–11 days. The IT world and the OT world have different physics, different lifecycles, different priorities, and different engineering cultures.
In IT the classical security triad is CIA — Confidentiality, Integrity, Availability. Confidentiality is paramount (financial data, personal data, intellectual property), then integrity, and only at the end availability. In OT the triad inverts to AIC — Availability, Integrity, Confidentiality. For a power plant operator, losing control of a turbine for 30 seconds is a drama, while a leak of a control schematic is a medium-severity incident. For a water utility operator, stopping a pump for 2 minutes means a pressure drop in the district, while the confidentiality of the chlorination recipe is secondary. This change of priorities changes every design decision — from network architecture to the choice of EDR.
The second fundamental difference is the system lifecycle. A server in the data center lives 3–5 years. A PLC in the production hall lives 15–25 years. A SCADA system deployed in 2010 is realistically meant to operate until 2030–2035. Manufacturers of OT components (Siemens, Allen-Bradley/Rockwell, Schneider Electric, ABB, Honeywell, Yokogawa, GE) design their systems with long-life assumptions — which means Windows XP still runs on HMI panels in European plants, Modicon Quantum controllers from 2003 control pipelines, and a controller firmware update requires planned downtime agreed with the plant director 6 months in advance.
The third difference is patching cadence. In IT security patches are installed on a monthly cycle (Patch Tuesday Microsoft, Oracle Critical Update, OpenSSL releases). In OT system patches are installed once a year, once every two years, or not at all. The reasons are hard: any change to the control system requires quality validation (FAT/SAT — Factory Acceptance Test, Site Acceptance Test), any firmware change can affect the control loop timing, and every controller reboot is a micro-halt of production. The industry standard is a patch window planned for annual maintenance or scheduled outages. Which means a vulnerability discovered in a controller in January may be applied in November — and that is in the optimistic scenario.
The fourth difference is determinism and real-time requirements. The control network must guarantee that a valve-open command reaches the actuator in less than 50 milliseconds. Adding any inspection firewall or IPS that introduces unpredictable jitter can disturb control regulation. That is why classic enterprise IPS rarely fits in Purdue Levels 0–2. By comparison, a 200 ms delay in an enterprise network for most IT applications is imperceptible.
The fifth difference is engineering culture. The IT engineer works with virtual, abstract, barely material infrastructure. The OT engineer works with a physical process — a turbine they feel through the floor, a reactor whose cooling cycle they understand, a pumping station whose measurements they read daily. When IT says “just reboot it” — OT asks how much that costs in tons of unproduced polypropylene. This cultural difference is a fundamental challenge of every OT cyber project and the reason why a unified IT+OT SOC requires simultaneous training for both teams, not just technology.
The comparison table below synthesizes ten dimensions distinguishing these two worlds:
| Dimension | IT | OT/ICS |
|---|---|---|
| Priority triad | CIA (Confidentiality > Integrity > Availability) | AIC (Availability > Integrity > Confidentiality) |
| Device lifecycle | 3–5 years | 15–25 years |
| Patching cadence | Monthly (Patch Tuesday) | Annually / every 2 years / never |
| OS support | Stable (Microsoft 5+5 years) | Often EOL (Windows XP, 2000, NT still in production) |
| Reaction to anomaly | Quarantine, isolate, reimage | Manual fail-safe, operator alert, NEVER auto-block |
| Downtime tolerance | Minutes–hours for most systems | Seconds for critical process |
| Networks | TCP/IP, HTTP/HTTPS, REST API | Modbus, DNP3, OPC UA, Profinet, EtherCAT, IEC 60870-5-104 |
| Real-time | Usually no | Often a deterministic requirement |
| Incident priorities | Data leak, ransomware | Loss of control, physical damage to equipment, safety |
| Regulations | GDPR, ISO 27001, sectoral | NIS2, IEC 62443, NERC CIP, ISO 26262 (automotive), TS50701 (rail) |
The implication of this difference is one specific operational conclusion: OT cybersecurity requires a separate team or at least separate playbooks within an existing CSIRT team. A classic IT SOC that automatically cuts off an infected endpoint from the network, in an OT environment can trigger a production line halt costing hundreds of thousands of euros. A classic IT incident response that prioritizes preserving evidence for forensic analysis, in OT must yield to the priority of restoring control of the physical process.
ICS/SCADA system architecture — what it consists of
Before securing an industrial system, you must understand what you are securing. The acronym ICS (Industrial Control System) is the umbrella term — it covers the entire family of systems controlling industrial processes. SCADA (Supervisory Control and Data Acquisition) is a specific subtype of ICS designed to supervise geographically distributed processes — typically for electrical power grids, gas pipelines, water networks. DCS (Distributed Control System) is the second main subtype of ICS, used in geographically concentrated facilities — refineries, power plants, chemical factories. The third important component is PLC (Programmable Logic Controller) — the brain of local automation. The fourth — SIS (Safety Instrumented System) — an independent functional safety system that enforces emergency shutdowns (e.g., an SIS in a refinery that closes a furnace before an explosion).
The hierarchy of these elements is best described by the Purdue Model, formally known as Purdue Enterprise Reference Architecture (PERA), developed in the 1990s at Purdue University and adopted as a foundational reference by ISA-95 and IEC 62443:
- Level 0 — physical process: valves, pumps, sensors, actuators, turbines. The world of matter, not informatics. Attacks on this level (Stuxnet, Industroyer) require specialist knowledge of the specific process.
- Level 1 — basic control: PLC, RTU (Remote Terminal Unit), DCS controllers. Here millisecond decisions are made — open valve, close valve, raise temperature, trigger alarm.
- Level 2 — process supervision: HMI (Human-Machine Interface), operator stations, local historians. Here the operator sees the process and sends manual corrective commands.
- Level 3 — manufacturing operations: MES (Manufacturing Execution System), central historians, OEE (Overall Equipment Effectiveness), production planning, integration with the office.
- Level 3.5 — industrial DMZ: buffer between the OT world and the IT world. The jump host lives here, traffic is audited here, and normalized here.
- Level 4 — enterprise: ERP, office, finance, HR, corporate network.
- Level 5 — internet / cloud: gateways to the internet, cloud integrations, external suppliers.
The Purdue Model in its classical form assumed strict segmentation — every communication between levels passes through controlled points (jump hosts, data diodes, dedicated industrial firewalls). In Industry 4.0 practice this assumption breaks — operators want to see Level 1 data in BI dashboards at Level 5, integrators connect remotely via VPN to Level 2 from the office, suppliers service controllers via an internet connection. This blurring of boundaries between levels is the single largest cybersecurity risk factor in modern OT.
The Purdue Model still fulfills a fundamental function: it structures risk analysis and segmentation planning. The zones-and-conduits map in IEC 62443 (discussed in the next section) is essentially an updated version of Purdue, allowing more flexible boundaries but still requiring clear separation of layers with different security levels.
The practical implication for an industrial operator looks like this. The first step of any OT cybersecurity audit is a Purdue map for the specific plant — who and what sits at which level, what protocols flow between levels, where the jump hosts are, where direct connections bypass the DMZ. In most plants this document does not exist — and that is the first real OT cybersecurity task to perform. Without a Purdue map, no investment in OT security technologies (Claroty, Nozomi Networks, Dragos, Microsoft Defender for IoT, Tenable.ot, Forescout) makes sense, because we do not know what to configure and where.
IEC 62443 — the OT cybersecurity standards stack
The ISA/IEC 62443 family of standards is currently the strongest international benchmark for cybersecurity of Industrial Automation and Control Systems (IACS). It originates from standardization work begun by the International Society of Automation (ISA) in 2000 as ANSI/ISA-99, taken over in 2010 by the International Electrotechnical Commission (IEC) and formalized into the complete IEC 62443 package. Contrary to a common myth, IEC 62443 is not one document but a family of more than a dozen standards organized into four tiers.
Tier -1 (General) — general concepts. The most important document: IEC 62443-1-1 (Terminology, concepts and models) — industry vocabulary, the AIC triad definition, definitions of SuC (System under Consideration), zones, conduits, defense in depth.
Tier -2 (Policies and Procedures) — organizational requirements for operators (asset owners). The key document: IEC 62443-2-1 (CSMS — Cybersecurity Management System) — the operator must have a documented cybersecurity management system, analogous to ISO 27001 but adapted to OT specifics. The second important one: IEC 62443-2-4 — requirements for service providers (integrator firms, external maintenance providers).
Tier -3 (System Requirements) — architectural requirements for systems. The most important document: IEC 62443-3-3 (System security requirements and security levels) — defines 7 groups of foundational requirements (FR): Identification and Authentication Control, Use Control, System Integrity, Data Confidentiality, Restricted Data Flow, Timely Response to Events, Resource Availability. Each FR has from a few to a dozen detailed system requirements (SR) mapped to 4 security levels (SL1–SL4). The second important document of the tier: IEC 62443-3-2 (security risk assessment) — formal risk analysis methodology.
Tier -4 (Component Requirements) — requirements for components. Two key documents: IEC 62443-4-1 (Secure product development lifecycle) — the process of developing secure products on the manufacturer side, and IEC 62443-4-2 (Technical security requirements for IACS components) — concrete technical requirements for controllers, HMIs, network components.
The most important operational concept introduced by IEC 62443 is the division of the system into zones and conduits. A zone is a logical or physical grouping of assets with shared security requirements — e.g., “Level 1 PLC zone of production line A”, “Level 2 operator stations zone”, “Level 3.5 industrial DMZ zone”. A conduit is a controlled communication channel between zones — physically an industrial firewall, a data diode, a dedicated VLAN. After classifying all assets into zones and all connections into conduits, the operator can deliberately design where SL1 is to be, where SL2, where SL3, and what technical controls each zone requires.
The mapping of security levels looks as follows:
| Security Level | Threat | Required controls | Typical application |
|---|---|---|---|
| SL1 | Casual / accidental violation (e.g., careless employee) | Basic authentication, role separation | Most office systems, some Level 3.5 layers |
| SL2 | Intentional attacker with low resources and simple tools | Multi-factor authentication, segmentation, monitoring | Most European OT systems today |
| SL3 | Organized attacker with moderate resources and specific OT knowledge | Full logging, anomaly detection, controller hardening, RBAC | Transmission networks, larger refineries |
| SL4 | State-level attacker with high resources and deep process knowledge | Defense in depth, maximum segmentation, continuous monitoring, redundancy, immutable logs | Critical defense and nuclear installations |
Practically no European operator needs SL4 — the costs are disproportionate. A realistic target for most critical operators in Europe is moving from today’s mixed SL1 to mature SL2 with selected SL3 zones over a 2–4 year horizon.
Citing ISA terminology: the operator defines SL-T (target) — what they want to achieve from a business perspective. The component manufacturer declares SL-C (capability) — what their controller/HMI/firewall is technically capable of delivering. An audit checks SL-A (achieved) — what was actually deployed in a given zone. The gap between SL-T and SL-A is the cybersecurity gap — clean, measurable, auditable.
The full ISA certification path (discussed later in the “Competency map” section) includes four certificates: Cybersecurity Fundamentals Specialist (IC32), Risk Assessment Specialist (IC33), Design Specialist (IC34), Maintenance Specialist (IC37). An operator who completes all four becomes an ISA/IEC 62443 Cybersecurity Expert.
NIS2, national cybersecurity laws, and the CER directive — what applies when
In the European regulatory ecosystem for OT cybersecurity, three main regimes apply (or are about to apply): the NIS2 Directive (EU level), national implementations through amended cybersecurity acts (national level — in Poland through the amended National Cybersecurity Act, in Germany through IT-SiG 2.0, in the Netherlands through Wbni, etc.), and the CER directive — Critical Entity Resilience (EU, focused on physical and hybrid resilience of critical infrastructure). Additionally there are sectoral regulations (ENTSO-E network code for energy, EBA regulations for finance) and international ones (NERC CIP for operators exchanging energy with the US/Canada — not binding in the EU but used as a benchmark).
NIS2 entered into force on 16 January 2023 with a transposition deadline for member states of 17 October 2024. The directive expands the scope of NIS1 from 2016 (which covered mainly operators of essential services) to 18 critical sectors in two categories: essential entities (energy, transport, banking, health, drinking water, wastewater, digital infrastructure, public administration, space sector) and important entities (postal and courier, waste, chemistry, food, manufacturing, digital providers, research). Size threshold: medium and large enterprises (headcount ≥50 and turnover ≥10 million EUR), with the possibility of lowering by the national regulator for critical sectors.
The technical and organizational requirements of NIS2 (Article 21 of the directive) cover ten groups: risk analysis policies, incident handling, business continuity and recovery, supply chain security, security of acquisition/development/maintenance of systems, effectiveness assessment policies, basic cyber hygiene practices and training, cryptographic policies, human resources security (access control, asset management), multi-factor authentication and secure communications. Penalties reach €10 million or 2% of global annual turnover (for essential entities) and €7 million or 1.4% of turnover (for important entities). Importantly — NIS2 introduces personal liability of management board members for failure to implement adequate measures, including the possibility of restricting the holding of their function.
Three-stage incident reporting is the second practical test of operator maturity: 24 hours for an early warning to the sectoral CSIRT, 72 hours for a notification report with impact assessment, 1 month for a final report with root-cause analysis and corrective actions taken.
National implementations: each member state transposes NIS2 into national law. Most member states experienced delays in 2024. Regardless of the exact date of national legislation entering into force, critical infrastructure operators should already be implementing the technical requirements of NIS2 — the ultimate deadline will not be moved, and the pace of technical deployments in energy/water utilities requires 12–24 months.
The CER (Critical Entity Resilience) Directive entered into force in parallel with NIS2 (16 January 2023, implementation deadline 17 October 2024). CER focuses not on cybersecurity but on physical, organizational, and hybrid resilience of critical entities — resilience to floods, droughts, physical sabotage, combined attacks (kinetic + cyber). For an energy/water utility operator, this means the need to run a NIS2 project (cyber layer) and a CER project (physical and organizational layer) in parallel, with coordination at the board level.
In the decision-making practice of a European essential operator this looks like: NIS2 + national cybersecurity laws define minimum legal requirements (compliance baseline), CER adds a layer of physical resilience, and IEC 62443 is a voluntary technical standard whose implementation satisfies most NIS2 requirements (Article 21 points d, g, i) plus a benchmark against which auditors will compare.
Competency map by role — who needs what
The fastest method of deploying OT cybersecurity in an organization is a clear assignment of competencies to roles. The classic question of management — “how many people do we need?” — is wrongly posed. The better question is — “which roles in our organization need which competencies?”. The competency map below answers this question for a typical essential operator (manufacturing plant, power plant, water utility, transport operator).
Board member responsible for cyber (CISO, CTO, CIO, COO). Competencies: regulatory awareness (NIS2, national cybersecurity laws, CER), knowledge of threat taxonomy (top 10 OT incidents of the last decade), ability to assess cyber risk in financial terms. Recommended training: a one-day executive briefing combining regulatory frameworks, strategic budget recommendations, and sector case studies.
Specialist CISO / Head of Information Security (in organizations >500 people — a dedicated role). Competencies: full knowledge of IEC 62443 (tiers -2, -3, -4), ability to build a CSMS, leading external audits, coordination with the sectoral CSIRT, managing a SOC covering IT and OT. Development path: Cybersecurity Fundamentals Specialist (IC32) → Risk Assessment Specialist (IC33) → postgraduate studies in OT cybersecurity + annual rotations at a production plant.
OT cybersecurity specialist (OT Security Engineer / Plant Security Engineer). The most often missing role in European plants. Competencies: full knowledge of the Purdue Model, IEC 62443-3-3 (FR/SR mapped to SL), practical tools (Claroty, Nozomi Networks, Dragos, Microsoft Defender for IoT, Tenable.ot, Forescout), OT protocols (Modbus, DNP3, OPC UA, Profinet, S7), ability to communicate with automation engineers. Path: general cyber fundamentals → ICS/SCADA Security Essentials → OT Network Security Architecture → Advanced OT Penetration Testing → optionally ISA IC32 + IC34 (Design Specialist) certification.
Automation engineer entering cyber. The most common development path in European industry 2025–2027. The automation engineer has deep knowledge of the process and control systems, and lacks cyber fundamentals. Development path: Industrial OT/ICS cybersecurity fundamentals (1–2 days, introduction) → ICS/SCADA Security Essentials (3 days, technical workshop) → optionally ISA IC32 (Fundamentals Specialist) certification. Path duration: 6–9 months with practice between modules. A hybrid “automation engineer with cyber awareness” emerges, often the most valuable profile for European plants.
IT engineer entering OT. The second most common path — a network administrator, security analyst, or SOC engineer is given the task of extending competencies into the OT layer. Development path: general OT fundamentals (IT vs OT differences, Purdue Model, protocols) → ICS/SCADA Security Essentials → OT Network Security Architecture: segmentation and monitoring → optionally OT pentest or embedded systems security. Duration: 4–6 months intensively.
Internal OT cybersecurity audit auditor. Often combines IT audit competencies (CISA, CISSP) with knowledge of IEC 62443. Path: Information Security Management System Auditor → Cybersecurity Fundamentals Specialist (IC32) → Risk Assessment Specialist (IC33) → optionally ISO 27001 Lead Implementer for joining with CSMS frameworks.
Production line worker, HMI operator, maintenance technician. The largest group, most often overlooked. Competencies: phishing awareness, password policy, awareness of why not to plug a private USB stick into an HMI, anomaly reporting procedure. Training: Cybersecurity for employees in the NIS2 and national cybersecurity law context — 2–3 hours, regularly repeated.
Systems integrator (external company). A key role, most often poorly secured. Requires: IEC 62443-2-4 certification (Service Providers), remote access management procedure, controlled intervention scheduling. The operator should require this certification in tenders — and that is the fastest mechanism enforcing the standard in the European integrator ecosystem.
The most common OT attacks and lessons learned
The OT threat map has changed dramatically in the last 15 years. From a few state-sponsored operations (Stuxnet 2010) to today’s reality of daily opportunistic attacks using ransomware. Below are the key incidents whose lessons must enter European defense plans.
Stuxnet (2010) — the first publicly known state attack on OT infrastructure. Target: the uranium enrichment installation at Natanz, Iran. Mechanism: a virus spread via USB infected Windows computers, searched for Siemens S7-300/S7-400 controllers, reprogrammed the logic of PLCs controlling uranium centrifuges, while spoofing normal readings to the monitoring system. Result: several hundred centrifuges destroyed by excessive RPM. Lesson: the attack surface includes not only the network, but also USB, supply chain, engineering environment. MITRE ATT&CK: T0863 (User Execution), T0859 (Valid Accounts), T0833 (Modify Parameter).
BlackEnergy / Sandworm — attack on Ukrainian power grid (December 2015). Target: three regional distribution companies (Prykarpattyaoblenergo, Kyivoblenergo, Chernivtsioblenergo). Mechanism: spear phishing → BlackEnergy 3 backdoor → privilege escalation via Active Directory → access to dispatch network → manual opening of breakers at 30 substations plus DDoS on the call center. Result: 230,000 residents without power for 1–6 hours. Lesson: lack of segmentation between corporate AD and dispatch network = no defense. MITRE ATT&CK: T0866 (Exploitation of Remote Services), T0814 (Denial of Service).
Industroyer / CRASHOVERRIDE (December 2016) — the second attack on the Ukrainian grid, this time automated. Target: Pivnichna substation near Kyiv. Mechanism: malware natively understanding the IEC 60870-5-101, IEC 60870-5-104, IEC 61850 protocols and OPC DA. Result: ~70 minutes of power outage in part of Kyiv. Lesson: the first documented malware specific to OT protocols — the future of threats. MITRE ATT&CK: T0855 (Unauthorized Command Message), T0832 (Manipulation of View).
TRITON / TRISIS (August 2017) — attack on a petrochemical refinery in Saudi Arabia. Target: Triconex Schneider Electric Safety Instrumented System. Mechanism: malware modifying the SIS controller code, attempt to disable the functional safety system. Result: SIS entered fail-safe, shutting down the refinery (attack failed but exposed). Lesson: the first attempt at an attack on the functional safety layer SIS — had the attacker succeeded, the refinery could have exploded. MITRE ATT&CK: T0858 (Modify Operating Mode), T0831 (Manipulation of Control).
Colonial Pipeline (May 2021) — DarkSide ransomware attack on the largest pipeline operator on the US East Coast. Target: not OT directly, but the billing system (IT). Mechanism: compromise of a VPN account with an older password, no MFA, ransomware. Result: the operator preventively shut down the pipeline, panic fuel buying, a 5-day paralysis of supplies on the US East Coast, a $4.4M ransom paid (most later recovered by the FBI). Lesson: lack of IT/OT segmentation can lead to voluntary production halt even if OT was not attacked. MITRE ATT&CK Enterprise: T1078 (Valid Accounts), T1486 (Data Encrypted for Impact).
Volt Typhoon (2023–2024) — Chinese state group attacking American critical infrastructure (energy, water, transport, telecom) with the likely goal of maintaining a position for actions during a geopolitical crisis. Mechanism: living-off-the-land (LOTL) — using built-in Windows and network tools, no typical malware, attacks on SOHO networking gear, long persistence without action. Lesson: today’s state attackers do not need Stuxnet — undermanaged accounts, default passwords, unpatched edge gear are enough. Detection requires behavioral analysis, not signature-based.
Synthesis for a European operator: most incidents start with an account with excessive privileges, an unsegmented network between the office and production hall, and a lack of monitoring of Purdue Levels 0–2. Investment in fundamentals (account hardening, segmentation, basic OT monitoring) yields radically more effect than investment in advanced detection technologies without those fundamentals.
The table below maps the main MITRE ATT&CK for ICS techniques to recommended controls:
| MITRE ATT&CK ICS | Technique | Recommended control |
|---|---|---|
| T0859 | Valid Accounts | MFA for every account accessing Levels 1–3, password rotation, AD hardening |
| T0883 | Internet Accessible Device | Exposure mapping (Shodan, Censys), elimination, data diode for necessary traffic |
| T0817 | Drive-by Compromise | Browser hardening on engineering stations, awareness, Office macro blocking |
| T0863 | User Execution | Application whitelisting, AppLocker, USB hardening |
| T0867 | Lateral Tool Transfer | EDR on IT stations, SMB/RDP monitoring, mandatory jump host to OT layers |
| T0855 | Unauthorized Command Message | OT protocol allowlists on firewalls, deep packet inspection, behavioral baselining |
| T0813 | Denial of Control | Fail-safe procedures, controller redundancy, independent functional safety system |
| T0858 | Modify Operating Mode | Command whitelisting, audit of controller configuration changes, digital signature of logic |
Implementation roadmap — 15 steps through the first 18 months
Deploying OT cybersecurity in a European manufacturing plant or in a critical infrastructure organization realistically takes 18–36 months. The roadmap below is an expansion of the 15-step Energetiko sequence (see sources), supplemented with mapping to IEC 62443 and specific EITT training courses at each step.
Step 1 — Baseline Assessment (months 1–2). Zero audit: what is our state today. A Purdue map for the specific plant, asset list (OT hardware, firmware, OS), network connectivity map, privileged account map, external access map (VPN, service signatures), external integrator map. Output: Current State Assessment document + gap matrix against NIS2 Article 21. Required competencies: OT Security Engineer, optionally external audit. IEC 62443 mapping: 2-1 (CSMS init), 3-2 (risk assessment).
Step 2 — Establishment of the Cyber OT Team and Steering Committee (months 1–2). CISO + Plant Security Engineer + IT representative + automation representative + board representative. The committee meets at least monthly. Required: executive briefing for the board on NIS2.
Step 3 — Risk Analysis per IEC 62443-3-2 (months 2–4). SuC (System under Consideration) identification, division into zones and conduits, classification of zones by SL-T (target). Output: Risk Assessment document with zone map + SL-T. IEC 62443 mapping: 3-2 (formal methodology). Training: Risk Assessment Specialist (IC33) or EITT equivalent — a key step for CISO and OT Security Engineer.
Step 4 — Policies, procedures, and CSMS (months 3–6). Cybersecurity Management System satisfying IEC 62443-2-1: OT cybersecurity policy, information classification policy, access management policy (RBAC), incident management policy, change management policy, privileged account management policy, backup and recovery policy, supply chain management policy. IEC 62443 mapping: 2-1.
Step 5 — Network segmentation (months 4–9). Implementation of controlled segmentation per the zones-and-conduits map. Industrial firewalls between Purdue layers (e.g., between Level 3 and Level 3.5/industrial DMZ, between Level 3.5 and Level 4 enterprise). Required: practical knowledge of OT-aware firewalls (Cisco Industrial, Fortinet OT Security, Palo Alto, Hirschmann, Phoenix Contact mGuard). Training: OT Network Security Architecture: segmentation and monitoring.
Step 6 — Account and identity hardening (months 4–6). Elimination of shared service accounts, MFA for all accesses to Levels 2–3, segregation of office AD from industrial AD (or dedicated tenant), password rotation policy, privileged account policy (PAM). The fastest ROI of OT cybersecurity — one of the three strongest protective controls.
Step 7 — OT monitoring (months 6–12). Deployment of OT-aware monitoring (Claroty, Nozomi Networks, Dragos, Microsoft Defender for IoT, Tenable.ot, Forescout). Phase A: passive monitoring (sniffing traffic in Levels 1–2), Phase B: active discovery, Phase C: integration with IT SIEM, Phase D: alarming and playbooks. IEC 62443 mapping: 3-3 FR6 (Timely Response to Events).
Step 8 — Incident Response Plan (IRP) for OT (months 6–9). Separate playbook from IT IRP. Procedure for reporting to the sectoral CSIRT within 24h/72h/1mc. Emergency contact list. Manual fail-safe procedure for every critical process. Annual schedule of tabletop and incident drill exercises. Training: for CSIRT + CISO team, plus annual joint IT+OT exercises.
Step 9 — Backup, recovery, business continuity (months 8–12). Backup of controller configurations, backup of operator station images, backup of historians. Recovery testing at least quarterly. Air-gapped/immutable backups for critical data. RTO/RPO agreed with the board for each process.
Step 10 — Supply chain security (months 9–15). Integrator audit (requirement of IEC 62443-2-4 certification for service providers in new contracts), manufacturer audit (requirement of IEC 62443-4-1 for newly acquired components), procedure for managing remote access of maintenance personnel (lifting/closing after session, logging). NIS2 mapping: Article 21 point d.
Step 11 — Training, awareness, and culture (from month 3). Annual cybersecurity training for production line employees, quarterly briefings for HMI operators, monthly CSIRT tabletop exercises. NIS2 mapping: Article 21 point g. EITT training: Cybersecurity for employees in the NIS2 and national cybersecurity law context.
Step 12 — External audit (months 12–18). The first external audit of compliance with NIS2 or IEC 62443-2-1. Selection of a certified auditor (e.g., TÜV, DEKRA, Bureau Veritas, BSI). Output: certificate or report with a corrective action plan (CAR). Required: 12-month operational history of CSMS.
Step 13 — Implementation of IT+OT SOC (months 12–24). Consolidation of monitoring and incident response into a single team, but with separate playbooks. Dedicated OT analyst on every shift 24/7 or on-call. SIEM integration covering Purdue Levels 0–5. NIS2 mapping: Article 21 point b.
Step 14 — Improvement and measurement (from month 18). Quarterly maturity assessment against NIST CSF or C2M2 (Cybersecurity Capability Maturity Model). Annual Risk Assessment update. Risk Treatment Plan update. Maturity report for the board.
Step 15 — Scope expansion (from month 24). After stabilizing the core scope (Purdue Levels 1–3) — expansion of monitoring to Level 0 (sensors, actuators), deployment of advanced anomaly detection, possibly deployment of SOAR for playbook automation, possibly deployment of deception technology (OT honeypots, e.g., Conpot).
European and global case studies
Energy — anonymous distribution operator in southern Europe (2022). After a phishing attempt in summer 2021, the operator commissioned a cybersecurity audit. The audit revealed: no segmentation between office AD and dispatch stations, 17 service accounts with static passwords dating back to 2014, an open RDP session from the internet to the historian station (incident waiting to happen). The operator deployed in 14 months: full segmentation, MFA for all accounts accessing Levels 2–3, Claroty as OT monitoring, joint IT+OT SOC. Cost: approximately €1 million. After deployment — zero Tier 1 incidents over 30 months of operation.
Water utilities — European water operator serving a city >300k residents (2023). Pre-NIS2 readiness assessment revealed: 11 water treatment stations accessible via service VPN with a 9-year-old default manufacturer password, no monitoring of controller configuration changes, no IRP procedure, external integrator with RDP access to the entire Level 3.5. 18-month implementation: closing internet exposure, MFA, dedicated jump host for integrator with session recording, integration with sectoral CSIRT, Nozomi Networks as monitoring. Cost: €650k. Pre-NIS2 status: ready.
European chemical industry — plastics factory with Siemens S7-1500 line (2024). Ransomware attack attempt on the office network in Q1 2024, stopped before escalation to the production floor thanks to segmentation deployed in 2023. The attack revealed, however, a weakness: the ARP table in the Level 2 HMI showed an attempted connection from Level 4 — segmentation worked, but monitoring was not yet deployed and the attack would have gone unnoticed without retrospective log analysis. Lesson: segmentation without monitoring is a half solution. The operator completed OT monitoring deployment in Q3 2024.
Global case — Mondelez NotPetya (2017). A global candy manufacturer attacked by NotPetya via the Ukrainian accounting software M.E.Doc. Two factories in Europe were affected. Global outcome: 1,700 servers and 24,000 workstations encrypted in one day. Mondelez global losses: $100M+. Lesson: the software supply chain is an attack vector often underestimated in European industry.
EITT training map — ready answers to competency needs
EITT offers in 2026 one of the broadest portfolios in Europe of training courses in OT/ICS cybersecurity, ICS/SCADA, NIS2, and embedded systems security. Below is a training map answering specific competency needs from the roadmap and the role map.
Industrial OT/ICS Cybersecurity Fundamentals — a 1–2-day introduction for automation engineers and IT engineers entering the topic. Covers: IT vs OT differences, Purdue Model, IEC 62443 basics, NIS2 basics, threat landscape, account hardening, basic segmentation.
ICS/SCADA Security Essentials — Industrial Systems Security — flagship 3-day workshop training. Covers: ICS/DCS/SCADA architecture, OT protocols (Modbus, DNP3, OPC UA), practical segmentation, hands-on attacks and defense on a PLC lab, basic OT monitoring, basic IR playbooks.
OT Network Security Architecture: Segmentation and Monitoring — advanced 3-day training for OT Security Engineer and Plant Security Engineer. Covers: advanced zones-and-conduits IEC 62443 segmentation, OT-aware firewalls (Cisco Industrial, Fortinet, Palo Alto), industrial VLANs, OT monitoring (Claroty/Nozomi/Dragos/Defender for IoT).
Advanced Pentesting Techniques in OT Environments — expert 4-day training for red team and security architecture teams. Covers: OT pentest methodology (with fail-safe considerations), attacks on OT protocols, HMI attacks, PLC attacks, post-exploitation in Purdue Levels 1–2, reporting and remediation guidance.
Embedded Systems Security — 3-day training for embedded systems developers and product security personnel. Covers: firmware hardening, secure updates (secure boot, signed updates), cryptography in resource-constrained environments, IEC 62443-4-1/4-2.
NIS2 Directive in Practice — Preparing Your Organization — 2-day training for CISOs, Compliance Officers, board members. Covers: full analysis of Article 21, essential/important entity classification, mapping of requirements to technical controls, incident reporting procedure, sanctions and personal board liability.
Cybersecurity for Employees in the NIS2 and National Cybersecurity Law Context — 0.5–1-day awareness training for operational employees (HMI operators, maintenance technicians, production staff). Covers: phishing, password policy, USB hygiene, anomaly reporting procedure, basic cyber hygiene.
Information Security Management System Auditor — 3-day training for internal auditors combining IT and OT. Covers: ISO 27001 + IEC 62443-2-1 audit methodology, conducting interviews with technical personnel, documenting non-conformities, corrective action plan.
Operators planning a fast development path for a CISO+OT Security Engineer team typically use a 4-module combination: OT/ICS Fundamentals → ICS/SCADA Security Essentials → OT Network Security Architecture → NIS2 in Practice. The total absorbs 11 training days over 6–9 months, generates a critical mass of internal competencies, and costs a fraction of the outsourcing alternative.
From guide to action
IT/OT/ICS cybersecurity in 2026 is no longer optional. NIS2 has entered into force, national cybersecurity laws are tightening, the CER directive imposes a layer of physical resilience, IEC 62443 is becoming the benchmark of every new integrator contract, and operators of states adjacent to regional conflicts find themselves in the attention web of state adversaries. Attempts to attack European critical infrastructure are no longer a question of “if” but “when” and “how often”.
This guide is the first step, not the last. The second step is a real baseline assessment for your organization — Purdue map, zones-and-conduits map, gap matrix against NIS2. The third — a Cyber OT Steering Committee with an 18-month budget. The fourth — internal competencies. Without internal competencies, no investment in tools translates into mature defense.
If you are starting this path — start with a one-day executive briefing for the board on NIS2, a two-day OT/ICS fundamentals course for the CISO+IT+automation team, and one concrete zero-audit. Three decisions, total cost below the budget of a single ransomware attack, total duration three months. That is a real start, not theoretical planning.
Training and compliance are the beginning. Operational readiness is the result of 12–24 months of consistent work. EITT has accompanied European critical operators on this road for a decade — from industrial cybersecurity fundamentals to advanced OT penetration testing courses and NIS2 compliance audits.
Frequently Asked Questions about IT/OT/ICS cybersecurity
How does OT cybersecurity differ from IT cybersecurity?
In IT the priority is the CIA triad (Confidentiality – Integrity – Availability). In OT the order reverses to AIC (Availability – Integrity – Confidentiality). Stopping a production line or losing control of a turbine costs minutes, hours, or human lives. As a result, OT patching is rare and planned (once every 3–12 months), the operating system lifecycle lasts 15–25 years, and controller downtime is not an option. An IT engineer and an OT specialist must understand this difference before they meet at the same SOC.
Is NIS2 already in force in the EU?
The NIS2 Directive entered into force in the EU in January 2023, with member states required to transpose it by 17 October 2024. Several member states (including Poland) experienced implementation delays. Regardless of national delays, essential entities (energy operators, water utilities, gas, transport, financial sector) should already be implementing the technical and organizational requirements derived from the directive, because penalties reach €10 million or 2% of global annual turnover.
What is the Purdue Model and does it still apply in 2026?
The Purdue Model (PERA — Purdue Enterprise Reference Architecture) is a hierarchical segmentation of the production system into 6 levels (from Level 0 — physical processes, through Levels 1–3 control and SCADA, to Level 3.5 DMZ, Level 4 enterprise, and Level 5 internet). In 2026, despite Industry 4.0 and the blurring of IT/OT boundaries, the Purdue Model remains the foundation of network segmentation and of mapping IEC 62443 zones/conduits controls. Clean separation of levels is no longer sufficient — but their existence still structures risk analysis, monitoring, and incident response.
What is IEC 62443 and is it mandatory?
ISA/IEC 62443 is a family of international standards for industrial automation and control systems (IACS) cybersecurity. It is divided into four main groups: -1 (general concepts), -2 (organization and CSMS — Cybersecurity Management System), -3 (architecture and system requirements), -4 (component requirements and development process). The standard itself is not legally binding — but in many countries (including Poland, Germany, the Netherlands) energy and safety regulators reference IEC 62443 as a recognized good practice satisfying the requirements of NIS2 and industry regulations.
What are Security Levels SL1–SL4 in IEC 62443?
Security Levels define the resistance of a system to attack — SL1 protects against accidental violations, SL2 against simple intentional attacks with low resources, SL3 against organized attacks with moderate resources, SL4 against state-level attacks with high resources. In project practice, the operator defines SL-T (target — what they want to achieve), the manufacturer declares SL-C (capability — what their component delivers), and an audit checks SL-A (achieved — what was actually implemented). Most of European industry currently operates between SL1 and SL2.
What is MITRE ATT&CK for ICS?
MITRE ATT&CK for ICS is a public knowledge base of tactics, techniques, and procedures (TTPs) used by adversaries attacking industrial systems. It contains concrete technique identifiers (e.g., T0859 Valid Accounts, T0883 Internet Accessible Device, T0813 Denial of Control) mapped to real threat actors (Sandworm, ALLANITE, XENOTIME, Volt Typhoon). For operators, it is an invaluable vocabulary for designing controls and detection — it allows mapping each defense layer to the specific TTP it should counter.
How do you report an OT incident under NIS2?
NIS2 introduces three-stage reporting to the sectoral CSIRT (in Poland: CSIRT GOV, CSIRT NASK, CSIRT MON depending on the entity): early warning within 24 hours of detection, notification report within 72 hours with impact assessment, final report within 1 month with full root-cause analysis and actions taken. For an essential operator, this means the necessity of having an IRP (Incident Response Plan) with clearly assigned roles, a trained team, and communication channels with the regulator before an incident occurs.
Does a small renewable energy plant also fall under NIS2?
It depends on scale and category — NIS2 introduces a size threshold (headcount ≥50 or turnover ≥10 million EUR) as a baseline condition, but in the energy sector the threshold can be lowered by a national regulator decision. Operators of renewable energy plants with installed capacity ≥10 MW and larger photovoltaic/wind installations typically fall under NIS2. Operators of smaller installations (micro-installations, prosumers) most often do not — but if they provide aggregator or balancing services, the classification can change.
What OT training is recommended for an automation engineer with no cybersecurity background?
A natural starting path is: (1) Industrial OT/ICS cybersecurity fundamentals — 1–2-day introduction covering Purdue, IT vs OT, basics of standards; (2) ICS/SCADA Security Essentials — 3-day practical workshop on architecture, segmentation, monitoring; (3) IEC 62443 Fundamentals — formal standard path; (4) optionally specialization: OT penetration testing, OT network architecture, automotive cybersecurity (ISO 26262 + ISO/SAE 21434). The full path takes 6–12 months with practice between modules.
How do you set up a unified SOC for IT and OT?
A unified IT+OT SOC is the target model for most European critical operators, but it requires separate playbooks, separate incident taxonomy (T-IDs MITRE ATT&CK ICS vs Enterprise), and the presence of OT analysts on every shift. In practice: one CSIRT/SOC team, two distinct IRP processes (IT vs OT), a shared SIEM with dedicated connectors to Purdue Levels 0–2, and regular joint-incident exercises at least quarterly. The most common mistake in industrial deployments: bringing IT playbooks 1:1 into OT — quarantining an endpoint in IT is a correction, in OT it is a potential production halt.
Sources and references:
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security — fundamental American OT standard, basis for many European practices
- MITRE ATT&CK for ICS — public knowledge base of TTPs of attackers targeting industrial systems
- ENISA Threat Landscape — annual EU threat analysis
- ISA/IEC 62443 Cybersecurity Certificate Program — formal 4-certificate path
- Dragos Year in Review — annual OT threat analysis from global intel
- SANS ICS Security Curriculum — benchmark roadmap