Application Whitelisting

What is Application Whitelisting?

Application whitelisting (AWL), also called software whitelisting, application allowlisting or application control, is a security measure in which a system may only execute explicitly approved programs, scripts and libraries, and blocks everything else by default. Where Antivirus looks for known malicious code, AWL reverses the principle: only what is on the list may start. The same deny-by-default principle, in its broader sense simply called whitelisting, is also applied to devices and network connections. In OT, application whitelisting is one of the most effective defences against Malware, Ransomware and unauthorised tools on SCADA servers, HMIs, historians and engineering stations.

The US agency CISA puts application whitelisting first in its Seven Steps to Effectively Defend Industrial Control Systems, because the static nature of many OT systems makes them ideal candidates.

🧠 Why is Application Whitelisting important in OT?

An OT workstation runs the same set of applications for years: the SCADA runtime, a historian client, the vendor’s engineering package. That predictability makes a precise allowlist achievable, something that is much harder on an office laptop that gets new software every week. In addition, many OT systems cannot be patched quickly, and an antivirus scan on a real-time system is not always desirable, so a control that stops unknown code is particularly valuable.

In attacks by APT groups using Industroyer (2016) and TRITON (2017), attackers placed their own executables on Windows systems in the OT network. TRITON, for example, was dropped as trilog.exe, disguised as Triconex’s legitimate log viewer, on the engineering workstation of a safety instrumented system. A strict allowlist with hash or signature rules does not let such an unknown file start.

🧱 Which forms of whitelisting exist besides applications?

Whitelisting is a general principle: make a positive list of what is allowed and block the rest. Application whitelisting is the best-known form, but industrial networks apply the same idea at several layers. Together they put Zero Trust and defence in depth into practice.

For network connections, IEC 62443-3-3 system requirement SR 5.2 (zone boundary protection) explicitly asks for deny by default, allow by exception from Security Level 2. An allowlist of connections on the firewall between zones is therefore the network equivalent of application whitelisting. The rest of this article focuses on the application layer, because that is where whitelisting has the most impact on OT workstations and servers.

🔄 What is the difference between whitelisting and antivirus?

Antivirus works with a blocklist (formerly blacklist): a database of signatures of known malware. Anything not recognised is allowed to run. AWL works with an allowlist: anything not recognised is blocked. According to CISA, attackers can circumvent antivirus fairly easily with unique or polymorphic variants, whereas AWL simply does not admit those variants.

The two are not mutually exclusive. CISA and NIST see AWL as a complement within defence in depth, and modern OT endpoint products combine an allowlist with an on-demand antivirus scan.

🔧 How does Application Whitelisting work technically?

An agent, or the operating system itself, checks on every execution attempt whether the file matches a rule in the policy. Attempts that match no rule are blocked and logged. NIST SP 800-167, Guide to Application Whitelisting (October 2015), lists the attributes such a rule can rely on:

CISA recommends path rules only for corporate environments and considers file-name-only rules too weak. In OT, the usual combination is publisher rules for signed vendor software, supplemented by hash rules for unsigned or in-house applications.

A mature solution checks more than .exe files. DLLs, drivers, installers, PowerShell and other scripts must also fall under the policy, otherwise an attacker can still run code through a script or library.

🏭 Which software belongs on the allowlist for each OT system?

Each system gets its own allowlist, kept as small as possible and matched to its function. Software that the function does not need stays off the list, even if it is harmless in itself. This matches the least functionality principle in IEC 62443.

When drawing up the lists, work with operations and the system vendor, so that functions that only run during faults or annual maintenance also make it onto the list.

🛠️ Which tools are used for application whitelisting?

• Windows AppLocker - built into Windows since Windows 7 and Server 2008 R2; rules on publisher, path and hash for executables, scripts, installers, DLLs and packaged apps, managed through Group Policy. Microsoft itself describes AppLocker as a defence-in-depth feature rather than a full security boundary.
• App Control for Business - formerly Windows Defender Application Control (WDAC); Microsoft renamed the feature, but the mechanism is the same. It works at kernel level, can also enforce drivers and is Microsoft’s recommendation for robust protection. Rule levels range from Hash through FilePublisher to PcaCertificate.
• Trellix Application Control - formerly McAfee Application Control. Siemens documents its use in SIMATIC PCS 7 and WinCC environments and tests compatibility per version.
• TXOne StellarProtect (Legacy Mode) - formerly StellarEnforce, part of the Stellar range from Trend Micro spin-off TXOne Networks; trust-list-based application lockdown for legacy and fixed-function OT endpoints.
• Other solutions - such as Carbon Black App Control and the allowlisting features in EDR platforms and OT security suites from vendors.

Preferably choose a product that the vendor of your control system has officially approved. That way, support for your DCS or SCADA installation remains valid.

🧭 How do you implement application whitelisting step by step?

1. Inventory systems and software - use your asset inventory to record per system which applications, services and drivers are needed. Involve the vendor: some programs only run during faults or emergencies.
2. Create a clean baseline - start from a known-good gold image so that no existing malware ends up on the allowlist. Combine this with hardening: remove what is not needed first.
3. Run in audit or learning mode - the solution logs what would be blocked without intervening. Let this run for at least a full production cycle, including maintenance, start-up and backups.
4. Test in a test environment - also exercise rarely used functions and emergency procedures so that nothing is missing.
5. Switch to enforcement - start with less critical systems such as historian clients and engineering stations. For highly critical processes, the ICS-CERT guidance also mentions an alert mode instead of blocking: the user is prompted and decides, so a false positive does not stop the process.
6. Send logs to your SIEM - every blocked attempt is a signal. Thanks to logging, you see both attacks and forgotten software.
7. Protect administration - administrators can change or bypass the allowlist. Apply least privilege and RBAC, and have every change trigger an alert.

🔁 How do you keep the whitelist up to date with patches and changes?

Maintenance on static OT systems is modest but requires discipline. With hash rules, every patch or update must be explicitly added to the allowlist, so include that step in your patch management procedure. Publisher rules automatically cover updates from a trusted, signing vendor, but testing remains necessary.

Link every adjustment to MOC (Management of Change) or change management, so that the allowlist moves with approved changes and becomes part of configuration management. CISA points out that an allowlist thus also serves as a verification tool: what runs must match what has been formally approved. Agree in advance how service engineers use their diagnostic tools, and combine AWL with USB Control to limit software being brought in.

🔐 Which standards and guidelines call for application whitelisting?

In the Netherlands, the Cyberbeveiligingswet (Cybersecurity Act), the Dutch implementation of NIS2 that entered into force on 15 August 2026, requires essential and important entities to take appropriate measures against cyber risks. Application whitelisting is not a literal legal requirement, but it is a common and demonstrable way to meet the malware protection that IEC 62443 and supervisory authorities expect.

⚠️ What are the limitations of application whitelisting?

The Sandworm group showed in October 2022 that the first row is not theoretical. At a Ukrainian energy company, it ran commands via an ISO file using scilc.exe, a legitimate component of the MicroSCADA software that would be on any allowlist. AWL is therefore not a silver bullet, but one layer alongside network segmentation, anomaly detection and monitoring. An overly strict policy without a sound management process can also disrupt production itself.

❓ Frequently asked questions

What is the difference between whitelisting and allowlisting?

Whitelisting and allowlisting mean the same thing: only explicitly approved software, devices or connections are admitted. The UK NCSC switched to the terms allow list and deny list in 2020, and CISA and Microsoft also increasingly speak of allowlisting or application control. NIST SP 800-167 still uses the term application whitelisting.

Is software whitelisting the same as application whitelisting?

Software whitelisting and application whitelisting are two names for the same control: only approved programs, scripts and libraries may run on a system. Vendors also use terms such as application control and application lockdown. Whitelisting on its own is broader and can also cover devices and network connections.

Does application whitelisting replace antivirus?

Application whitelisting does not fully replace antivirus but complements it. AWL blocks unknown code, while antivirus also detects known malware in files that are not executed, such as on a USB stick. On static OT systems where antivirus is hard to maintain, AWL is often the most important malware protection.

Does application whitelisting work on old Windows systems?

Application whitelisting is also available for old Windows versions through specialised OT products such as TXOne StellarProtect in Legacy Mode or Trellix Application Control. AppLocker requires at least Windows 7 and App Control for Business at least Windows 10, so they are not an option for older systems such as Windows XP. Where no agent can run, network segmentation and compensating controls are needed.

Can application whitelisting disrupt a production process?

An overly strict or incomplete whitelisting policy can block a necessary application and thus disrupt the process. That is why an application whitelisting rollout always starts in audit or learning mode and the policy is tested in a test environment, including rarely used functions. Coordination with the control system vendor prevents surprises.

What is the difference between AppLocker and App Control for Business?

AppLocker is an older Windows feature whose rules can be scoped to users or groups and which, according to Microsoft, is a defence-in-depth measure. App Control for Business, formerly WDAC, applies to the whole device, works at kernel level, can also control drivers and is the solution Microsoft recommends for robust application whitelisting. Both have an audit mode for testing a policy first.

📌 In summary

Application whitelisting, also called software whitelisting or allowlisting, lets only explicitly approved software run and blocks everything else, so unknown malware and unauthorised tools get no chance on OT systems. Because OT systems change little, AWL is particularly effective and manageable there. Start in audit mode, combine hash and publisher rules, tie maintenance to patch and change management, and apply the same deny-by-default principle to devices and network connections as one layer of defence in depth.