OT/ICS & IoT network security monitoring

Factories, utilities and hospitals run controllers that cannot be patched quickly, cannot be scanned actively and were never designed for hostile networks. Passive sensors that decode industrial protocols build an asset inventory, learn what "normal" communication looks like and flag malicious commands, new devices and process-relevant changes without touching the production network. Typical benefit: visibility where there was none, and an auditable basis for NIS2 and IEC 62443 compliance.

Problem & value

• Today: many plants have only spreadsheet asset lists, flat or poorly segmented networks, and IT security tools that either do not understand OT protocols or disrupt fragile devices when they actively scan. OT patch cycles are tied to maintenance windows measured in months or years.
• AI value: automatic asset discovery from traffic, behavioural baselining of who talks to which PLC with which function code, detection of unusual write/stop/firmware commands, and vulnerability prioritisation by exploitability and network exposure rather than CVSS alone.
• Regulatory pull: NIS2 extends security and reporting duties to energy, water, transport, manufacturing and health operators; IEC 62443 is the de-facto technical standard; the Cyber Resilience Act (CRA) pushes manufacturers of connected products to ship secure, updatable components [1][2][3].
• Threat context: the MITRE ATT&CK for ICS matrix documents real-world ICS techniques, and public advisories from CISA and national agencies (BSI in Germany) show recurring exposure of internet-facing controllers [4][5].

Variants

• Discrete manufacturing: PROFINET/S7/EtherNet/IP cells, remote vendor maintenance access, engineering-station monitoring.
• Energy and utilities: IEC 104, DNP3, IEC 61850 substations, distributed energy resources and smart-grid edge devices.
• Water, transport, building automation: Modbus, BACnet, rail and airport systems.
• Healthcare / IoMT: medical device and building-IoT discovery and segmentation (clinical safety first).
• SMB with IoT only: managed service or firewall-integrated OT visibility instead of a dedicated platform.

How it works

1. SPAN/TAP at OT switches (passive, one-way)
2. protocol dissectors (Modbus, S7, PROFINET, IEC 104, OPC UA, DNP3 ...)
3. asset fingerprinting (vendor, model, firmware, role)
4. live inventory
5. baseline learning (communication graph, function codes, polling cycles, value ranges)
6. detection: rules/signatures (known ICS malware, CVE exploits) + anomaly models (new flow, new write command, protocol deviation)
7. enrichment with vulnerabilities and exposure
8. risk score
9. alert triage (LLM-assisted summary)
10. SIEM/SOAR/firewall
11. OT security team

• Sensors run at the site (often industrial-hardened appliances, HW1-class) and send metadata, not raw traffic, to a central console; air-gapped sites use local consoles.
• AI components: unsupervised and graph-based baselining of communication patterns, sequence models on command/function-code behaviour, classifiers for device fingerprinting, and since 2025 LLM assistants for alert explanation and query in natural language. Process-value anomalies (temperatures, pressures) are a separate discipline, see ANOM-005.
• Human-in-the-loop: OT engineers confirm whether a flagged write is a legitimate maintenance action; containment (blocking, isolating a cell) is never automatic on safety-relevant assets without the plant owner's approval.

Data preparation

The raw material is network traffic: SPAN/mirror-port or TAP copies from OT switches, plus asset lists from engineering (PLC and HMI lists, network plans, firmware versions) and patch or vulnerability data from vendors. In an SMB manufacturer these are scattered over the automation supplier's documentation, an Excel list at the maintenance team, and the heads of a few experts.

Typical gaps: outdated or missing network diagrams, no asset inventory, unmanaged switches that cannot mirror traffic, flat networks mixing IT and OT, unknown owners per cell, and no baseline of "normal" operation.

Preparation steps: 1. Consolidate an asset list from plant documentation into a table (PREP-011) and name data owners (PREP-004). 2. Plan sensor placement with the automation supplier, and clear change windows. 3. Collect two to four weeks of baseline traffic before switching on alerts. 4. Label known maintenance and engineering activity so it is not flagged (PREP-020). 5. Export vulnerability and asset data from vendor systems (PREP-005).

Tools: managed switches or TAPs, a sensor appliance, Zeek, Excel or CMDB. Rough share of effort: 30-40 percent, mostly inventory and network access; see GUIDE-003.

Implementation paths

Which path for whom

• Enterprise: Path A — mature OT-monitoring products (passive sensors, protocol parsers for Modbus, S7, OPC UA, IEC 104) are tested with plant vendors, and writing and maintaining protocol decoders yourself is not worthwhile for a core production environment.
• Public sector (utilities, municipal plants): Path A — choose a product with on-premises sensors and analysis, KRITIS/NIS2-ready reporting and German or EU support; OT traffic must not leave the site.
• Developer: Path C — Zeek with ICS parsers, Malcolm or Security Onion plus open-source anomaly detection let integrators and researchers build and adapt monitoring on a small server.

Path A — Buy (off-the-shelf)

• OT/ICS platforms: Nozomi Networks (Guardian sensors, Vantage), Claroty (xDome, CTD), Dragos Platform (threat-intelligence-led, with OT Watch service), Rhebo (DE, EU), Armis (agentless asset intelligence incl. IoT), Forescout, Microsoft Defender for IoT, Fortinet and Palo Alto OT modules; Siemens SINEC Security Guard and Industrial Edge apps for Siemens estates.
• EU / regional: Rhebo (Germany); also check managed OT SOC services from European integrators and national CERT partnerships.
• Check: protocol coverage for your controller brands, passive-only operation, on-prem console option, SIEM and firewall connectors, IEC 62443 reporting, data location and sovereignty of the cloud console.
• Choose A when: you operate critical or essential entities, lack OT security staff, or need audit-grade evidence quickly.

Path B — Build on cloud APIs

• Rarely a full replacement. Use cloud LLMs (EU-region Azure OpenAI, Mistral, Claude, Gemini) to summarise alerts from the platform's API, map findings to IEC 62443 / ATT&CK for ICS, and draft incident reports under NIS2 early-warning timelines. Never send raw OT traffic or process data to external APIs without an explicit data-classification decision.
• Integrate via SIEM (Microsoft Sentinel, Splunk, Elastic) and SOAR; see SEC-001.

Path C — Self-host (open source)

• Sensors and parsers: Zeek with ICS protocol analyzers, Suricata with ICS rule sets, CISA's Malcolm (packet capture and analysis suite) and CISA's open ICSNPP parsers [6]; Arkime for full-packet search.
• Asset and vuln data: NetBox, OpenVAS/Greenbone (only on test beds, not production PLCs), CISA KEV and ICS advisories.
• Analytics: OpenSearch or Elastic, Grafana, scikit-learn / PyOD / graph libraries for baselining; small open-weight LLMs (Llama, Qwen, Mistral Small via Ollama or vLLM) for alert summarisation on HW1/HW2 hardware.
• Effort: significant; you maintain parsers, rules and tuning. Good for research, labs, small sites and teaching.

Path D — Custom training

Worthwhile only for vendors, large operators with unusual proprietary protocols, or research. Needs weeks to months of clean baseline captures per site plus labelled attack simulations from test beds (not live plants). Public datasets such as those from ICS test-beds exist but transfer poorly between sites.

State of the art (2026)

• Passive DPI plus behavioural baselining is the mature core; leaders combine it with curated threat intelligence (known ICS malware families, adversary groups) and exposure-based vulnerability prioritisation.
• Convergence of IT, OT and IoT visibility (single asset inventory, unified exposure management) is the main vendor trend; so is the integration of OT alerts into IT SOC workflows and generative-AI analyst assistants.
• Zero-trust segmentation for OT: policy suggestions derived from observed flows feed firewall rules (IEC 62443 zones and conduits).
• Limits: encrypted protocols (OPC UA with security, TLS) reduce inspection depth; learning-mode baselines can embed an existing compromise; false positives rise after process changes; coverage of proprietary or legacy protocols is uneven; attack detection on process-physics level is still immature. Anomaly alerts without process context overwhelm small teams.

Shared resources & combinations

• Shares streaming and anomaly-detection capabilities with SEC-006 (IT network IDS) and SEC-005 (behavioural anomalies); alerts flow into SEC-001 (SOC triage).
• SEC-004 (vulnerability management), SEC-008 (threat intelligence) and SEC-009 (NIS2/ISO compliance automation) consume its inventory and findings.
• ANOM-005 and PRED-006 watch the physical process; combined with network detection they separate cyber incidents from equipment faults.
• SEC-012 (threat modelling) uses the discovered topology for zone-and-conduit design.

Effort, cost & KPIs

• Path A: 2-6 months for a first multi-site rollout (sensor placement, SPAN configuration, baselining, tuning); cost is typically per sensor/site plus subscription; request quotes, pricing is not public.
• Path C: 3-9 months of engineering for a comparable result; low licence cost, high staff cost.
• KPIs: share of OT assets inventoried versus ground truth, mean time to detect and acknowledge, false-positive rate per site per week, share of critical vulnerabilities with compensating controls, segmentation coverage (zones and conduits defined), incident-report readiness against NIS2 deadlines.

People & change

Plant operations and IT security often work in separate worlds, so bring both in from the start. Management funds and owns the risk; the department lead (plant or production manager) agrees sensor placement and change windows; IT and IT security run the monitoring; data owners and external suppliers (automation vendors, integrators) provide asset data and approve any connection to their systems; legal checks NIS2 and KRITIS duties.

Works council: depends. Traffic analysis is mostly machine-to-machine, but if operator logins, engineering-workstation commands or shift activity can be attributed to named persons, the system is objectively suited to monitor behaviour and §87(1) no. 6 BetrVG applies. Inform the works council early anyway (§90(1) no. 3) and agree that alerts target devices and anomalies, not individual performance (GUIDE-004). Public bodies involve the staff council. If personal data are visible (user names), involve the DPO and check a DPIA (GUIDE-005).

Start with a passive pilot in one production cell, alert-only, no automatic blocking, because false positives can disturb production (GUIDE-009). Typical concerns: "will it disturb the process" (passive means no active scanning) and "who is watched". Support AI literacy for operators and security staff (Art. 4 AI Act, GUIDE-006, GUIDE-008). Humans decide on any response in the plant.

Risks, regulation & compliance

• EU AI Act: the monitoring system itself is typically minimal risk. If the AI is a safety component in the management and operation of critical infrastructure (Annex III point 2), obligations could apply; a pure cyber-detection tool normally is not, but assess case by case. No Art. 5 practice is involved unless the data is used to monitor individual employees, which must be avoided [7].
• NIS2 / KRITIS: essential and important entities need risk management, incident reporting (early warning within 24 hours) and supply-chain security; management bodies carry liability [1]. The CRA adds vulnerability-handling duties for product makers [3].
• IEC 62443: zones and conduits, security levels, secure development; map monitoring evidence to 62443-2-1 and 3-3 requirements [2].
• GDPR: traffic metadata can contain operator IDs, user names, badge or maintenance-access logs and IP addresses; involve the works council, minimise and pseudonymise, define retention.
• Risks and mitigations: sensor misconfiguration disrupting production (use passive TAPs, test in staging), cloud console exposing plant topology (prefer on-prem or EU-hosted), alert fatigue (staged tuning), baseline poisoning (validate learning phase), vendor lock-in (open export formats, SIEM integration).

Getting started

1. Define crown-jewel processes and plant owner responsibilities with OT engineering, not only IT.
2. Confirm switch capabilities (SPAN/TAP points) and map the network; follow NIST SP 800-82 guidance for the architecture [5].
3. Run a time-boxed passive discovery pilot at one site (4-8 weeks) with two vendors or with Malcolm/Zeek as a baseline.
4. Review the inventory and findings with plant staff; define response playbooks and escalation to the OT owner.
5. Connect to SIEM, plan segmentation using observed flows, and align reporting with NIS2 duties.

Sources

1. Directive (EU) 2022/2555 (NIS2) - https://eur-lex.europa.eu/eli/dir/2022/2555/oj
2. ISA/IEC 62443 series overview - https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
3. Regulation (EU) 2024/2847 (Cyber Resilience Act) - https://eur-lex.europa.eu/eli/reg/2024/2847/oj
4. MITRE ATT&CK for ICS - https://attack.mitre.org/matrices/ics/
5. NIST SP 800-82 Rev. 3, Guide to Operational Technology Security - https://csrc.nist.gov/pubs/sp/800/82/r3/final
6. CISA Malcolm and ICSNPP (Idaho National Laboratory / CISA) - https://github.com/cisagov/Malcolm
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Nozomi Networks platform documentation - https://www.nozominetworks.com/
9. Dragos platform - https://www.dragos.com/
10. Rhebo Industrial Protector - https://rhebo.com/en/
11. BSI - Industrial control systems security - https://www.bsi.bund.de/EN/