Endpoint monitoring for manufacturing and OT workstations: why the plant floor changes the design
On a plant floor, the design is driven by production uptime and vendor support, not by detection alone. Engineering workstations and HMIs often run older Windows builds, sit on networks that cannot tolerate heavy agents, and are certified by equipment vendors to run a specific software stack. Any monitoring change must be tested against that stack before it touches a production line, and a rollback plan is part of the design from day one. For most manufacturers the short answer is layered. Wazuh is the core for agent-based alerting, file integrity monitoring and log collection on hosts that support its agent. osquery provides lightweight inventory of installed software, services and listening ports, so you can see what is on each machine without a full scan. Velociraptor handles targeted hunts and offline triage when a workstation must be examined in place. Falco belongs only where containers run, which is often not the case on an HMI or engineering workstation.
Plant networks are also governed by a different body of guidance. IACS asset owners need the OT context set out in the ISA/IEC 62443 series, which organizes requirements into general, policies and procedures, system and component groups. In particular, ANSI/ISA-62443-2-1-2024 describes the security program an asset owner must run, and ANSI/ISA-62443-3-2-2020 covers risk assessment for system design. Before you deploy anything, confirm with your OT security lead which zones and conduits the workstations belong to, which vendor-supported configurations must stay untouched, and which response actions the operations team has pre-approved. The practical decision is what the agent is allowed to do. Read-only collection and alerting are usually easier to approve than active response that stops processes or changes firewall rules on a controller-adjacent host. Ask your vendors in writing which agent versions, scan rates and file monitoring paths they support, and record those answers as part of the scope before any pilot begins.
Which requirements shape the build for manufacturers
This table maps the standards and regulations that apply to manufacturing and OT workstations to the decisions they force on agent choice, change windows, log retention and incident reporting. Read each row as a question to answer before selecting tools, since several requirements apply to different parties (asset owners, suppliers and manufacturers of products). Applicability depends on your sector code, location and whether you supply products into the EU.
| Requirement | What it means for the build | What to confirm or evidence |
|---|---|---|
| ISA/IEC 62443-2-1-2024 (asset owner program) | Sets the security program expected of the plant or operator. Agent choice must fit a documented policy for which OT hosts are monitored and how exceptions are approved. | Confirm the asset inventory, named owners for each zone and a written decision on which engineering workstations and HMIs get agents, logs only or no monitoring. |
| ISA-62443-3-2-2020 (risk assessment for system design) | Zone and conduit risk assessment should set how deeply each workstation is monitored. Higher-risk zones justify richer telemetry and tighter response limits. | Ask for the zone and conduit diagram and the risk ratings that drive monitoring depth, and record where Wazuh or osquery data will cross zone boundaries. |
| ISA-62443-3-3-2013 (system security requirements and security levels) | Security levels set expectations for logging, access and malware protection on the system. Monitoring design should be traceable to the target level for each zone. | Map each monitored host to its target security level and confirm which requirements the monitoring evidence supports and which need other controls. |
| ISA-62443-4-2-2018 (component requirements, sent to suppliers) | Applies to product suppliers rather than asset owners. Ask OT vendors whether their controllers and HMI software tolerate agents, and what they require for patching and logging. | Request written vendor statements on supported agents, approved file integrity scope and any warranty conditions affected by installed software. |
| NIS2 Annex II (manufacturing scope) | Manufacturing is a listed critical sector, covering medical devices and NACE Rev. 2 divisions 26 to 30. In-scope entities must keep logs and incident records that support reporting. | Confirm whether your sites fall under NIS2 and whether you are an essential or important entity, since this affects supervision and fines. |
| NIS2 Article 23(4) reporting deadlines | Significant incidents require an early warning within 24 hours, a notification within 72 hours and a final report within one month. Alert routing and log retention must support these clocks. | Document who triages OT alerts out of hours, how timestamps are synchronized across Wazuh and plant systems, and where the incident record is kept. |
| Machinery Regulation (EU) 2023/1230, Annex III 1.1.9 (from 14 January 2027) | Machinery must be protected so that connecting another or remote device does not create a hazardous situation. Remote or agent-driven response on machines needs safety review before automation. | Keep response actions on production machinery manual or approval-gated, and involve the machine builder and safety engineers in design. |
| Cyber Resilience Act Article 14 (from 11 September 2026) | Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents. Monitoring should flag exploitation signals on products you make, not only on workstations you run. | Confirm whether you are a manufacturer of such products, and define the internal path from a detection to a reportable notice. |
| NIST SP 800-82 Rev. 3 (OT security, September 2023) | Covers SCADA, DCS, PLCs and building systems, with explicit attention to performance, reliability and safety. Passive monitoring and staged change windows are usually preferred over active scanning on OT networks. | Ask for the OT asset types in scope, the test plan for each agent and the rollback steps before any change on a live line. |
Which open-source platforms fit plant-floor endpoints
Engineering workstations and HMIs rarely fit one tool. Wazuh, osquery, Velociraptor and Security Onion each cover a different part of the job, from continuous monitoring to offline triage and network visibility. The limits of each choice, especially for older Windows versions, decide which combination a plant can actually run.
Wazuh for agent-based monitoring
Wazuh combines a manager, indexer and dashboard with agents on Windows and Linux endpoints, and its core is licensed under GPL-2.0. The 4.14 release line is the current one, so plants should pin an agent version that their HMI vendor and Windows build support. File integrity monitoring on engineering project folders and controller configuration directories is a common use. Vulnerability detection can read an offline repository, which matters where workstations cannot reach the internet. Confirm agent footprint and Windows version support on each HMI before rollout.
osquery for scheduled, low-footprint queries
osquery exposes process, service, network and file state as SQL tables and runs on Windows, Linux and macOS. Scheduled queries through osqueryd can check for unexpected listening ports or USB device history at a modest load, which suits machines that cannot tolerate heavy scanning. The project has no central server, so a fleet manager such as Fleet, OSCTRL or Zentral is needed to deploy and collect results at scale. Wazuh's osquery module is one route to central collection. Test query frequency on a non-production HMI first.
Velociraptor for offline-capable triage
Velociraptor collects forensic artifacts and runs hunts across endpoints, and it suits hosts where a permanent agent is not accepted by the process owner. Collections can be triggered on demand during an incident, which limits background load on controller-facing machines. Teams should confirm whether the Velociraptor client builds and dependencies run on their specific Windows versions, and how collected evidence is stored inside the plant network. Its use for ransomware triage is covered on a sibling page.
Security Onion as the network companion
Security Onion bundles Suricata, Zeek, osquery and the Elastic stack, and it is licensed under the Elastic License 2.0. Endpoint visibility on a host is complementary to network sensing at the plant boundary, where traffic between IT and OT zones can show lateral movement that a workstation agent misses. Sensor placement on OT networks needs review against vendor and safety constraints before any mirror port is added. Confirm the Elastic License 2.0 terms fit your redistribution and hosting plans with counsel.
Where Falco does not apply
Falco is built for runtime detection in containers and Kubernetes nodes using kernel-level event sources. Most plant-floor workstations and HMIs run classic Windows or embedded systems without container runtimes, so Falco rarely adds coverage there. Plants with container workloads on MES or historian servers can still use it on those Linux nodes. Treat Falco as a question for the platform team, not a default for the control floor, and confirm kernel support with your OS vendor before any deployment.
How a monitoring rollout on OT workstations proceeds
The sequence moves from inventory and agreement with the OT owner and vendors to a passive pilot, measured resource use, file integrity baselines, staged agents and runbooks, so that monitoring never reaches a running line before the people accountable for it have approved each step.
Inventory assets and vendor dependencies
The OT owner, the controls engineers and DeployOpen build a list of engineering workstations, HMIs and historians with operating system version, service pack, network zone, installed vendor software and the vendor that supports each system. The team also records which machines are on a running line and which can be taken offline. The output is an asset register with a named owner and a support contact for every station, and a list of systems where the vendor has not confirmed that an agent is permitted.
Agree vendor support and change windows
The rollout plan is reviewed with each OT vendor and the plant change board before any software is placed on a controller-adjacent machine. Each vendor confirms in writing whether a monitoring agent is supported, which file paths and processes must not be touched, and whether their warranty or license terms are affected. Change windows are set around production schedules. The output is a signed rollout scope that lists approved hosts, approved agent types and the maintenance windows in which installation may happen.
Run a passive pilot with resource measurement
The first deployment goes to non-critical stations, such as an offline engineering workstation or a spare HMI with no control function. The agent collects events and sends them to the server without any response capability enabled. CPU, memory, disk I/O and network use are measured under normal and peak engineering activity, and the vendor's application is tested for stability. The output is a measurement report with observed overhead against the vendor's limits and a go or no-go decision recorded by the OT owner.
Build the file integrity baseline
Once the pilot shows acceptable overhead, file integrity monitoring is configured on paths the OT owner approved, such as vendor program directories, project files and configuration folders. Known-good hashes are captured on a clean, verified state, and expected changes such as scheduled project downloads are documented so they do not generate noise. The output is a baseline document listing monitored paths, hash capture date, the people who can approve changes and the alert routing for unexpected modifications.
Deploy agents in stages
Agents move to production in small groups, starting with the stations that have the lowest process risk and ending with those closest to live control. After each group, the team checks agent health, alert volume, application performance and the vendor's support status. Rollback steps are tested on one station before a group is expanded. The output is a deployment log showing each host, agent version, installation date, rollback method and the operator who signed off the group.
Write safe response playbooks
Response is limited to alerting and evidence collection on running lines. Automatic isolation or process termination is disabled on any station that controls or displays live processes. Playbooks define who is notified, what artifacts are collected (such as process lists, file hashes and event logs), and when a human at the plant must approve any containment step. Isolation is only considered during planned outages, and each playbook names the vendor contact to involve. The output is a tested playbook set with approval roles documented for each action.
Hand over runbooks and confirm ownership
DeployOpen documents the configuration, baseline locations, alert triage steps, change procedures for approved file paths and the escalation chain to OT vendors. The plant team runs a tabletop exercise with the playbooks, and the OT owner confirms who maintains agents, reviews integrity alerts and approves changes after the engagement ends. The output is a signed handover package with runbooks, an ownership matrix and a record of the exercise, which the plant can use for its own assessments.
Safe response actions on production lines
Alert-only monitoring is the lowest-risk starting point for engineering workstations and HMIs. Wazuh generates alerts from agent telemetry and rules, and a person decides what happens next. Nothing on the host changes, so the main risks are operational rather than technical: alert fatigue, missed events on hosts that are offline for long periods, and alerts that reach people who cannot act on them without the plant engineer. Plan who receives each alert class before go-live, and confirm that the alerting path works during a maintenance window, not only in the lab.
- Alert routing: Map each rule group to an owner, such as the security team for credential access and the plant engineering team for changes to controller software.
- Tuning period: Expect noisy rules on legacy systems and reduce them with documented exceptions rather than silencing whole rule groups.
- Offline hosts: Confirm how queued events are handled when a workstation is disconnected, since many OT hosts are off the network between shifts.
- Alert records: Keep alert history and the triage decision together so auditors can see who reviewed each event.
Before relying on alerts, confirm with the plant and the OT vendor that the agent's footprint and any monitoring activity are approved for each host class.
Evidence collection reads state from a host without changing its behavior. Velociraptor artifacts and osquery queries can list running processes, loaded modules, network connections and file hashes. This is far safer than remediation, but it is not free. Heavy queries, full disk searches or memory capture can load a legacy workstation enough to affect a control application or a PLC programming session. Restrict collection to lightweight artifacts, schedule broad hunts outside production hours, and agree throttles with the plant before the first run.
- Query scope: Use narrow osquery queries for specific checks, such as hash comparisons on engineering project folders, instead of broad scheduled sweeps.
- Resource limits: Confirm CPU and disk impact on representative hardware in a test environment before any hunt reaches production hosts.
- Approval: Require change or engineering sign-off for hunts that touch systems tied to controllers or safety functions.
- Chain of custody: Hash and log every collection, including who ran it, when, and from which console.
Confirm with the OT vendor which artifacts they accept on their software, because some vendors treat any additional process or file access as a support risk.
Active response blocks a process, quarantines a file or isolates a host. In an IT environment this is routine. On a production line it can stop a process that was never malicious, such as a vendor tool that writes to a folder the rule considers suspicious. Isolating an HMI can cut the operator's view of a process, and a blocked driver can halt a controller connection. Wazuh active response is configured per rule, so each rule that triggers a response needs an explicit decision on what it does and which hosts it applies to. Test every rule in a non-production environment first, using a replica of the engineering workstation image where possible, and record the expected effect.
- Per-rule decisions: Document the response, target hosts and rollback step for each active response rule before enabling it.
- Approval model: Limit automatic responses to narrow, well-understood events, and require a plant and security approver for anything that isolates a host.
- Change records: Store the rule version, approver, test evidence and every triggered action in the change system and the SIEM.
- Rollback: Confirm how a blocked process or isolated host is restored, and who can do it outside business hours.
- Vendor coordination: Ask the OT vendor whether the response causes a support or warranty issue before it is enabled on their equipment.
Before enabling any automated response, confirm with the plant manager and the OT vendor that the response is acceptable for each production system.
How to coordinate monitoring with OT vendors and integrators
Before any agent touches an engineering workstation or HMI, the owner should have a written agreement with the controller and HMI vendor, and with the integrator who maintains the system. Many OT vendors restrict which software may be installed on their platforms, and some state that unapproved installations void support. The agreement should name the approved agent and its version, the directories and file paths the agent reads, whether scheduled scans or file integrity checks are permitted and at what times, how response actions such as isolating a host or killing a process are handled, and the patch window in which vendor-validated updates are applied. Ask each vendor to confirm these points in writing, and ask whether a monitoring change would affect their warranty or their support contract.
The same agreement should say where vendor-supplied software versions come from. Wazuh vulnerability detection correlates the software inventory collected from endpoints with vulnerability data, so a controller engineering package or HMI runtime that the inventory does not recognize will be missed. Ask each vendor for a bill of materials or a list of component versions for every supported release, and confirm whether the vendor publishes security advisories that map to those versions. For structuring detections, the MITRE ATT&CK for ICS matrix gives a shared vocabulary of adversary techniques against industrial systems. Teams can map each rule to a technique, then review with the vendor which techniques their platform can realistically be exposed to, so that alerts that depend on unsupported behavior are tuned out early rather than discovered during an incident.
Evidence that auditors and regulators ask for from OT endpoints
This table lists the evidence an assessor or regulator is likely to ask for from manufacturing and OT workstations, which component produces each item, and where the record usually breaks down. Use it to decide what must be collected, retained and reviewed before an audit or a NIS2 reporting clock starts. DeployOpen prepares this evidence for your assessors, but independent auditors and certification bodies issue any audit report or certification.
| Evidence item | Produced by | What the assessor or regulator expects |
|---|---|---|
| Asset inventory of engineering workstations and HMIs | osquery queries and Wazuh system inventory | Complete, dated list of hosts with OS version, owner and network zone, reconciled against the OT asset register |
| File integrity monitoring change records | Wazuh syscheck on supported hosts, with logs for unsupported hosts | Records of changes to controller project files, configuration and binaries, with who approved each change |
| Alert and investigation records | Wazuh alerts and case notes in the SIEM or SOAR | Timestamped alerts, triage decisions and closure reasons showing that alerts were reviewed |
| Incident timeline for NIS2 early warning and notification | Wazuh alerts, Velociraptor collections and the incident log | Reconstructed timeline supporting the 24-hour early warning and 72-hour notification deadlines in Article 23(4) |
| Vulnerability reports for legacy Windows hosts | Wazuh vulnerability detection with an offline repository where hosts have no internet access | Current findings per host, risk decisions for unpatched systems and compensating controls |
| Change-window logs for patching and agent updates | Change tickets matched to Wazuh agent and configuration changes | Evidence that changes happened inside approved windows and were tested with the OT vendor first |
| Forensic collections from suspect hosts | Velociraptor collections with hashes and chain-of-custody notes | Preserved artifacts, documented handling steps and hashes that match the collected files |
Questions manufacturers ask before monitoring OT workstations
Can a monitoring agent run on an old HMI or engineering workstation?
Sometimes, and the answer depends on the operating system build, free disk and memory, and what the vendor allows on the machine. Wazuh agents run on Windows, Linux, macOS, Solaris, AIX and HP-UX, but the supported version list is what decides the question, so check it against the exact OS build on each HMI. Where an agent is not supported or the OT vendor forbids installation, the fallback is collecting logs through syslog or Windows event forwarding and monitoring file integrity from a supported host. Ask the OT vendor in writing which software can be installed on each controller-adjacent machine before you plan the design.
Does OT workstation monitoring need a maintenance window?
Installing an agent usually does, because it changes a machine that runs a production process and may restart services. Plan the install for a planned stop, keep the agent configuration minimal at first, and test on a spare or staging HMI before production. Passive collection such as reading event logs or receiving syslog does not touch the process and can often start without a stop, but it still needs sign-off from plant operations. Agree the change procedure, rollback steps and who approves each change before the first machine is touched.
How much effort does an OT asset inventory take, and what drives it?
The effort is driven by how many machines are in scope, how many were never documented, and how much access the plant allows for discovery. Most plants find that engineering laptops, vendor service PCs and HMIs have changed since the last drawing set. Start with a passive inventory from the network and logs, then confirm each asset with the cell owner. ISA/IEC 62443 asks asset owners to know what is in the zone and conduit model, and ANSI/ISA-62443-2-1-2024 sets security program expectations that include this. Ask any partner to quote by the number of zones, sites and assets, and to state which discovery methods they will use.
Can our internal IT and OT team run endpoint monitoring without outside help?
A capable IT team can run Wazuh day to day, but OT monitoring usually needs people who understand both the control network and the process. Internal teams often handle the platform, alert review and routine updates, while the parts that need outside help are the first architecture, safe collection design and the first OT-specific detection content. Check that someone on staff can tell a legitimate engineering change from a suspicious one, and that there is a named person for every machine. A partner can cover the gaps as a fixed-scope project, and retainers can cover upgrades and tuning afterward.
How do NIS2 reporting deadlines affect alert handling on the plant floor?
NIS2 Article 23(4) requires in-scope entities to send an early warning within 24 hours, an incident notification within 72 hours and a final report within one month, so alerts on OT workstations must reach someone who can judge significance quickly. Manufacturing is listed as a critical sector in NIS2 Annex II for several NACE Rev. 2 divisions, so check whether your sites are in scope. Set up triage routes that include OT engineering, not only the SOC, define who decides whether an alert is significant, and keep timestamps and evidence from the first alert. Confirm the exact obligations with counsel and your national authority.
Do we need OT vendor sign-off before installing monitoring tools?
In most cases yes, because many OT vendors state in their support terms which software may run on a controller, HMI or engineering station, and installing unapproved software can void support or affect certified configurations. Ask each vendor for written confirmation of permitted agents, ports, update methods and any restrictions on scanning. Keep vendor responses in the change record, and treat passive monitoring as the default until a vendor approves active collection. Also check the Machinery Regulation requirement that connecting another device must not lead to a hazardous situation, since it applies from 14 January 2027.
What does monitoring cost, and what is one-time versus recurring?
Costs fall into the inventory and design work, the platform build, the collection setup on each machine type, the detection content, and then recurring staff time, storage and support. Open-source components carry no license fee for the core products, but you still pay for servers, storage, engineering time and any support subscription. The main drivers are the number of machines, the number of sites and whether monitoring must stay inside a plant network. Ask any quote to separate one-time build effort from recurring operations and to list which OT vendor approvals and change windows it assumes.
How do we avoid breaking a production line while monitoring?
Start with read-only collection, test every change on non-production equipment, and never run active response actions such as killing processes or isolating a host from a live line without a documented procedure. Use Wazuh file integrity monitoring on defined paths, such as project files and configuration folders, and keep the alert scope narrow at first so noise does not cause operators to stop trusting alerts. Plan a rollback for every agent change and agree in advance which actions the plant may take when an alert fires.
Questions to ask an implementation partner about OT endpoints
Start with the partner's experience as a supplier to IACS asset owners under the ISA/IEC 62443 series, not only as an IT security integrator. Ask which parts of the series they have applied in practice: the asset owner program requirements in ANSI/ISA-62443-2-1-2024, the zone and conduit risk assessment in ANSI/ISA-62443-3-2-2020, and the system security requirements and target security levels in ISA-62443-3-3-2013. Ask for a sample of the zone model and risk register they produced for a plant, with the sensitive details removed. A partner who cannot explain how monitoring data flows across the boundary between the process network and the business network has not yet done this work. Ask them to name the roles they expect you to fill, such as the plant engineering owner, the OT security lead and the vendor liaison, and confirm that each has been agreed in writing before the statement of work is signed.
Ask how the partner tests the Wazuh agent, osquery configuration and any file integrity monitoring rules on the exact Windows builds and control applications running on your engineering workstations and HMIs, not on a lab image. Request the test plan and ask what they measure: CPU and memory use during scheduled scans, disk I/O on historian-adjacent hosts, behavior when the network is interrupted and whether the vendor's control software still starts and runs normally. Ask how they handle updates to agents and rules on hosts that cannot be patched on a normal cycle, and whether any change is staged on a test bench that mirrors a production cell. Confirm that the partner will not push a new agent version or configuration to a live controller-adjacent host without a documented rollback path.
Ask how the partner defines safe response for these hosts before any automated action is enabled. Active response that kills a process, blocks a network address or isolates a machine can stop a production line, so the reader should see a written list of permitted actions per asset class, the conditions that trigger each one, and who must approve them in advance. Ask who signs off changes to detection rules, response policies and offline update packages, and how that sign-off is recorded. For offline updates and media transfer, ask how signatures and hashes are checked on each package, who handles the removable media, and how the chain of custody is logged. Finally, ask how they coordinate with OT vendors whose warranties or certifications depend on the software baseline, and request the written agreement that defines which vendor must be contacted before a change is made.
