What is Application Whitelisting?
Application Whitelisting (AWL), also called 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. In OT, this 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, so a control that stops unknown code is particularly valuable.
| Risk without whitelisting | Consequence | Effect of AWL |
|---|---|---|
| Malware via a USB stick or a service engineer’s laptop | Malicious code runs without detection | Unknown executable is blocked |
| Unauthorised tools or scripts | Shadow IT or exploits active on production systems | Only approved tools can start |
| New, unknown malware (Zero-day) | No AV signature, so no blocking | Blocks based on the list, not on a signature |
| Unpatched legacy systems | Known vulnerabilities stay open | Limits what an attacker can launch after exploitation |
| Misuse of legitimate tools (Living Off The Land) | PowerShell or vendor tools used for attacks | Only effective with additional deny rules |
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.
🔄 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.
| Characteristic | Application whitelisting | Antivirus (blocklisting) |
|---|---|---|
| Starting point | Default-deny: only what is on the list is allowed | Default-allow: only block what is known to be bad |
| Updates needed | On software changes and patches | Daily signature updates |
| New malware | Blocked, even without a signature | Often missed until a signature exists |
| Best suited to | Static, fixed-function systems | Dynamic systems, and as an additional layer |
| System load | Low, no periodic full scans | Scans can disturb real-time processes |
| Weakness | Misuse of allowed programs | Unknown and custom malware |
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. NIST SP 800-167, Guide to Application Whitelisting (October 2015), lists the attributes such a rule can rely on:
| Method | How it works | Advantage | Disadvantage |
|---|---|---|---|
| Hash-based | Cryptographic hash (e.g. SHA-256) of each file | Very precise, one exact version | Every patch or update changes the hash |
| Publisher/certificate-based | Publisher’s digital signature via Code Signing | Updates from the same vendor remain allowed | Trusts everything from that publisher; much OT software is unsigned |
| Path-based | Execution only from approved folders | Simple to manage | Can be bypassed if a user can write to that folder |
| File name | Name of the file | Little maintenance | Weak, easy to spoof |
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 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), renamed with Windows 11 24H2. 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, successor to Trend Micro Safe Lock; 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?
- 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.
- 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.
- 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.
- Test in a test environment — also exercise rarely used functions and emergency procedures so that nothing is missing.
- Switch to enforcement — start with less critical systems such as historian clients and engineering stations. For highly critical processes, CISA sometimes advises an alert mode first.
- Send logs to your SIEM — every blocked attempt is a signal. Thanks to logging, you see both attacks and forgotten software.
- Protect administration — administrators can change or bypass the allowlist. Apply least privilege 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 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?
| Framework | What it says about AWL |
|---|---|
| NIST SP 800-167 (2015) | Dedicated guide to planning, selecting and implementing application whitelisting |
| NIST SP 800-82 | OT security guide; lists allowlisting as a control against malware on OT hosts |
| IEC 62443-3-3 SR 3.2 | System requirement Malicious code protection, mandatory from Security Level 1; higher levels add central management and reporting |
| IEC 62443-3-3 SR 7.7 | Least functionality: allow only necessary functions, ports and services |
| IEC 62443-4-2 CR 3.2 | Component requirement: protection from malicious code on hosts and applications |
| CISA Seven Steps | AWL is step 1; according to CISA, implementing all seven strategies would have prevented 98% of the incidents ICS-CERT responded to in 2014–2015 |
| ASD Essential Eight | Application control is the first of the Australian government’s eight baseline mitigations |
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?
| Challenge | Approach |
|---|---|
| Misuse of allowed programs (living off the land) |
Block unneeded built-in tools such as PowerShell, mshta and wmic with
explicit deny rules
|
| Exploits in the memory of allowed processes | Combine with memory protection, EDR and timely patching |
| Scripts, Java and .NET | Include script control in the policy, not just .exe files |
| Attacker with administrative rights | Separate admin accounts and monitor changes to the policy |
| Legacy operating systems without a supported agent | Choose a product for legacy Windows or document compensating controls |
| Many software variants | Use publisher rules with hash rules as a fallback |
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, hardening and monitoring.
❓ Frequently asked questions
What is the difference between whitelisting and allowlisting?
Whitelisting and allowlisting mean the same thing: only explicitly approved software may run. Organisations such as CISA and Microsoft increasingly use the terms allowlisting or application control. NIST SP 800-167 still uses the term application whitelisting.
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 a 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.
How much maintenance does application whitelisting require in OT?
Application whitelisting requires relatively little maintenance in OT, because the software on SCADA servers and HMIs rarely changes. Most of the work lies in the initial inventory and in updating the allowlist for patches and changes. With publisher rules for signed vendor software, that maintenance stays limited.
📌 In summary
Application whitelisting 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 deploy AWL as one layer of defence in depth, alongside segmentation, hardening and monitoring.