The Problem with Standard EDR in OT
Industrial control system environments were not built to run endpoint detection software. The engineering workstations, HMIs, historians, and jump servers that make up the Windows footprint of a typical OT network are running software and OS versions that predate modern EDR architecture. A Siemens WinCC HMI running Windows 7 Embedded Standard cannot run a current-generation EDR agent — it doesn’t meet the minimum system requirements. A Rockwell PLC programming terminal running FactoryTalk on Windows 10 LTSC may run an agent, but any interference with the FactoryTalk process from EDR interception logic risks a trip event.
The standard IT EDR deployment model — push the agent via SCCM or RMM, scan on-access, intercept process creation, monitor network connections in real time — is not appropriate for most OT assets. The performance overhead of real-time interception is acceptable when a 200ms delay on a file write doesn’t matter. In a DCS or safety system context, it might.
This doesn’t mean OT environments can’t have endpoint security coverage. It means the deployment approach needs to be OT-specific: risk-stratified by asset criticality and OS capability, staged through maintenance windows, and configured with OT-aware exclusion profiles from the start.
Asset Classification for OT EDR Deployment
Before deploying any endpoint security tooling, classify OT assets into deployment tiers:
Tier 1 — Standard agent eligible: Windows 10/11 or Server 2016+ engineering workstations, jump servers, data historian servers, and IT-OT DMZ systems. These typically have sufficient resources for a lightweight EDR agent and are not directly connected to control system hardware. Deploy standard EDR agents here, with OT-specific exclusions for vendor software (OSIsoft PI, AspenTech, AVEVA, etc.).
Tier 2 — Lightweight agent only: Windows 7, Windows Embedded, or Windows Server 2008/2012 HMI systems, older SCADA servers, and OPC servers. Resource-constrained environments where a standard EDR agent may cause performance issues. Lightweight agents from vendors who maintain legacy OS support — Claroty xDome Endpoint, Honeywell Forge Cybersecurity Suite, and Dragos Platform endpoint coverage — are appropriate here. Configure in monitor-only mode without real-time interception.
Tier 3 — Agentless only: PLCs, RTUs, DCS controllers, safety systems (SIS), and embedded devices. These are not Windows systems and cannot run agents. Endpoint visibility here comes entirely from network-level monitoring — passive traffic analysis via network TAPs — not from endpoint agents. The “endpoint security” for Tier 3 assets is correctly implemented at the network layer (passive monitoring, zone enforcement, change detection for traffic pattern deviations).
Tier 4 — No monitoring change: Legacy systems on proprietary OS, serial-protocol-only devices, and safety systems where any change requires a change management process that takes longer than the deployment timeline. Document these gaps explicitly. They inform the risk register, not the deployment plan.
Agent vs. Agentless: What Each Actually Covers
The “agentless” OT security approach — passive network monitoring with deep packet inspection of industrial protocols — is well-established and provides excellent network-layer visibility. What it does not cover:
- Process creation and termination on endpoints
- File system modifications on engineering workstations
- User authentication events on local systems (if not forwarded to SIEM)
- USB and removable media activity
- In-memory execution (fileless malware running in PowerShell or WMI)
For Tier 1 and Tier 2 assets — the Windows systems that are most likely to be initial access targets — network-only monitoring misses the endpoint behaviours that matter most. Agent-based coverage provides the visibility that network monitoring cannot.
The pragmatic approach: deploy agentless passive network monitoring (Claroty, Dragos, Nozomi, or open-source alternatives using Zeek with ICS decoders) across all zones, and layer agent-based endpoint coverage on Tier 1 and Tier 2 assets only. The combination provides defence-in-depth without requiring agents on control system hardware.
OT-Specific EDR Configuration
Standard EDR agents deployed on OT Windows systems need configuration adjustments before rollout:
Exclusion Profiles for OT Vendor Software
Most OT vendors’ software generates process creation and file access patterns that trip standard EDR rules. Before deployment, build exclusion profiles for:
- OSIsoft/AVEVA PI System: PI Data Archive, PI AF Server, PI Vision — high-volume file I/O and process activity
- Rockwell FactoryTalk: FactoryTalk View, FactoryTalk Diagnostics, RSLinx Classic — regular UDP broadcast activity and process spawning
- Siemens TIA Portal / WinCC: ScadaRT.exe, SimRuntime.exe — HMI runtime processes with elevated privilege requirements
- Honeywell Experion / Uniformance: PHD Server, Process Knowledge System processes
- Emerson DeltaV: DeltaV Explorer, DeltaV Operate runtime processes
- GE Proficy: Historian client and server processes, CIMPLICITY runtime
Work with each OT vendor’s cybersecurity team to obtain their recommended exclusion lists before deployment. Most major OT vendors now provide documented compatibility guidance for common EDR platforms.
Scan Mode Configuration
For Tier 2 legacy systems, disable or restrict:
- On-access scanning: Replace with scheduled off-shift scans only (maintenance window periods)
- Real-time process interception: Switch to detect-only mode, not prevent mode
- Automatic quarantine: Disable automatic quarantine on OT endpoints — an EDR that quarantines FactoryTalk during a production run creates an immediate process safety event. Alert only; manual remediation through change control.
- Network connection interception: Disable if running at the host firewall level; rely on network-layer monitoring for connection visibility
Performance Baselines
Before deploying agents on any OT endpoint, establish a performance baseline: CPU utilisation, memory utilisation, disk I/O, and network bandwidth consumption during normal operation. After agent deployment, verify the endpoint returns to baseline within defined tolerances. If CPU utilisation increases by more than 10-15% at peak load, escalate to the OT vendor for compatibility assessment before proceeding.
Deployment Sequencing
Deploy OT endpoint security in phases aligned with maintenance windows, not on the IT endpoint security rollout schedule:
Phase 1 — DMZ and jump servers (standard maintenance window): Highest-value targets from an attack path perspective, standard Windows environments, no OT vendor software conflicts. Validate the agent, baseline, and exclusion profile in this tier before touching operational networks.
Phase 2 — Data historians and SCADA servers (planned maintenance window): High data value, Windows environments with OT software installed. Test exclusion profiles against production OT software workloads. Validate that agent operation does not affect historian data collection rates or SCADA polling cycles.
Phase 3 — Engineering workstations (off-shift, planned): Active OT programming environments. Coordinate with OE/control systems engineers to ensure agents are not deployed during active programming or commissioning activity.
Phase 4 — HMI systems (next scheduled turnaround or planned outage): HMIs are the most risk-sensitive Windows systems to touch. Deploy only during planned maintenance when the process being controlled is in a safe state. Have OT vendor support on standby for the first deployment in each HMI software family.
Never phase: PLCs, RTUs, SIS controllers. These are covered by network monitoring only.
OT-Aware EDR Products
Several security vendors have developed OT-specific endpoint coverage:
Claroty xDome Endpoint Agent: Designed specifically for OT environments, with pre-built exclusion profiles for major OT vendors and a lightweight footprint that supports Windows 7 Embedded. Integrates with the Claroty platform for correlation with network-layer detection.
Dragos Platform with Endpoint Collection: Dragos’s endpoint component focuses on the specific behaviours relevant to OT attack chains — credential harvesting on engineering workstations, lateral movement toward OT assets, staging behaviour before OT-specific payload deployment. Correlates endpoint events with Dragos threat intelligence on OT-targeting actors.
Nozomi Networks Guardian Air: Agentless wireless OT/IoT security monitoring, relevant for environments with wireless-connected OT assets.
Honeywell Forge Cybersecurity Suite: Vendor-specific endpoint security for Honeywell Experion and Uniformance environments, with native compatibility across the Honeywell portfolio.
For organisations with existing enterprise EDR (CrowdStrike Falcon, Microsoft Defender, SentinelOne), these vendors have published OT compatibility guidance and in some cases OT-specific policy templates. Enterprise EDR on Tier 1 assets with OT-specific configuration is a viable path; OT-specialist platforms add value primarily at Tier 2 and for the correlated OT threat intelligence context.
Logging and SIEM Integration
OT endpoint agent logs should feed into a SIEM with OT context — asset classification, zone membership, and OT software baseline profiles — for alert triage. Raw endpoint alerts from OT assets without this context generate noise that OT staff will tune out.
Key log sources to integrate:
- Windows Security Event Log: Authentication events (4624, 4625, 4672), process creation (4688), service installation (7045), scheduled task creation (4698)
- Agent telemetry: Process execution, file modifications in vendor software directories, network connection anomalies
- USB/removable media events: All USB insertion events on OT endpoints should be alerted; removable media is a primary infection vector for air-gapped and near-air-gapped OT environments
Alert priority for OT endpoint events: any execution of PowerShell, cmd.exe, or scripting engines on HMI or SCADA servers should be high-priority — these processes have no legitimate role in most OT environments and are primary initial post-access tools for attackers who have reached OT systems from an IT-side compromise.
Measuring OT Endpoint Coverage
Track coverage by tier as a quarterly metric:
- Tier 1 coverage: Percentage of Tier 1 assets with active EDR agent
- Tier 2 coverage: Percentage of Tier 2 assets with lightweight agent deployed
- Tier 3 visibility: Percentage of Tier 3 asset communication captured by passive network monitoring
- Tier 4 documentation: Count of assets in the unmonitored tier, with risk register entries for each
OT endpoint security programs rarely achieve 100% coverage — the asset mix includes devices that cannot run agents and processes that cannot tolerate the associated risk. Complete coverage documentation, including explicit acknowledgment of unmonitored assets and compensating controls, is more valuable than overstating deployment scope.
A Note on Change Management
Every OT endpoint security deployment is a change to a controlled environment. Even if the technical work is straightforward, the change management process must be followed: formal change request, risk assessment reviewed by OT operations and process safety, rollback plan documented, and approval from the appropriate authority (operations manager, site manager, or safety officer depending on the organisation’s MOC process).
The change management overhead is not bureaucratic resistance to cybersecurity — it is the mechanism that prevents a well-intentioned security deployment from causing a production incident. It also creates the documentation trail that demonstrates due diligence in security program management.