Application Allowlisting in OT: Locking Down What Runs on Critical Hosts

01Key takeaways

1. 01

   Application allowlisting permits only approved executables, libraries and scripts to run, and denies everything else by default.

2. 02

   It suits OT because industrial hosts run a small, stable software set for years, so deny-by-default rarely interferes with operations.

3. 03

   Allowlisting is most effective against unsigned malware, dropped payloads, living-off-the-land binaries and unauthorized engineering tools.

4. 04

   It depends on a clean baseline, controlled change management and protection of the rules themselves; a poorly maintained allowlist becomes either a blocker or a bypass.

5. 05

   Allowlisting hardens the host but does not control how files reach it. One-way transfer and segmentation reduce the inbound paths an attacker would use to deliver code.

02What application allowlisting is

Application allowlisting is a deny-by-default execution control. The host holds a list of software that is explicitly trusted, and the operating system refuses to run anything that is not on that list. The older term whitelisting describes the same idea; NIST and most vendors now use allowlisting.

This is the inverse of traditional antivirus. Signature-based antivirus tries to identify and block known-bad files, which means a brand-new or slightly modified payload can slip through until a signature exists. Allowlisting flips the logic: the defender does not need to know what the malware looks like, because anything not previously approved is denied regardless.

Short version: antivirus asks "is this known to be bad?" Allowlisting asks "is this known to be good?" and blocks everything else.

03Why it fits OT and ICS hosts

OT endpoints are not like office laptops. An HMI, an engineering workstation, a historian or an operator station usually runs a fixed vendor application stack that changes only during planned upgrades. New software almost never appears for a legitimate reason between maintenance windows. That predictability is exactly what allowlisting needs to work cleanly.

These hosts are also hard to patch. Vendor validation cycles, safety constraints and long support contracts mean an OT host can run an unsupported operating system for years. Allowlisting helps here because it reduces the value of an unpatched vulnerability: even if an exploit lands, the attacker still cannot execute an arbitrary payload that the host was never told to trust.

NIST SP 800-82 Rev. 3, the Guide to Operational Technology (OT) Security, treats application allowlisting as a recommended host control precisely because OT software baselines are stable and downtime tolerance is low. The control matches the environment rather than fighting it.

04The threats it actually stops

Allowlisting is narrow but decisive. It does one thing well: it prevents unapproved code from executing. That single property defeats a surprising share of the techniques used against industrial endpoints.

• Dropped malware and ransomware binaries that arrive via removable media, email on a connected IT host, or a compromised update.
• Unsigned or untrusted executables introduced by a contractor laptop or a transient maintenance tool.
• Living-off-the-land abuse, where attackers run scripting hosts, PowerShell, or system utilities to stage activity, when those interpreters are constrained or denied.
• Unauthorized engineering and remote-access tools installed outside change control.
• Persistence mechanisms that try to launch a new, unapproved service or scheduled task on boot.

Several of these map directly to MITRE ATT&CK for ICS techniques, including Execution through API, scripting and the use of unauthorized engineering software. Allowlisting raises the cost of all of them, because the attacker must work entirely within already-trusted code instead of bringing their own.

05How allowlisting decides what runs

An allowlisting engine intercepts execution attempts and checks each one against its rules before allowing the code to load. The strength of the deployment depends on which identifiers it uses to decide trust.

Cryptographic hash

A unique fingerprint of a specific file version. Precise and hard to spoof, but the rule breaks the moment the file is legitimately updated, so it needs change management.

Publisher / digital signature

Trust based on a software vendor's signing certificate. Survives version updates from that vendor but trusts everything they sign, so scope it carefully.

Path and parent process

Trust based on file location or what launched it. Convenient but weaker, because an attacker who can write to a trusted path or abuse a trusted parent can bypass it.

Memory protection

Controls that block fileless and in-memory techniques such as injected code or reflective loading, which pure file-based rules miss.

Good deployments combine identifiers: publisher rules for the vendor stack, hash rules for fixed binaries, and tight control of writable directories so path rules cannot be subverted. Scripts and interpreters need explicit attention, because a permitted scripting host can otherwise run an unapproved script as trusted code.

06Deploying allowlisting without breaking production

The risk in OT is not that allowlisting is too strict in theory. It is that an aggressive rollout blocks a legitimate process and disrupts operations. A staged approach keeps the control safe to deploy.

• Build a clean baseline. Capture the approved software set from a known-good, malware-free host, not a machine that has been in service and possibly tampered with.
• Run in audit or monitor mode first. Log what would have been blocked, review it against the real workload, and refine rules before enforcing.
• Enforce per host group. Start with the most stable hosts, such as historians, before moving to engineering workstations that change more often.
• Tie updates to change management. Every approved software change should update the allowlist through the same controlled process that approves the change itself.
• Protect the ruleset. Restrict who can modify policy, log every change, and ensure the agent cannot be silently disabled by a local user.

Most operational failures come from skipping the audit phase or from leaving a writable, trusted directory that turns the allowlist into a checkbox. Treat the baseline and the change process as the real project; the software agent is the easy part.

07How it maps to standards and compliance

Allowlisting is well supported across the major OT and IT security frameworks, which helps when justifying the control to auditors and management.

NIST SP 800-167

The Guide to Application Whitelisting is the dedicated reference for planning, baselining and operating the control. It is the primary technical source for any program.

NIST SP 800-82 Rev. 3

Recommends application allowlisting as an OT host hardening control and frames it within an ICS-specific risk context.

NIST SP 800-53

Control CM-7 (Least Functionality) covers authorized-software enforcement and deny-by-default execution policies.

ISA/IEC 62443-3-3

System requirements such as SR 2.4 (mobile code) and malicious-code protection align with restricting which software may execute in a zone.

NERC CIP

For bulk electric system cyber assets, allowlisting supports CIP-007 system security management and CIP-010 baseline and change-monitoring obligations.

Because allowlisting produces a defined, auditable inventory of permitted software, it also feeds configuration and change-monitoring requirements. The same baseline that enforces execution doubles as evidence of what is supposed to be on the host.

08Common pitfalls and how allowlisting fails

Allowlisting is a strong control that fails quietly when it is configured for convenience instead of security. The most common weaknesses are predictable and avoidable.

• Baselining a dirty host, which approves malware that was already present and turns the allowlist into a permanent blind spot.
• Over-broad path rules that trust an entire writable directory, letting an attacker drop and run code from a permitted location.
• Permitting interpreters without controlling their input, so PowerShell, cmd, Python or VBScript run unapproved scripts as trusted processes.
• Trusting a publisher too broadly, which approves every tool that vendor has ever signed, including ones the host never needs.
• Leaving the agent disableable or the policy editable by local operators, so a foothold simply turns the control off.
• Allowing it to drift, where temporary exceptions for a maintenance window are never removed and the list slowly loses meaning.

An allowlist is only as trustworthy as the baseline it was built from and the discipline that maintains it. A stale or over-permissive list provides false assurance, which is worse than knowing the host is unprotected.

09Allowlisting controls execution, not delivery

Allowlisting decides what runs once a file is on the host. It does nothing about how that file arrived. An attacker who can repeatedly reach the host over the network has many attempts to find a fileless technique, a trusted-binary abuse, or a misconfigured rule. Reducing the number of ways code can be delivered shrinks that opportunity.

This is where host hardening and network architecture reinforce each other. Segmentation limits which systems can talk to an OT host at all. Where data only needs to leave the protected environment, a one-way path removes the inbound route entirely, so a compromised IT or cloud side has no network channel to push a payload back to the engineering workstation or historian.

For teams designing these boundaries, an AIRGAPNET one-way transfer pattern can sit alongside allowlisting and segmentation: the host enforces what may execute, while the boundary removes the bidirectional reachability an attacker would otherwise use to deliver and control malicious code. Neither control replaces the other.

10Where allowlisting sits in defense in depth

Allowlisting is one layer, not a strategy. It is strongest when it complements controls that address the parts of the risk it cannot touch.

Asset inventory

You cannot allowlist hosts you do not know about. Inventory defines the scope of the program.

Removable-media control

USB scanning and kiosks reduce the most common delivery path for code that allowlisting would later have to block at execution.

Network monitoring

Detection catches the activity that runs inside already-trusted software, which allowlisting will not flag.

Backup and recovery

If a host is compromised through a path allowlisting does not cover, tested recovery limits the consequence.

The honest framing is that allowlisting removes a large class of execution-based attacks cheaply and reliably on stable OT hosts. It does not remove the need for inventory, monitoring, segmentation, controlled transfer and recovery. Each layer covers a different gap.

11Closing thought

Application allowlisting is one of the few security controls that gets easier in OT than in IT. The same stability that makes industrial hosts hard to patch makes them easy to allowlist, because the trusted software set rarely changes.

Get the baseline clean, tie the list to change management, protect the rules, and decide deliberately how files are allowed to reach the host in the first place. Allowlisting controls what runs; segmentation and one-way transfer control what can ever get there. Used together, they make a critical host both predictable and hard to abuse.

FAQFrequently asked questions

SRCSources of record