OT Endpoint Protection Guide: Choosing Antivirus, EDR and Allowlisting for Control Systems

Control-system hosts need malware protection, but the wrong product, an untested signature update or an automatic quarantine can stop a plant as surely as the malware it was meant to block. HMIs, SCADA servers, historians and engineering workstations run Windows or Linux, so they can run antivirus, endpoint detection and response (EDR) or application allowlisting, yet each option behaves differently on a host that may be air-gapped, pinned to a vendor-qualified build and expected to run for months without a reboot. This guide is about the choice and the rollout: which protection fits which class of OT host, how to qualify products with automation suppliers, how to deliver signatures to disconnected networks, how to set response actions safely, and how to move allowlisting from monitor mode to enforcement. It is for OT security leads, control system engineers and IT security teams extending endpoint programmes into plants. Hardening of individual host types is covered in the Engineering Workstation Security Guide and the HMI and SCADA Server Hardening Guide; this guide does not repeat them.

Key takeaways

• Match the control to the host, not the policy. MITRE ATT&CK for ICS mitigation M0949 says antivirus should be limited to assets not involved in critical or real-time operations; static, single-purpose hosts are often better served by allowlisting.
• Qualification comes before selection. If the automation supplier has not tested a product and version with your control system release, installing it can put the system outside support and is an untested change to a production asset.
• Signature updates are a change, not a background task. NERC CIP-007-6 R3.3 requires a process for testing and installing signature updates, and its guidance warns that a false positive could harm system availability.
• Detect everywhere, respond carefully. Run EDR and antivirus in alert or detect-only mode on critical hosts and keep automatic quarantine, process kill and network isolation for hosts whose loss does not affect the process.
• Allowlisting suits OT, slowly. NIST SP 800-82 Rev. 3 notes that the static nature of OT makes allowlisting a good fit, but every project change and patch may need a policy update, so plan the change process before enforcing.

The three options and what they actually do on an OT host

NIST SP 800-82 Rev. 3 recommends antivirus and file integrity checking "where technically feasible", lists allowlisting as a host protection layer in defence in depth, and advises considering host-based monitoring on HMIs, SCADA servers and engineering workstations only where it does not adversely affect operational performance or safety. NERC CIP-007-6 R3 deliberately does not prescribe a method: its guidance names traditional antivirus, allowlisting, network isolation and IDS/IPS as options and lets the entity decide per system. For a general comparison outside OT see EDR vs Antivirus.

Choosing per host class

Decide per class of host, not per site. The starting points below assume the host runs a general-purpose operating system and that the automation supplier supports the chosen product.

The CIP-007-6 guidance makes a related point: a cyber asset with no updateable software and unalterable executing code is considered to have its own internal method of deterring malicious code. Do not force an agent onto something that cannot meaningfully run one.

Supplier qualification and selection criteria

Most major automation suppliers publish which antivirus and allowlisting products and versions they have tested with each release of their SCADA, DCS and engineering software, often with required exclusions and settings. The ATT&CK for ICS mitigation M0949 states that all products should first be validated within a representative test environment before deployment to production systems.

• Read the compatibility list for each control system release, including the product version and engine or platform version. A product tested with release N is not automatically qualified for release N+1.
• Record required exclusions exactly as the supplier documents them (folders, processes, file types) and treat any exclusion not on the list as a risk decision with an owner. See the EDR Tuning and Exclusions Management Guide.
• Ask about offline operation: can the agent run, detect and report fully with no internet access, through an on-premises or OT DMZ management server?
• Ask about resource use: CISA's recommended practice IR-18-214 warns that scanning can significantly raise CPU and memory use and disrupt applications on outdated or under-provisioned hardware. Measure on your oldest qualified hardware.
• Check operating system coverage: the agent must support the oldest Windows and Linux builds in the plant, including long-term servicing editions, for the life of the control system.
• Check response controls: per-group policies that can disable automatic quarantine, process termination and network isolation for critical hosts while keeping detection.
• Treat the protection product as supply chain: IR-18-214 recommends evaluating antivirus products as part of the supply chain, ideally through an approved products list.

For broader evaluation questions see the EDR and XDR Buyer's Guide and the Application Control and Endpoint Prevention Buyer's Guide; add the OT criteria above to either.

Delivering signature and agent updates to disconnected networks

IR-18-214 sets out the reference pattern. Antivirus, WSUS and patch servers sit in the control centre DMZ, each network level talks only to adjacent levels, and the OT update server never talks directly to the vendor. It recommends separate, hardened hosts for antivirus, WSUS and patch functions.

1. Download on a dedicated, internet-connected host in IT or the OT DMZ, and verify the source and a cryptographic hash of each file. IR-18-214 notes that checking the URL or vendor IP alone is not enough and that automatic updates often rely on CRC checks, which are weaker.
2. Transfer inward either by an automatic chain from enterprise to DMZ server, or by dedicated, locked removable media scanned before and after use, which IR-18-214 notes is common in air-gapped networks.
3. Test on a representative system that matches production; IT test systems do not reflect OT.
4. Deploy in order of least criticality: corporate IT, then the OT DMZ, then the control network, and within each, non-critical assets first, for example a backup HMI before the primary.
5. Back up endpoints before updating where possible, and schedule updates in maintenance windows under change management.

Worked example: Microsoft Defender Antivirus on disconnected hosts. Microsoft documents five update sources and a configurable fallback order: WSUS, Microsoft Update, a UNC file share, Configuration Manager and direct security intelligence downloads (shown as MMPC in policy). The UNC share option is described for devices without internet access: an internet-connected host downloads the full and delta packages (mpam-fe.exe, mpam-d.exe) into x64 and x86 folders, and endpoints are pointed at the share root with the Group Policy settings "Define the order of sources for downloading security intelligence updates" and "Define file shares for downloading security intelligence updates" under Microsoft Defender Antivirus, Security Intelligence Updates. Platform updates (KB4052623, copied as updateplatform.exe) are monthly and must be replaced on the share manually. Microsoft notes that security intelligence updates publish several times a day, so an OT network that receives them weekly through a tested relay is a deliberate trade-off between freshness and change control, which CIP-007-6 guidance accepts: HMIs exposed to portable media may justify rapid updates with minimal testing, while other hosts warrant tested updates.

Agent and engine upgrades are software changes, not content updates: route them through the OT Patch Management Guide process with supplier qualification and a rollback image.

Response actions: detect everywhere, act selectively

NIST SP 800-82 Rev. 3 tells operators to consider the effects of automated responses on OT before deploying them. CIP-007-6 guidance adds that antivirus may be set to remove or quarantine automatically, but allows removal to be delayed for reliability reasons, for example until a rebuild can be scheduled, provided monitoring is increased and the code is prevented from communicating with other systems in the meantime.

Write the response decision into the OT incident plan: who may approve isolating a Level 2 host, and how the process keeps running while it is offline. See the OT Incident Response Guide.

Allowlisting rollout: from monitor mode to enforcement

The general method (rule types, audit and enforcement, event IDs) is in the Application Allowlisting Guide, with Windows detail in App Control for Business (WDAC) and Linux detail in the fapolicyd and Linux Application Allowlisting Guide. In OT the sequence changes in four ways.

1. Build from a verified known-good image, ideally the supplier-qualified golden image held for recovery. See the OT Backup, Recovery and Golden Image Guide.
2. Monitor through full operating cycles, not a fixed number of days: shift changes, month-end reports, alarm floods, backup jobs, supplier maintenance and at least one patch cycle. Review every would-be block with the control engineer.
3. Enforce first on a redundant or standby host, with operations present and a written rollback: revert to the monitor policy and restart, tested in advance.
4. Tie the policy to change control: every control system patch, supplier hotfix and new engineering tool updates the policy before deployment, and the policy version is recorded with the change. Prefer publisher rules for signed supplier software so routine updates do not need new hash rules.

NIST SP 800-82 Rev. 3 asks operators to coordinate allowlisting with suppliers and to test configurations thoroughly before deployment; NIST SP 800-167, Guide to Application Whitelisting, covers planning in more depth.

Where identity fits

• Management console accounts: whoever administers the EDR or allowlisting console can disable protection or push a policy to every HMI. Give console access named accounts, phishing-resistant MFA and role separation between policy authors and approvers.
• Update relay service accounts: the accounts that move signatures across zones, and the share permissions on update folders (Microsoft's procedure calls for at least Read for authenticated users), are a path for tampered content. Restrict write access to the relay identity only.
• Tamper protection and local administrators: operators with local administrator rights can stop agents. Remove standing local admin and manage local passwords centrally. See NHIs in OT and the OT and ICS Identity and Access Guide.

Detection and measurement

• Coverage by host class: share of eligible OT hosts with a qualified agent or allowlisting policy, reported per class from the table above.
• Signature age: median and maximum age of security intelligence on OT hosts against the target set for each class.
• Allowlisting state: share of Level 2 hosts in enforce mode, and count of hosts stuck in monitor mode longer than the agreed period.
• Agent health: hosts not reporting to the console in the last 24 hours, and any agent stopped or uninstalled outside a change.
• False positive rate: detections on control system files per update cycle, with each one fed back to the supplier and the test procedure.
• Blocks and detections on removable media: trend for transfer stations and engineering workstations, which shows whether media controls are working. See the Removable Media and USB Control Guide.

Forward agent alerts, tamper events and policy changes to the OT SOC. See the OT Security Operations Centre Guide.

Common failure patterns

• IT policy pushed to OT: the enterprise EDR policy, with automatic isolation and daily full scans, applied to HMIs because they joined the same management group.
• Unqualified version drift: the agent auto-upgrades to an engine the automation supplier has not tested, often because the OT console inherits IT update settings.
• Signatures months old: an air-gapped network that was never given a relay, so antivirus reports "installed" while detecting nothing recent.
• Allowlisting left in monitor mode: deployed, generating logs nobody reviews, and never enforced because the change process was not ready.
• Broad exclusions: whole drives or the control application folder excluded to fix a performance problem, creating the place malware will be written.
• Agent on a host it should not be on: a heavy agent on under-provisioned or legacy hardware, slowing HMI screens or historian writes during an upset.

Framework mapping

CIP-007-6 guidance notes that R3 complements, but does not satisfy, the malware protection obligations for transient cyber assets and removable media under CIP-010-2. For the wider standards view see the NIST SP 800-82 OT Security Guide and the NERC CIP Guide.

Practitioner checklist

• Every OT host is assigned a host class with a primary control and a response mode.
• Each product and version in use is on the automation supplier's compatibility list for the installed control system release.
• Exclusions match the supplier's documentation, and every extra exclusion has an owner and review date.
• Signatures reach every network through a hardened relay with hash verification and a tested deployment order.
• Automatic quarantine, process kill and isolation are off for Level 2 hosts, with a manual approval path written into the incident plan.
• Allowlisting reached enforcement on a redundant host first, with a tested rollback to monitor mode.
• Policy updates are a mandatory step in OT change control and patching.
• Console administration uses named accounts with phishing-resistant MFA, and agents have tamper protection on.
• Coverage, signature age and enforcement state are reported monthly by host class.

Standards and references

• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NERC: CIP-007-6 Cyber Security, System Security Management
• CISA: Recommended Practice, Updating Antivirus in an Industrial Control System
• MITRE ATT&CK for ICS: M0949 Antivirus/Antimalware
• MITRE ATT&CK for ICS: M0938 Execution Prevention
• MITRE D3FEND: Executable Allowlisting
• NIST: SP 800-167 Guide to Application Whitelisting
• Microsoft Learn: Manage the sources for Microsoft Defender Antivirus protection updates

Related NHI Mgmt Group resources: Engineering Workstation Security Guide · OT Patch Management Guide · HMI and SCADA Server Hardening Guide · OT Security Guide