Why network security monitoring for manufacturing starts with the plant floor
For a manufacturing security lead whose PLCs, HMIs and historians cannot run endpoint agents, the practical route is passive network monitoring at the IT/OT boundary and inside OT zones. Sensors built on Suricata for signature-based detection, Zeek for protocol-aware metadata and Security Onion to bundle, manage and search both are a credible open source stack for this job. The sector matters here: NIS2 Annex II lists manufacturing as a critical sector, covering computer, electronic and optical products, electrical equipment, machinery and motor vehicles, so in-scope entities should expect incident reporting duties with early warning within 24 hours and a final report within one month. Monitoring that cannot show what happened on the network is hard to defend under those timelines.
The platform choice matters less than three decisions made before any software is installed. The first is sensor placement: which switches, firewalls or conduits carry the traffic you need to see, and whether a SPAN port or network tap can capture it without adding load to controllers. The second is production safety: a sensor must never sit inline on a control path, and capture settings must be tested against real cycle times so that a busy engineering workstation does not become a bottleneck. The third is protocol scope: confirm with your control engineers which industrial protocols are in use, because Zeek and Suricata visibility varies by protocol and by how much parsing you enable. Ask your vendor or integrator to document each decision in writing.
Security Onion is worth evaluating because its Distributed deployment separates manager, sensor and search roles, which fits plants where sensors sit in segmented zones and the analysis tier stays in a controlled data center. Its Elastic License 2.0 is source-available rather than OSI-approved, so legal review belongs in the selection process alongside the technical design. Confirm hardware for each sensor site against the published minimums, confirm whether your plant networks need air-gapped updates, and confirm what the OT engineering team will accept for changes near production equipment before you commit to a rollout plan.
Which requirements shape the manufacturing monitoring build
This table maps each requirement family that applies to plant and OT monitoring to the concrete build decision it forces, such as sensor zones, retention and alert routing. Read it as a checklist: start with the requirement that applies to your organization, then confirm the design decision with your OT engineers and your assessor before buying hardware.
| Requirement | What it asks for in plain terms | Build decision it shapes |
|---|---|---|
| ISA/IEC 62443 asset owner program (ANSI/ISA-62443-2-1-2024) | A documented security program for the industrial control systems you own, covering roles, procedures and ongoing review | Monitoring becomes a named program control with owners, review cadence and documented exceptions for each plant zone |
| ISA/IEC 62443 risk assessment (ANSI/ISA-62443-3-2-2020) | Divide the plant into zones and conduits and rank the risk of each based on consequence and exposure | Define sensor zones along zone boundaries, with the IT-to-OT conduit as the first tap or span point and higher-consequence zones monitored first |
| ISA/IEC 62443 system requirements (ISA-62443-3-3-2013) | Set target security levels for each zone and show the system supports the controls needed to reach them, including monitoring of security events | Choose which zones get network visibility and what evidence each zone must produce, which drives sensor count and log retention |
| NIST SP 800-82 Rev. 3 (OT security guide) | Guidance for ICS, SCADA, DCS and PLCs that puts performance, reliability and safety ahead of conventional IT assumptions | Passive sensing only, no active scanning of controllers, and a written test plan that proves the sensor cannot disturb control traffic |
| NIS2 Annex II (manufacturing sector) | Manufacturing divisions such as electronics, electrical equipment, machinery and motor vehicles are listed as critical sectors for in-scope entities | Confirm whether your entity is in scope, since this determines whether the reporting clock below applies to your monitoring alerts |
| NIS2 incident reporting (Article 23(4)) | Early warning within 24 hours, incident notification within 72 hours and a final report within one month for significant incidents | Alert routing must reach the decision maker fast enough to meet the 24-hour early warning, so define severity triggers and an after-hours path for plant alerts |
| Cyber Resilience Act reporting (Regulation (EU) 2024/2847, Article 14) | Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents, with Article 14 obligations applying from 11 September 2026 | If you build or modify products, retain network evidence that helps identify exploitation of your own product firmware and link alerts to the product security team |
| Machinery Regulation protection requirement (Regulation (EU) 2023/1230, Annex III 1.1.9) | Machinery must be protected so that connecting another or remote device does not create a hazardous situation, applying from 14 January 2027 | Passive sensors must not add a connection path into machine control, so specify read-only taps, one-way data diodes where the design calls for them, and documented change control for any new network device |
| Retention and evidence | Monitoring records must be kept long enough to show what was seen and what was done, with the period set by your framework and your counsel | Size storage for metadata and alerts at minimum, and confirm with counsel whether full packet capture is needed and how long it must be held |
Where to place taps and span ports between IT and OT zones
The boundary between the business network and the industrial zone is usually the best first place for a sensor, because most traffic that crosses it is visible there: remote access, historian replication, patch distribution and directory lookups. A network tap on the firewall-adjacent link gives a complete, unaltered copy of every frame, which matters because a SPAN port on a busy core switch can drop frames silently when it is oversubscribed. A SPAN port is cheaper and quicker to set up, but it is only as reliable as the switch CPU and buffers behind it, and it is a configuration change on equipment the plant may not own.
- Tap preference: Use a passive tap on the link that carries all traffic between the zones, so the sensor sees the same frames the firewall sees.
- Span overload at peak: Shift changes, batch jobs and historian backfills can push a mirror past its capacity. Ask the partner how packet loss is measured during these windows.
- Asymmetric traffic: If return traffic takes a different path through a second firewall or DMZ, a single tap sees only half of each session. Map the routing before choosing the tap location.
- Dual NICs: A Security Onion sensor needs x86-64 hardware and 2 NICs, per the supplied hardware requirements, so one interface can be the monitored link and the other the management path.
- Change control: Confirm the cable path and any switch configuration with plant engineering and the OT change board before touching the link.
Before any work, ask plant engineering which links carry safety or control traffic and which maintenance windows are approved.
Inside a production cell, traffic is dominated by controller-to-HMI, PLC-to-drive and vendor engineering sessions. Volumes are often modest, but the devices are fragile and the switches may be unmanaged or in a control panel with little room. A SPAN port on a cell switch is frequently the only practical option, and it must be treated as a change to a control system. Taps inserted inline in a control loop introduce a point of failure, so inline devices must be rated for industrial use and approved as part of the cell's design.
- Placement by conversation: Monitor the switch that carries the controller and HMI traffic, not every drop in the cell, to limit the number of changes to live equipment.
- Span configuration risk: A mirror session that copies many ports to one destination can increase switch CPU load. Limit the source ports and document the session.
- Protocol visibility: Zeek and Suricata see industrial protocols only when the traffic is mirrored or tapped at the right point, so confirm which controllers talk across which switch.
- Fail-open behavior: Ask the vendor how a passive tap behaves if its power is lost, and make sure the control path is not affected.
- Hardware space: Sensor hardware needs power, cooling and a mounting location that the plant accepts, which may differ from the office rack.
Ask plant engineering to identify the controllers and their maintenance paths, and to approve each mirror session and cable change in writing before the monitoring design is finalized.
Plants that run satellite sites, warehouses or remote packaging lines often have smaller networks, slower WAN links and less on-site IT support. Sensor placement at these sites usually focuses on the uplink to headquarters, the remote firewall and any vendor access path. Backhauling full packet capture across a WAN is rarely practical, so the design usually keeps capture and analysis local and sends alerts and metadata back to the central monitoring team. The volume of traffic that must be sent back is a design decision to confirm with the network team.
- Uplink placement: Tap or mirror the site edge where traffic leaves for headquarters, since most cross-site and vendor traffic passes there.
- Local analysis: Keep packet capture and Zeek logs on site where possible, and confirm retention and transfer rules with the central team.
- Limited staff: Local staff may not be able to replace a failed sensor quickly, so ask the partner about spares and remote recovery procedures.
- Asymmetric or NAT paths: Remote sites with multiple carriers or NAT often route return traffic differently, so verify session symmetry during commissioning.
- Hardware constraints: Confirm the site can host x86-64 hardware with the required cores, memory and two NICs, since Security Onion does not run on other processor types.
Verify with the site network team and plant engineering which traffic leaves the site, how it is routed and whether any cellular or satellite link limits what can be sent back.
Which industrial protocols Zeek and Suricata can show you
Passive sensors on plant and OT networks see only what the protocols expose on the wire. What they can show depends on which parsers and rules exist for each protocol, how the traffic is segmented, and whether the sensor sees both directions of a session. Each area below maps to a MITRE ATT&CK for ICS technique family and needs confirmation in a lab before it is relied on.
Modbus traffic and function codes
Modbus is the protocol most often seen in plant networks, and Zeek and Suricata both have support for it. Zeek can log function codes, unit identifiers and exception responses to a structured log, which makes read and write patterns easy to baseline. Suricata rules can alert on specific write function codes from unexpected sources. Before relying on either, confirm in your lab that the parser decodes the function codes and devices your PLCs actually use, and test how it handles vendor-specific extensions. Map detections to the ICS technique families in MITRE ATT&CK for ICS.
OPC UA sessions and certificate use
OPC UA is common in newer plant and historian integrations and often runs over encrypted channels. Visibility is usually limited to session metadata, endpoints, certificate exchanges and service names, not the content of process data. Zeek can record connection and session metadata for the channel, while Suricata rules are most useful for flagging unexpected endpoints or security modes. Confirm which security policies your servers negotiate and whether your sensor can see the handshake. Without that handshake, you may only see opaque encrypted sessions, which changes what you can alert on.
EtherNet/IP and PROFINET traffic
EtherNet/IP and PROFINET carry implicit and explicit messaging used for control and configuration, and parser coverage for these protocols is narrower than for Modbus. Expect metadata about connections and common services rather than full decoding of every object. Use Suricata rules for known bad or unexpected service requests and Zeek scripts to log connection patterns between controllers and devices. Confirm in your lab which services and device classes are decoded, and check how the sensor behaves when a switch mirrors multicast or real-time traffic. Mirror-port limits are a common cause of gaps here.
Engineering workstation sessions
Engineering workstations reach PLCs, drives and HMIs for programming and troubleshooting, so their sessions are among the highest-value events to observe. Zeek can log which hosts open connections to controllers, when, and for how long, which supports baselining who normally touches which zone. Suricata can alert when a host outside the engineering allowlist starts a control protocol session. Confirm that your sensor sees both directions of these sessions, and that session logs can be tied to a named engineer or change ticket through your access records. Logs without that link show activity but not accountability.
Vendor file transfers into the plant
Vendors often move firmware, project files and patches into plant networks using FTP, SMB or HTTP, sometimes through a jump host. Zeek logs file transfers and file hashes for many of these protocols, which lets you record what crossed the boundary and when. Suricata can alert on specific file types or transfers to controller addresses outside a maintenance window. Confirm which file transfer protocols your sensor decodes and whether it extracts file content or only metadata. Pair these logs with your change records so each transfer can be matched to an approved job.
Remote access and tunnel sessions
Remote access to plant networks commonly uses VPN concentrators, remote desktop tools and vendor-managed relays. Visibility here is about session start and end, source identity, duration and the zones touched, rather than the commands inside. Zeek can log connection and tunnel metadata for many of these protocols, and Suricata rules can flag remote desktop or tunneling protocols crossing into OT zones. Confirm where the sensor sits relative to the access point, because a sensor behind the remote access gateway may never see the vendor's origin address. Record these sessions against the access approval for each vendor visit.
How a plant monitoring rollout proceeds without touching production
The sequence builds the monitoring design from plant knowledge first, proves every sensor on copied traffic before it touches a live segment, and hands the site over with the runbooks operators need to keep it stable.
Inventory assets and zones with plant engineering
DeployOpen works with plant engineering and the OT owner to list network segments, cell and area zones, controllers, HMIs, historians, engineering workstations and the remote access paths between IT and OT. Each asset is tagged with its zone, owner, protocols in use and whether it is safety-relevant. The output is a zone and conduit inventory that the plant signs off on. If no current diagram exists, the first deliverable is a verified one built from switch configurations and interviews, not from the original design drawings.
Complete a passive design review
Using the inventory, DeployOpen reviews where a tap or span port can be placed without adding devices to a control path, which switches support mirroring without degrading production traffic, and where the Security Onion sensor, manager and search roles should sit. The review also checks sensor hardware against the published minimums, expected traffic volume, and whether the design requires network changes that the plant must approve. The output is a written design with placement diagrams, a list of required changes, and a documented decision on what the sensors will not see.
Test sensors on a mirrored feed in the lab
Before any live connection, the sensor build, Suricata rules, Zeek scripts and industrial protocol parsers run against a copy of captured plant traffic or a test bench that reproduces the relevant protocols. The team measures packet drops, CPU and disk load under the expected rate, and whether alerts and logs arrive at the manager as designed. Any rule that fires on normal engineering traffic is noted for tuning. The output is a signed test report that lists pass criteria, results and open issues, and the plant decides whether the design proceeds.
Install during an agreed change window
Physical installation happens in a change window that operations approves in advance, with a named contact on the plant floor and a rollback plan for each connection point. Passive taps are installed with the process at a known state, and the sensor is brought up in listen-only mode before any monitoring rules are enabled. The team confirms link status, mirrored traffic counts and that the production network shows no change in latency or error rates. The output is an installation record with the rollback steps tested and the time each change was made.
Tune rules and baseline normal traffic
Over an observation period agreed with the plant, the team records the protocols, talkers and communication patterns that are normal for each zone. Alerts from Suricata and Zeek are reviewed with engineering staff, and rules that match legitimate maintenance or vendor activity are suppressed or adjusted with a recorded reason. Detections that could be triggered by polling or engineering commands are reviewed against the plant's own change records. The output is an approved baseline per zone and a tuning log that explains every suppression.
Hand over with runbooks and training
DeployOpen delivers runbooks written for plant and SOC staff: how to read zone alerts, how to escalate a finding that may affect the process, how to change a tuning rule through the approval path, how to add a new asset to the inventory, and how to perform a sensor or Security Onion upgrade without moving traffic onto an unmonitored path. Upgrade steps cover segmented and air-gapped zones where media is carried across. Operators are trained on the console and on the escalation contacts. The output is an accepted handover package and a list of open items with owners.
Integration points and deployment patterns for plant networks
Can a SPAN port or network tap feed Security Onion sensors on a plant network?
Yes, a SPAN (mirror) port or a passive network tap can feed a Security Onion sensor, and a tap is usually the safer choice on OT links because it copies traffic in hardware without relying on a switch's mirroring process. A SPAN port is common on managed switches, but mirroring can drop packets under load and can be reconfigured by someone who is not monitoring the plant. Confirm with the plant's network team which switches support mirroring, what link speeds carry the traffic, and whether a tap can be fitted without a planned outage. Sensor hardware must meet the minimums in the Security Onion hardware documentation, which requires two NICs for a sensor node, and the sensor needs a monitoring interface that does not transmit onto the production network.
Where should Suricata and Zeek sensors sit between the DMZ and cell zones?
Place sensors where they see the traffic that crosses zone boundaries, usually at the IT to OT boundary in or beside the industrial DMZ, and add sensors inside larger cell or area zones where lateral movement matters. A sensor in the DMZ sees remote access, historian replication and patch traffic, while a sensor in a cell zone sees controller and HMI traffic that never leaves the area. Each added sensor adds hardware, tap points and a support target, so the count should follow the zone model in the plant's ISA/IEC 62443 design work. An illustrative plant with three cell zones behind one DMZ might start with one DMZ sensor and one sensor per high-consequence cell, then expand after a baseline period.
Where should the manager and search nodes go in a plant deployment?
Put the manager and search nodes in the IT or security operations network, not on the plant floor, and let sensors in the OT zones send data outward. The Security Onion architecture documentation recommends a Distributed deployment with a manager node, one or more sensor nodes and one or more search nodes for production. The manager needs a path to every sensor, and search nodes need reliable access to the manager. Confirm firewall rules, the time sources used by each node, and whether the OT zone must tolerate a sensor that holds data while the link to IT is down.
What happens to plant monitoring if the Security Onion manager goes down?
Search nodes stop indexing when the manager is unavailable, because they cannot reach Redis, so new alerts and events stop becoming searchable until the manager returns. The architecture documentation also describes receiver nodes as a way to add pipeline redundancy and load balancing. Sensors may keep capturing locally, but the plant should confirm how long local buffering lasts, how much storage each sensor holds, and how the team will know indexing has stopped. Ask the implementation partner for a written failure runbook and a monitoring check that alerts on manager health.
How do plant alerts reach the central SOC or SIEM?
Alerts and logs from the Security Onion deployment can be forwarded to a central SOC or SIEM, but the forwarding design must be agreed before rollout. Options include forwarding selected Suricata alerts and Zeek logs, forwarding only high-severity detections, or sending a filtered set to the SOC while keeping full data local for investigation. Confirm the event formats the SOC platform accepts, the volume of Zeek metadata at plant traffic levels, the field mapping for OT assets, and who owns tuning when alert volume changes. If a wider SIEM exists, check the open source SIEM and log management group for options on the receiving side.
How do you update Security Onion and its rules in an air-gapped or segmented plant zone?
The Security Onion airgap documentation says full installs can run on networks without internet access, with the ISO carrying packages and NIDS, YARA and Sigma rules. Updates come from newer ISO media through the soup update tool in airgap mode, so the plant needs a controlled way to move media across the gap. Plan a change window for each update, test the new ISO on a non-production sensor first, and record the hash and approval for every media transfer. Confirm with the vendor and the plant's change board how often media is produced, how rule content is refreshed, and what rollback looks like if an upgrade fails.
What does an implementation partner do for plant network sensor deployment?
Under a fixed-scope engagement, DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, which for a plant means the sensor, node and forwarding design, the installation in the client's environment and the runbooks for operations. DeployOpen does not issue audit reports or certifications, so evidence prepared for a compliance review is handed to the client and its independent auditor. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Ongoing upgrades and support are available as retainers.
Which plant teams must approve tap placement and sensor changes?
Approval usually involves the plant's operations and controls engineers, the OT or automation team, the IT security team, and the site safety and change management owners. Taps and switch changes can interrupt traffic, and a sensor that misbehaves on a shared switch can affect control traffic. Agree in writing who approves each physical change, what maintenance window applies, and how the team tests the change before go-live. Ask the partner to show how sensor installation avoids impact on production, including whether taps are passive and what happens if a sensor node fails.
Which evidence regulators and auditors ask for from plant monitoring
This table lists the evidence items an assessor or regulator is likely to request for passive plant and OT monitoring, and the component or record that produces each one. Read each row as a question to answer before an audit: if the component cannot produce the record, the gap belongs in the rollout plan. DeployOpen prepares these records and controls for assessment, but independent auditors and certification bodies issue any audit report or certification.
| Evidence item | Produced by | What to confirm |
|---|---|---|
| Sensor and tap inventory | Security Onion manager node and asset register kept by the site team | Each sensor's plant zone, tap or span point, NIC mapping and owner, kept current after every change |
| Tap and span diagrams | Network engineering documentation, checked against switch configurations | Where each tap or mirror port sits between IT and OT zones, and which industrial protocols it can see |
| Rule and detection change records | Security Onion Console Detections history and version control of Suricata and Zeek scripts | Who approved each NIDS rule change, suppression or threshold, and the test run that preceded it |
| Rule source and update records | Security Onion airgap or online update logs and rule set versions | Which rule sets were loaded, when they were updated, and how updates reached isolated plant zones |
| Alert triage records | SOC case records fed from Security Onion alerts | Triage outcome, analyst, timestamp and whether plant operations were consulted before any response |
| Incident timelines for NIS2 reporting | Case timeline in the SOC tooling, with Zeek and Suricata logs as supporting data | Clock sync across sensors and the manager, plus the 24-hour, 72-hour and one-month reporting milestones in your process |
| Retention settings | Security Onion storage configuration for metadata, logs and full packet capture | Retention periods set per data type, who can change them, and whether settings were reviewed on a schedule |
| Access and audit logs for the monitoring platform | Security Onion authentication and console audit trail | Named accounts for analysts and engineers, and how access reviews and removals are recorded |
How to avoid any impact on production
The first rule for plant networks is that the monitoring stack must be passive: sensors receive a copy of traffic from a span port or network tap and never sit in the control path between a PLC, HMI, historian or drive and the devices it talks to. A sensor that fails, reboots or saturates should lose visibility, not production traffic. In practice this means taps or span ports feeding the sensor's monitoring interface, no inline bridging, and no active scanning of OT segments unless the asset owner has approved it for a specific window. Ask the implementation partner to document, for each sensor, which interface receives mirrored traffic, whether any management or return path crosses the OT boundary, and what happens to the monitored link if the sensor is powered off.
Sizing has to be done for peak traffic, not average traffic. Plant networks are often quiet for most of a shift and then burst during batch changes, firmware pushes or historian backfills, and a span port that carries more than the sensor can process will drop packets without warning. Measure throughput at each mirror point during the busiest production window you can get access to, and plan sensor capacity with headroom above that peak. Review span overload carefully: a single span session aggregating several busy VLANs can oversubscribe a port that looked adequate on paper. The Security Onion hardware requirements list the minimum node resources, but those minimums describe the platform, not the traffic your plant generates, so confirm packet loss counters on the sensor during commissioning.
Every change to the monitoring estate, including new taps, span sessions, rule updates and sensor upgrades, should pass through the plant's change control process and receive a documented safety sign-off from the site engineering and safety owners before it touches an OT segment. The Machinery Regulation, Regulation (EU) 2023/1230, applies from 14 January 2027 and includes an essential requirement that machinery be protected so that connecting another device or remote device does not lead to a hazardous situation. That requirement concerns connected machinery, so confirm with the machine suppliers and your compliance team whether, and how, it reaches your monitoring equipment and the connections you add to machines.
What manufacturers ask before they monitor the plant network
What drives the cost of monitoring a plant network with Security Onion?
The cost is set mainly by how many sites and network segments need a sensor, how fast the links are, and how long packet data and metadata are kept. Each cost has a different owner. Hardware is bought once per sensor, and sensors must meet the minimum specification in the Security Onion hardware documentation, which lists 4 cores, 12 GB RAM and 2 NICs for a sensor, and 4 cores and 16 GB RAM for a manager or search node. Taps or switch span ports are another one-time item per monitored link. Storage, licenses for support and recurring analyst time for rule tuning are the costs that keep running. Security Onion itself is free to use, while Security Onion Pro is a paid edition sold on 1 to 5 year terms that adds OIDC single sign-on, FIPS mode, OS STIG compliance and professional support. Ask any quote to itemize sensors, taps, storage sizing, tuning hours and whether Pro is included, and to state who maintains the platform after go-live.
How long does a plant network monitoring rollout usually take?
No duration can be stated from the researched facts, so the timeline should come from a written scope. The main variables are the number of plants and OT zones in scope, how many tap or span points can be changed during planned maintenance windows, whether sensors must run without internet access, and how much of the baseline traffic has to be documented before alerts are tuned. Air-gapped sites also need an ISO-based install and an update path, which adds steps. A reasonable first conversation covers a pilot on one line or one zone, then a staged expansion. Ask the implementation partner to split the timeline into design, site access, installation, validation and tuning, and to name which of those depend on the plant's change calendar.
What does the plant team need to provide before sensors go in?
Passive monitoring still needs plant and IT cooperation. Before work starts, the team should be able to provide a current network diagram showing the IT and OT boundary, VLANs, and any firewalls or industrial demilitarized zones. They should also provide an inventory of control systems and protocols in use, the vendors that maintain each controller, and the names of people who approve changes on production lines. Access for installation must be scheduled with plant operations, and the team should confirm which switches support port mirroring and whether they are managed by IT or by an OT vendor. Ask the partner to list every item needed from your side, because gaps in these inputs are a common cause of delay.
Can our in-house security team run Security Onion on the plant network?
It can, but it depends on whether the team has Linux administration skills, time for tuning, and someone who understands OT traffic. Security Onion's Distributed deployment is the recommended design for production, with a manager, sensors and search nodes, and the architecture documentation notes that search nodes stop indexing if the manager becomes unreachable. Running this well means someone owns patching, backups and the Detections interface, where Suricata NIDS rules are modified, suppressed and tuned. Plant-specific alerts also need engineers from operations to review them. Teams without this capacity often choose a partner for build and handover, with a retainer for upgrades and testing. Ask any partner which tasks they would hand over, and what the internal team would need to operate the platform alone.
Does NIS2 apply to our manufacturing company?
NIS2 applies to manufacturers in the sectors listed in its Annex II, which include manufacturing of medical and in vitro diagnostic devices and NACE Rev. 2 divisions 26 to 30, covering computer and electronic products, electrical equipment, machinery, motor vehicles and other transport equipment. Whether a specific company is in scope as an essential or important entity depends on its size and national transposition, so confirm this with counsel or your national competent authority. If you are in scope, significant incidents must be reported with an early warning within 24 hours, an incident notification within 72 hours and a final report within one month, under Article 23(4). Important entities face fines of at least EUR 7 million or 1.4% of worldwide turnover under Article 34(5). Network monitoring supports detection and reporting, but it does not by itself satisfy the directive.
Can passive network monitoring disrupt PLCs or production?
Passive monitoring receives a copy of traffic through a tap or a switch span port, so the sensor should not send packets to the controllers. The real risks sit elsewhere: a tap that is installed incorrectly, a span port that is misconfigured on a switch and loads the device, a sensor that is unexpectedly active toward OT devices, or an active scan that is added later. Ask the partner to confirm that the design uses receive-only monitoring, that no active scanning is enabled on OT segments without a documented change, and that installation follows the plant's maintenance procedures. Changes that affect safety or machinery require checks against the applicable requirements, including the Machinery Regulation's essential requirement that connecting another device does not lead to a hazardous situation, which applies from 14 January 2027. Validate the design with the controls and safety engineers before go-live.
How DeployOpen scopes and supports plant network monitoring
The sequence moves from a written, fixed scope and a passive view of the plant network to sensors deployed, tested and handed over inside the client's own infrastructure, with optional retainers for ongoing tuning. Each stage ends with a checkpoint the plant owner can verify before the next one begins.
Agree a written, fixed scope
Before any work starts, DeployOpen and the plant owner agree the scope, deliverables and timeline in writing. The scope names the sites, the IT and OT zones in question, the Security Onion deployment type, and who approves changes on the production side. Plant engineering, operations and the security team should all sign the scope, because they each hold a veto over anything that touches a live process. The step is complete when the signed scope lists which zone boundaries will be observed and which are excluded.
Inventory zones, assets and protocols passively
DeployOpen reviews existing network diagrams, switch configurations and asset lists supplied by the plant, then confirms them through read-only observation. The goal is to map which controllers, historians and engineering workstations sit in each zone and which industrial protocols cross the IT and OT boundary. No active scanning of production controllers is included unless the plant owner approves it in the scope. The output is an asset and flow inventory the plant engineers have reviewed and corrected.
Design span and tap placement
Using the inventory, DeployOpen proposes where taps or switch span ports will feed sensors, at the IT and OT boundary and at selected points inside the OT zone. The design records link speeds, expected peak traffic, sensor sizing against the published Security Onion hardware minimums, and the failure behavior of each tap. Plant engineers confirm that each mirror or tap does not add load to a controller or a time-sensitive segment. The step closes with a placement diagram and a written sign-off from the plant owner.
Build and test sensors before production
DeployOpen builds the Security Onion sensors, manager and search nodes in a staging environment that mirrors the planned design, then replays representative traffic to confirm capture, Suricata alerting and Zeek protocol logs for the agreed protocols. Hardening covers host configuration, access, logging and, where the plant requires it, offline update handling. Testing records packet loss at the expected peak and any protocol the parsers do not decode. The step is complete when test results show the sensors meet the agreed scope without changing traffic on the production segments.
Deploy inside the client's infrastructure
Installation takes place inside the plant's own data centers, server rooms or isolated networks, using the client's hardware or cloud accounts as agreed in the scope. DeployOpen works through the change windows and maintenance procedures the plant owner defines, and any production-facing step waits for the agreed approval. Each sensor is checked for capture on the mirrored port and for alert delivery to the SOC or plant security contact. Completion means every sensor in the scope reports healthy status and the agreed alert path has been exercised.
Tune rules and document the baseline
DeployOpen configures the Suricata and Zeek rule sources agreed in the scope, then tunes detections in the Security Onion Console to reduce noise from recurring plant traffic such as scheduled polling. Suppressions and thresholds are recorded with the reason and the approver, so they can be reviewed later. The baseline of normal OT traffic is captured for comparison. The step is complete when the tuning log and baseline report are delivered and the plant security lead has accepted the alert volume.
Hand over runbooks and evidence
DeployOpen delivers operating documentation covering architecture, sensor locations, network diagrams, access roles, backup and update procedures, and the escalation path for each alert class. Where the plant needs evidence for an assessment, DeployOpen supplies the configuration records and monitoring logs in a form the plant can give to its own auditors. DeployOpen does not issue audit reports or certifications; independent assessors do. The handover is complete when the plant team has walked through the runbooks and confirmed they can operate the sensors without DeployOpen present.
Continue with optional retainers
After handover, the plant may choose a retainer for ongoing rule tuning, Security Onion upgrades, continued security testing of the sensors and support for new sites or protocols. Retainer scope, response expectations and the upgrade approach are agreed in writing, and changes to production-facing configuration follow the same approval path as the original deployment. The retainer is considered active when its written terms are signed and the plant has named its contacts for change requests.
