EDR for OT and ICS Environments: Endpoint Security for Operational Technology
Operational technology environments are not IT environments with different applications. They are fundamentally different computing environments where the consequences of system disruption are physical: a pump stops, a valve fails to close, a manufacturing line halts, or a power grid segment goes offline. Security controls designed for IT endpoints assume that disruption of the endpoint's operation is an acceptable cost of protection. In OT environments, that assumption is wrong.
The 2021 Colonial Pipeline ransomware attack disrupted fuel supply across the US East Coast not because attackers compromised pipeline control systems directly, but because the company shut down OT operations as a precaution after an IT network compromise. The Oldsmar water treatment attack the same year demonstrated that IT/OT boundary failures create direct access paths to systems controlling physical infrastructure. These incidents established OT cybersecurity as a board-level concern and accelerated investment in OT-specific security platforms.
This guide covers what makes OT endpoint security different from IT endpoint security, which constraints govern the deployment of endpoint agents in industrial environments, and how to evaluate the vendor landscape that has emerged to address these requirements. The goal is to give security architects the technical vocabulary and evaluation framework to make defensible OT endpoint security decisions without disrupting the operational processes they are protecting.
Why Standard EDR Cannot Be Deployed As-Is in OT Environments
Standard endpoint detection and response tools are designed for IT environments where certain assumptions hold: the operating system is a currently supported version, patches can be applied within weeks of release, restarting a system or process for remediation is acceptable, and the cost of a false positive response (quarantining a file, terminating a process) is measured in user productivity rather than physical production output.
In OT environments, each of these assumptions fails in ways that make standard EDR deployment dangerous rather than protective.
OT systems cannot tolerate agent-induced reboots. A PLC or HMI reboot during active process control can cause production outages measured in hours or days, with financial consequences that exceed the cost of a security incident the reboot was meant to address. Standard EDR agents may require reboots during installation, during agent version updates, and following kernel driver changes. Each reboot event requires OT change management approval, outage scheduling, and coordination with operations teams, making routine agent lifecycle management a significant operational burden.
Real-time kernel monitoring interferes with deterministic process control. OT systems running SCADA software and real-time control applications are designed to execute process control loops with microsecond to millisecond timing precision. EDR agents that perform kernel-level monitoring introduce latency variability into system operations. For most OT applications this latency is negligible. For precision motion control, high-speed manufacturing, or safety instrumented systems with tight timing requirements, agent-induced latency variation can disrupt process control performance.
Legacy operating systems are pervasive in OT environments. Windows XP, Windows 7, Windows Server 2003, and unsupported Linux distributions remain in active use on HMIs and engineering workstations across industrial environments, because OT equipment vendors often bundle specific operating system versions with their control system software and do not support OS upgrades without full control system requalification. Most modern EDR agents do not support operating systems that have reached end of life with their vendors, which means legacy OT systems are simply incompatible with standard EDR deployment.
Patch cycles in OT are measured in years, not weeks. An OT system running a certified configuration may not receive patches for twelve to eighteen months, and some control system vendors require full system requalification before patch application. EDR agents that cannot be maintained at current versions accumulate known vulnerabilities in the agent software itself, creating a security control that introduces new attack surface.
The Colonial Pipeline and Oldsmar incidents illustrate that the primary OT security threat is not direct exploitation of PLCs and control systems through specialized OT malware, but rather lateral movement from IT environments into OT networks through inadequately protected boundary systems. The endpoint security priority for most OT programs should address the IT/OT boundary and the OT-adjacent systems (historian servers, DMZ-resident gateways, engineering workstations with IT connectivity) before attempting to address deep OT assets where agent deployment is most constrained.
OT Endpoint Security Requirements
The requirements that differentiate OT endpoint security from IT endpoint security derive from the operational constraints described above. Understanding these requirements before evaluating vendors determines which tools are technically viable and which will create operational risk.
Passive monitoring is the default posture. OT security controls should observe and alert without generating network traffic or system activity that could affect process control operations. Active scanning (sending probe packets to discover services, enumerating running processes through active queries) is unacceptable in environments where unexpected network traffic can trigger IDS alerts, disrupt industrial protocol communication, or interfere with deterministic process timing. Passive monitoring means capturing traffic from SPAN ports or network taps, reading process lists from OS APIs without probing, and collecting logs without generating additional system load.
Application whitelisting is more reliable than behavioral detection in OT. IT EDR tools use behavioral anomaly detection to identify threats: processes behaving unusually, code executing from unexpected locations, network connections to unusual destinations. This approach works well in IT environments where process behavior is diverse and dynamic. OT systems, by contrast, run the same set of applications executing the same set of operations in highly repetitive patterns for months or years without change. Application whitelisting, which allows only explicitly approved applications to execute, is architecturally better suited to OT environments than behavioral detection, because the small set of legitimate OT applications makes whitelist maintenance feasible and the low rate of application change makes whitelist updates infrequent.
Removable media control addresses the primary OT infection vector. USB-borne malware is the leading delivery mechanism for OT compromises, particularly for air-gapped or minimally connected systems where network-based attack paths are unavailable. Controls include disabling USB storage device class mounting through group policy, mandatory scanning of removable media at sanitization kiosks before entering the OT network, and physical USB port blockers on systems where disabling the device class through software is not feasible.
Integrity monitoring for engineering workstation configurations provides a change detection capability that is achievable even on legacy operating systems. Baseline configuration capture followed by continuous comparison to the baseline identifies unauthorized software installation, configuration file modifications, and new executable additions without requiring the full agent footprint of a modern EDR product.
Agentless options must be available for systems where agent installation is not feasible. Many OT security requirements can be satisfied through network-based monitoring (passive capture and analysis of industrial protocol traffic, authentication events, and network connection patterns) without deploying any software on the OT endpoints themselves. Agentless options are not a compromise; for deep OT assets at Level 0 and Level 1 of the Purdue Model, they are the only viable approach.
Passive monitoring without traffic generation
All monitoring activity must be read-only and must not generate network traffic on OT segments. Acceptable: SPAN port capture, syslog collection, log forwarding from existing agents. Not acceptable: active port scanning, network discovery probes, SNMP polling that generates broadcast traffic on OT segments.
Application whitelisting over behavioral detection
OT systems run predictable, repeated application sets. Whitelisting approved executables and blocking unknown code is more reliable and less disruptive than behavioral anomaly detection in environments where normal behavior is highly consistent.
Removable media control
USB media is the primary malware delivery vector for OT systems with limited or no network connectivity. Controls include device class disabling, sanitization kiosks for mandatory scanning before entry, and registered media programs for high-risk environments.
Legacy OS support without agent modification
Security monitoring must be available for Windows XP, Windows 7, Windows Server 2003, and unsupported Linux distributions that cannot host modern endpoint agents. Network-based monitoring and agentless integrity checking must substitute for agent-based telemetry on these systems.
Zero impact on process control timing
Any endpoint software deployed in OT environments must be validated to introduce no measurable latency or timing variability to real-time control applications. Vendors should provide specific documentation of testing in representative OT environments, not generic performance benchmarks from IT test environments.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Also compare in endpoint security
IT EDR Vendors with OT Adaptations
The major IT EDR vendors have developed OT-specific deployment guidance and product configurations in response to customer demand, but these remain IT tools adapted for OT rather than purpose-built industrial security platforms. Understanding what each vendor offers and where the limitations remain is essential for evaluating them against OT-specific requirements.
CrowdStrike Falcon for OT offers a reduced telemetry mode configuration that limits the active scanning activities of the Falcon agent to reduce the risk of process interference. CrowdStrike has published specific OT deployment guides and offers OT-specific threat intelligence through Falcon Intelligence, which includes coverage of ICS-targeting threat groups. The Falcon sensor does support some legacy Windows operating systems through its extended support program, but support for Windows XP and very old Windows Server versions is limited. CrowdStrike's partnership with Dragos allows integration between Falcon telemetry and the Dragos Platform for organizations that want to combine IT EDR visibility with OT-specific threat detection and response.
SentinelOne Singularity for OT offers a passive monitoring configuration mode designed specifically for sensitive environments. SentinelOne has extended its operating system support to include some legacy Windows versions and has published OT-specific deployment guidance. The platform includes integrations with OT asset management tools and supports deployment in environments where the control plane is isolated from the internet through a locally managed console option.
Microsoft Defender for Endpoint in older Windows environments requires custom policy configuration to reduce active scanning activities. Microsoft's Defender for IoT (formerly CyberX) is a separate product positioned specifically for OT environments, providing agentless network-based monitoring of industrial protocols rather than endpoint agent-based detection. Defender for IoT integrates with Microsoft Sentinel for SIEM-based detection and response.
The honest assessment of all three platforms is that they are IT EDR tools with OT-specific configuration guidance rather than platforms designed from the ground up for industrial environments. Their threat intelligence is primarily IT-oriented with OT additions rather than OT-native. Their agent deployment models, even in reduced-footprint configurations, carry more operational risk in deep OT environments than purpose-built OT monitoring approaches. They are most appropriate for OT-adjacent systems (historian servers, DMZ gateways, engineering workstations with IT network connectivity) where IT EDR capabilities are more applicable and where the consequences of agent-related disruption are lower.
Purpose-Built OT Security Platforms
The purpose-built OT security platform category was developed specifically to address the constraints that make IT security tools inappropriate for industrial environments. These platforms are designed from the ground up to monitor OT networks and endpoints without generating traffic, without requiring agent installation on production systems, and with native understanding of industrial protocols.
Dragos Platform is the most widely recognized purpose-built OT security platform, with a primary focus on network-based threat detection and OT-specific incident response. Dragos ingests industrial protocol traffic (Modbus, DNP3, OPC-UA, PROFINET, EtherNet/IP) through passive network sensors and applies behavioral detection rules developed specifically for ICS threat actor tactics. The Dragos WorldView threat intelligence program maintains the most extensive library of named OT threat groups and ICS-specific attack techniques, making Dragos the strongest choice for organizations in critical infrastructure sectors where attributable threat intelligence is a primary security program requirement. Dragos provides OT-specific incident response retainer services and has responded to more confirmed ICS security incidents than any other vendor. For organizations subject to NERC CIP requirements, Dragos maintains extensive mapping of its detection capabilities to CIP standards.
Claroty provides OT asset discovery, vulnerability management, and network monitoring through a combination of passive network analysis and optional lightweight agents for OT-adjacent systems. Claroty's acquisition of Medigate in 2021 extended its platform into healthcare OT, medical devices, and building management systems, making it particularly strong for healthcare organizations managing a mix of clinical and operational technology. Claroty's vulnerability management capabilities, which correlate OT asset inventory with known OT vulnerabilities from ICS-CERT advisories and the Claroty vulnerability research team, are among the strongest in the market for organizations prioritizing exposure management across their OT asset inventory.
Nozomi Networks provides network-based OT monitoring with a hybrid deployment model that combines passive network sensors with an optional endpoint agent (Nozomi Arc) for OT-adjacent systems that can support it. Nozomi's strong multi-protocol support and its competitive pricing relative to Dragos and Claroty make it a common choice for mid-market industrial organizations and managed security service providers offering OT security services. Nozomi integrates with a broad range of SIEM, ticketing, and asset management platforms, which is relevant for organizations that need OT monitoring to feed an existing security operations infrastructure.
Fortinet OT Security combines FortiEDR with OT-specific policy templates and integrates with Fortinet's network security products (FortiGate OT firewalls, FortiNAC for OT network access control) to provide a coordinated OT security architecture. Fortinet's advantage is primarily for organizations already running Fortinet network infrastructure in their OT environment, where adding Fortinet's OT security components provides tighter integration and unified management than deploying a separate OT security platform alongside existing Fortinet infrastructure.
The critical distinction between purpose-built OT platforms and IT EDR tools adapted for OT is that the OT platforms monitor the OT network and its protocols natively, providing visibility into industrial process communications that IT tools cannot interpret. An IT EDR tool on an HMI sees the HMI's Windows processes and file activity. An OT network monitoring platform sees the Modbus commands being sent from the HMI to PLCs, the DNP3 communications between substations, and the OPC-UA data flows from field devices to historian servers. This protocol-level visibility is what enables OT-specific threat detection: identifying a malicious command being injected into a Modbus session, detecting anomalous setpoint changes in PLC communications, or flagging unauthorized engineering workstation connections to control systems.
The Network vs. Endpoint Debate in OT Security
One of the most productive debates in OT security program design is whether to invest in network-based monitoring or endpoint-based monitoring, and the answer is not either/or but a deliberate combination based on asset criticality and technical feasibility.
Network-based monitoring (using passive taps or SPAN ports to capture and analyze industrial protocol traffic) is the dominant primary control in mature OT security programs. The reasons are practical: network sensors can be deployed without touching production systems, they provide visibility into industrial protocol communications that endpoint agents cannot interpret, they work regardless of the operating system running on OT endpoints, and a single network sensor can provide visibility into all communications on a network segment without per-system deployment.
The limitation of network-based monitoring is that it is blind to endpoint-level compromise that does not generate unusual network traffic. An attacker who has placed a backdoor on an engineering workstation and is conducting reconnaissance by reading local files and configuration data without generating network traffic will not be detected by network-based monitoring. A cryptominer that was introduced via USB and is consuming CPU resources while communicating with a mining pool using allowed DNS and HTTPS connections may not trigger network-based detection rules.
Endpoint monitoring catches process and file-level activity that network monitoring misses, but risks disrupting sensitive systems and is not technically feasible on many OT assets. The convergence that most mature OT security programs reach is: network monitoring as the primary control covering all OT segments and all assets within them, with selective endpoint monitoring focused on the OT-adjacent systems that face the highest risk and can support monitoring with the lowest operational impact.
The OT-adjacent systems most suitable for endpoint monitoring are historian servers (which aggregate process data and often have IT network connectivity), DMZ-resident data transfer systems (which bridge OT and IT networks), and engineering workstations that have internet connectivity or removable media access. These are also the systems where IT EDR tools adapted for OT are most appropriate, because they are Windows-based systems with more conventional IT characteristics than deep OT assets, but are within or adjacent to the OT network perimeter where OT-specific configuration is still required.
Network monitoring: what it covers
Industrial protocol traffic (Modbus, DNP3, OPC-UA, PROFINET), connection patterns between OT assets, authentication events on network-accessible systems, command and response patterns in SCADA communications, and anomalous traffic across IT/OT boundary points. Network monitoring is the only technically feasible control for Level 0 and Level 1 OT assets.
Network monitoring: what it misses
Endpoint-local activity that does not generate network traffic: file system changes, new process execution from USB-delivered malware, configuration modifications on isolated systems, and attacker activity during quiet reconnaissance phases before exfiltration or destructive action.
Endpoint monitoring: what it covers
Process execution, file system changes, application whitelisting violations, USB device insertions, configuration modifications, and user account activity on systems that can host monitoring agents. Most applicable to Level 3 historian servers and Level 2 HMIs and engineering workstations.
Endpoint monitoring: what it risks
Agent-induced latency on time-sensitive control systems, installation and update reboots that require planned outages, incompatibility with legacy operating systems, and the operational complexity of managing agent deployments across OT change management processes.
Recommended convergence: layered by asset criticality
Network monitoring covering all OT segments (all Purdue levels) as the baseline control, supplemented by endpoint monitoring on OT-adjacent systems (Level 3 and internet-facing Level 2 assets) using OT-configured IT EDR or lightweight OT-specific agents where technically feasible and operationally safe.
Vendor Evaluation Criteria for OT Endpoint Security
Organizations evaluating OT security platforms should apply criteria that reflect the specific constraints and requirements of industrial environments rather than adapting IT security evaluation frameworks. The following criteria address the dimensions that most directly determine whether an OT security tool will be deployable and effective in a real industrial environment.
OT protocol awareness
Does the platform natively understand and parse industrial protocols including Modbus TCP/RTU, DNP3, OPC-UA, PROFINET, EtherNet/IP, IEC 61850, and BACnet? Protocol-native parsing is required to detect anomalies in industrial communications (malicious command injection, unauthorized setpoint changes, unexpected device registrations) that appear as normal IP traffic to protocol-unaware tools.
Legacy OS support without agent modification
Can the platform provide meaningful security monitoring for Windows XP, Windows 7, and unsupported Linux versions either through lightweight agents specifically supported for those versions or through agentless network-based monitoring? Verify specific supported OS version lists with the vendor and request customer references for environments running those specific OS versions.
Passive monitoring option with verified zero traffic generation
Does the platform provide a deployment mode that generates no network traffic on monitored OT segments? Request vendor documentation that verifies passive-only operation and ask for references from customers who have validated this claim in their environments. Passive monitoring is not just a checkbox; it is a deployment architecture that should be validated in a proof-of-concept before production deployment.
Integration with existing SIEM and SOC tooling
Does the platform support log forwarding and alert integration with the SIEM and SOC tools already used by the security operations team? OT security alerts that are siloed in a separate OT-only console increase the analyst workload rather than reducing it. SIEM integration allows OT-specific alerts to be correlated with IT-side alerts that may indicate lateral movement from IT to OT environments.
OT-specific threat intelligence
Does the vendor maintain and publish OT-specific threat intelligence covering ICS-targeting threat groups and OT attack techniques? The MITRE ATT&CK for ICS framework is the reference standard; verify that the vendor maps its detections to ATT&CK for ICS tactics and techniques. Vendors with dedicated OT threat research teams (Dragos is the strongest example) provide more actionable OT-specific intelligence than IT vendors with OT intelligence additions.
Vendor OT expertise and incident response capability
Does the vendor have demonstrable OT incident response experience and the capability to provide emergency support for OT security incidents? OT security incidents have potential physical consequences that require response teams with operational technology domain knowledge, not just cybersecurity expertise. Verify vendor incident response capability through case studies, retainer service offerings, and direct conversation with the incident response team.
Compliance framework coverage
Does the platform provide evidence-ready reporting for NERC CIP requirements (for electric sector operators), IEC 62443 security level assessments, and NIST SP 800-82 control coverage? Compliance reporting that maps platform findings and detections to specific CIP requirements reduces the manual effort of preparing CIP audit documentation and validates that the platform addresses the specific controls that regulators will examine.
Total cost including OT-specific deployment professional services
OT security platform deployments require professional services investment that is typically higher than IT security tool deployments due to the complexity of OT network segmentation, passive tap or SPAN port deployment in industrial network infrastructure, and integration with OT asset management and change management processes. Request fully loaded cost estimates that include professional services for deployment, OT-specific tuning, and ongoing threat intelligence and detection rule updates.
The bottom line
OT endpoint security is not IT security with different operating system constraints. It is a distinct discipline that requires understanding the Purdue Model, industrial protocol communications, the physical consequences of security control disruption, and the specific compliance frameworks that regulate critical infrastructure sectors.
For most OT security programs, the right starting point is network-based monitoring that provides visibility across all OT segments without touching production systems. Purpose-built OT platforms from Dragos, Claroty, and Nozomi Networks are purpose-designed for this deployment model and provide OT-specific threat intelligence that IT security vendors cannot match for industrial protocol-level detection.
IT EDR tools from CrowdStrike, SentinelOne, and Microsoft have appropriate roles in OT environments, but primarily for OT-adjacent systems (historian servers, DMZ gateways, engineering workstations with IT connectivity) where IT EDR capabilities are more applicable and where OT-specific configuration reduces the operational risk of agent deployment. Deploying standard IT EDR configurations on deep OT assets without careful validation creates more risk than it mitigates.
Frequently asked questions
Can CrowdStrike or SentinelOne be used safely in an OT environment?
CrowdStrike Falcon and SentinelOne Singularity can be deployed in OT environments, but only with specific configuration modifications that reduce their active scanning and behavioral monitoring footprint. Standard deployment of either platform in an OT environment, using default IT configurations, creates unacceptable risk because the agents perform active kernel-level monitoring and periodic scanning activities that can interfere with deterministic process control systems. CrowdStrike offers a reduced telemetry mode and OT-specific deployment guidance through its professional services team. SentinelOne offers a passive monitoring configuration for sensitive environments. In both cases, the OT-adapted configuration reduces the depth of detection compared to standard IT deployment: agents are configured to observe rather than intervene, which means active response capabilities like process termination or quarantine are disabled for systems where those actions could cause physical process disruption. For internet-facing OT components like historian servers, DMZ-resident data aggregation systems, and engineering workstations with external connectivity, IT EDR with OT-appropriate configuration is a practical control. For deep OT assets like HMIs directly attached to PLCs, legacy systems running unsupported operating systems, or any system where agent installation carries meaningful risk of process disruption, purpose-built OT monitoring platforms that operate without endpoint agents are the more appropriate technical control.
What is the Purdue Model and why does it matter for OT endpoint security?
The Purdue Model, formally called the Purdue Enterprise Reference Architecture (PERA), is a hierarchical reference model for industrial control system network architecture developed by Theodore Williams at Purdue University in the 1990s. The model organizes OT and IT systems into five levels based on their function and proximity to physical processes. Level 0 contains the physical process itself: sensors, actuators, and the physical equipment being controlled. Level 1 contains the basic control systems: PLCs, distributed control systems (DCS), and remote terminal units (RTUs) that receive sensor data and send control commands. Level 2 contains supervisory control systems: HMIs, SCADA systems, and engineering workstations that operators use to monitor and control Level 1 systems. Level 3 contains manufacturing operations management systems: historian servers, manufacturing execution systems (MES), and batch management systems that aggregate and analyze process data. Level 4 and 5 contain enterprise IT systems: ERP, corporate email, and business applications. The Purdue Model matters for OT endpoint security because different security controls are appropriate for different levels. Endpoint agents may be deployable on Level 3 historian servers and Level 2 engineering workstations (which often run Windows operating systems with sufficient resources to host an agent). Level 1 PLCs and Level 0 sensors are not general-purpose computers and cannot host endpoint agents at all. Network-based monitoring is typically the only option for providing security visibility at Levels 0 and 1. Understanding which Purdue level a given asset occupies determines which endpoint security controls are technically feasible for that asset.
What is the difference between Dragos, Claroty, and Nozomi Networks?
Dragos, Claroty, and Nozomi Networks are the three most established purpose-built OT security platforms, and all three focus primarily on network-based OT monitoring with varying secondary capabilities. Dragos is differentiated primarily by its OT threat intelligence through the Dragos WorldView intelligence program and its team of OT-focused incident response practitioners. Dragos has attributed more named OT threat groups (CHERNOVITE, KAMACITE, ELECTRUM) than any other vendor and maintains the deepest public OT threat intelligence library. The Dragos Platform is strongest for organizations in critical infrastructure sectors (electric utilities, oil and gas, water) where OT-specific threat intelligence and incident response capability are primary selection criteria. Claroty built its position through strong OT asset discovery and vulnerability management capabilities, and expanded its platform through the acquisition of Medigate (healthcare OT and IoT security) in 2021. Claroty is strongest for healthcare organizations managing a combination of OT, medical device, and building management system security, and for industrial organizations prioritizing asset inventory and vulnerability management over threat intelligence depth. Nozomi Networks is positioned as a flexible OT monitoring platform with strong passive discovery capabilities, support for hybrid deployments combining network sensors and endpoint agents, and broad OT protocol support. Nozomi is competitive across vertical sectors and is often selected for its deployment flexibility and competitive pricing relative to Dragos and Claroty at mid-market scale.
How does USB media control work in OT environments without network connectivity?
USB removable media control in OT environments is a critical security control because USB-borne malware is one of the primary infection vectors for air-gapped or minimally connected OT systems. The Stuxnet malware, the most studied ICS cyberattack, was delivered via USB media to OT systems with no internet connectivity. In OT environments, USB media control is typically implemented through a combination of technical and procedural controls. Technical controls include group policy settings on Windows-based HMIs and engineering workstations that disable USB storage device class mounting entirely, application whitelisting products that prevent execution of software from removable media even if the device can be read, and dedicated USB media sanitization stations (purpose-built hardware kiosks that scan USB drives for malware before they enter the OT environment). For systems where USB access cannot be technically disabled due to operational requirements (firmware updates to PLCs that require USB delivery, for example), procedural controls include logging of all removable media insertions through endpoint monitoring agents or physical security cameras, mandatory scanning at sanitization kiosks before entry, a registered media program that tracks approved USB devices by serial number, and dual-person integrity requirements for high-risk USB operations near critical control systems. Vendors that provide OT-specific USB control include Honeywell Secure Media Exchange (a purpose-built OT USB sanitization kiosk), OPSWAT MetaDefender (a malware scanning platform used in OT USB sanitization workflows), and the application whitelisting features of Tripwire, TXOne Networks, and Claroty Edge agent products.
What compliance frameworks govern OT cybersecurity and what do they require for endpoint security?
The primary OT cybersecurity compliance frameworks are NERC CIP (North American Electric Reliability Corporation Critical Infrastructure Protection standards, mandatory for bulk electric system operators), IEC 62443 (the international OT security standards series, used across sectors globally), and NIST SP 800-82 (the US government guide to industrial control systems security, used as a reference by federal agencies and critical infrastructure operators). NERC CIP applies specifically to operators of the North American bulk electric system. CIP-007 (Systems Security Management) requires patch management and security event monitoring for medium- and high-impact BES Cyber Systems, which translates to requirements for change detection monitoring and log management on OT endpoints in scope. CIP-010 (Configuration Change Management) requires baselining of system configurations and change detection, which aligns with integrity monitoring tools for OT endpoints. IEC 62443 is a series of standards that applies across industrial sectors and establishes security levels (SL1 through SL4) with escalating control requirements. For endpoint security, IEC 62443-3-3 (System Security Requirements and Security Levels) specifies requirements for software execution monitoring (relevant to application whitelisting), malicious code protection (relevant to endpoint security agents), and audit log management across OT system components. For critical infrastructure operators subject to CISA advisories and sector-specific regulatory guidance (TSA Security Directives for pipelines and aviation, EPA cybersecurity requirements for water utilities), endpoint security requirements are increasingly specified in incident reporting rules and minimum cybersecurity practice requirements that reference both NERC CIP and IEC 62443 as underlying frameworks.
How should organizations prioritize OT endpoint security when budgets are shared with IT security?
Budget competition between IT and OT security programs is a documented challenge in organizations that have not separated OT security funding. The prioritization framework that produces the most defensible outcome uses a consequence-based risk model rather than a vulnerability-count-based model. The starting point is consequence analysis: for each OT system, define the physical consequence of a security incident affecting that system. A historian server going offline creates a data availability impact. An HMI compromise creates a potential process control impact. A PLC compromise creates a direct physical process impact including safety risk. Systems with higher consequence severity deserve disproportionate security investment regardless of IT-derived vulnerability scoring that may rank them lower based on CVSS scores alone. With consequence-based prioritization established, OT endpoint security investment typically follows this order: first, segmentation controls that prevent IT-side compromises from reaching OT networks (the IT/OT boundary is the highest-leverage control point); second, network-based monitoring for OT protocol traffic (provides visibility without touching production systems); third, endpoint security controls for internet-facing OT components (historian servers, DMZ systems, remote access gateways); and fourth, application whitelisting and integrity monitoring for Level 2 HMIs and engineering workstations. When presenting OT security investment requests alongside IT security budget requests, framing OT risk in operational and safety terms rather than cybersecurity terms reaches leadership audiences more effectively. The cost of a process disruption incident, measured in production downtime, regulatory fines, and potential safety liability, typically exceeds the cost of the endpoint security controls that could have prevented it.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.