An OT-IDS that runs on the equipment you already have.

Industrial operators face new compliance pressure from NIS2, IEC 62443 and the Swiss ICT Minimal Standard. Most OT intrusion-detection products are built around a central appliance with traffic mirrored to it. That works for a single large site with a dedicated security team. The case we're working on is the other one: many small sites, thin links, no full-time SOC.

This Innosuisse-funded project, run with the FHNW, asks what an OT IDS looks like when the constraint is many small sites instead of one big one. Detection runs in a container on the switches, firewalls and gateways already on site. Baselines calibrate themselves. Only events that local analysis confirms as serious travel to a central system.

Where central appliances strain

Central appliances work when there is one site big enough to justify the cost and a steady link to feed them. When the network is spread out (district heating with many small sites, energy operators with substations on LTE, multi-site logistics), three things push back:

• Economics
  Per-site or per-appliance pricing doesn't scale linearly across hundreds of small sites. Most of the security value lands in the first one or two; the long tail is hard to justify.
• Bandwidth
  Continuous mirroring needs a steady link from every site back to the appliance. LTE backhaul and constrained heating-network connections don't reliably provide it.
• Operability
  Cross-site tuning to suppress false positives, then ongoing maintenance, is its own job. A distributed operator rarely staffs a full security team. Detection has to work without one.

Four design choices

Each one follows from the same starting point: many small sites instead of one big one.

Detection runs at the edge, in a container, on hardware that's already on site. Industrial switches, firewalls and gateways with a container runtime can host a small detection pipeline next to the forwarding plane. No second appliance to install per site, no SPAN port back to a datacentre.

Baselines calibrate themselves. Each site learns its own normal from its own traffic: the OT protocols, the device roles, the daily rhythm of the plant in front of it. Detection works without expert tuning, and re-tunes when the plant changes.

Only events leave the site. The edge keeps a rolling 30–60 second buffer; when something passes a local suspicion threshold it's saved (the record-on-suspicion step), and only if local analysis confirms a serious anomaly does a packaged piece of evidence travel to central. Bandwidth use tracks actual incidents rather than steady-state traffic: the budget thin OT links can reliably offer.

On-prem LLMs do alert context and natural-language interaction. Operators of sensitive OT environments often can't send traffic to a cloud model. The project evaluates which local models, at which size, handle useful alert triage and operator Q&A without anything leaving the site.

What the research has to answer

The four choices above are the design intent. The research determines whether each one is achievable in practice:

1. RQ-1
   Can self-calibration converge reliably on OT traffic? Industrial protocols are periodic and asset-stable in ways IT traffic is not, promising for unsupervised baselines, but unproven at the precision an IDS needs.
2. RQ-2
   Can existing edge hardware run meaningful detection without degrading the network it sits on? The container runtime on a substation switch is the easy part; running anomaly detection there under real packet rates without touching the forwarding plane is the open question.
3. RQ-3
   Can LLMs be deployed on-prem for alert contextualization? Which models, at which size, with what latency and accuracy, and whether the resulting footprint is one a typical OT site can host.