What is Application Control?
Application Control is a security measure that uses predefined rules to decide which programs, scripts, libraries and installers may run on a system, and blocks or records everything else. In OT environments, Application Control stops unauthorised, untrusted or malicious software from starting on systems such as HMIs, engineering stations, historians and SCADA servers. Because these systems run a fixed, predictable set of software and are often hard to patch, Application Control is more effective and easier to manage in OT than on a typical office workstation.
Application Control protects against Malware, Ransomware and unwanted software without relying on signature updates or antivirus detection: whatever is not allowed does not start.
🧠 How does Application Control work?
Application Control steps in at the moment the operating system is about to execute a file. An agent or a built-in operating system feature compares the file against the rules and allows the execution, blocks it or only logs it. There are four modes, which are often combined in practice:
- Allowlisting (whitelisting) - only pre-approved applications may run; anything unknown is blocked by default (deny by default). This is the strongest form and the usual recommendation for OT.
- Denylisting (blacklisting) - specific applications are explicitly forbidden, for example remote access tools, BitTorrent clients, games or commonly abused system tools. Anything not on the list is still allowed, which makes this a supplement rather than a replacement.
- Audit mode - rules are evaluated, but violations are only logged. This shows you which software actually runs before you start blocking.
- User and group rules - some solutions can apply rules per user or per group from Active Directory, so a maintenance engineer may start a diagnostic tool while an operator account may not. This fits with RBAC and, in more advanced products, ABAC.
Application Control is not network access control: authentication through RADIUS or 802.1X decides who may join the network, while Application Control decides what may run on a host. Both belong in a defence-in-depth approach.
🔧 Which attributes does Application Control use to identify software?
A rule has to identify an application unambiguously. The common attributes differ widely in strength and maintenance effort:
| Rule type | How it works | Advantage | Drawback |
|---|---|---|---|
| Hash | Cryptographic fingerprint (e.g. SHA-256) of the exact file | Very precise, cannot be bypassed by renaming | Every update or patch needs a new hash |
| Publisher (certificate) | Vendor’s digital signature, optionally with product name and minimum version | Updates from the same vendor keep working | Trusts everything that vendor signs; stolen certificates get abused |
| Path | Folder or file location, e.g. C:\Program Files\ |
Simple and low maintenance | Weak if users have write access to that folder |
| File name or size | Name or size of the file | Quick to set up | Easy to fake; only useful as an additional attribute |
Stuxnet shows why publisher rules must not be trusted blindly: the worm’s drivers were signed with certificates stolen from Realtek and JMicron. A practical mix is publisher rules for major vendors, hash rules for individual tools and path rules only for folders that ordinary users cannot write to. See also Code Signing.
🏭 How do you apply Application Control to OT systems?
Each OT system has a clear function, so the allowed software per role can stay small:
| OT component | Security risk | Application Control option |
|---|---|---|
| Engineering Station | Installation of unsafe or unlicensed software | Allow only PLC programming tools and the vendor’s engineering software |
| HMI | Unwanted software via USB or downloads | Allow only runtime executables, supplemented by USB Control |
| Historian | External scripts or tools | Allow only database and historian processes |
| SCADA server | Remote code execution via unknown apps | Allow only runtime and communication processes |
| Jump host / remote access | Abuse of administration tools | Allow only approved remote desktop and admin tools |
Blocking USB sticks is strictly speaking device control, not Application Control. The combination is powerful, though: a program that arrives on a USB stick will not start if it is not on the allowlist.
Application Control is a particularly powerful layer of defence in environments with legacy systems and limited patching options, because it blocks new code from running even while the vulnerability itself remains open.
Note that many OT vendors only support tested security software. Siemens, for example, publishes application examples and compatibility lists for PCS 7 and WinCC stating which whitelisting solution has been tested with each software version. Check such a list before installing an agent, or you may lose vendor support.
🔐 Which standards and frameworks call for Application Control?
| Framework | Relevant requirement |
|---|---|
| IEC 62443-3-3 | SR 3.2 Malicious code protection and SR 7.7 Least functionality |
| IEC 62443-4-2 | CR 3.2: protection from malicious code at component level |
| ISO 27001:2022 | Annex A 8.7 (protection against malware) and 8.19 (installation of software on operational systems) |
| NIST SP 800-53 Rev. 5 | CM-7(4) deny-by-exception and CM-7(5) allow-by-exception |
| NIST SP 800-167 (2015) | Complete guide to application whitelisting |
| NIST SP 800-82 Rev. 3 | OT security guide that recommends allowlisting for ICS hosts |
| CIS Controls v8 | Safeguards 2.5, 2.6 and 2.7: allowlists for software, libraries and scripts |
| ASD Essential Eight | Application control is one of the eight baseline mitigation strategies |
The Australian Essential Eight model shows how far Application Control can go. At the first maturity level, only approved executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets may run from user profiles and temporary folders on workstations. Higher levels extend this to servers, add Microsoft’s recommended blocklist, require central logging of both allowed and blocked events and an annual validation of the rule set. At the highest level, drivers and Microsoft’s vulnerable driver blocklist are covered as well.
In the Netherlands, the Cyberbeveiligingswet, which entered into force on 15 August 2026 as the Dutch implementation of NIS2, requires appropriate measures against cyber risks. Application Control is not named in the law itself, but it is a demonstrable way to provide the malware protection that IEC 62443 and supervisors expect.
🧭 How do you roll out Application Control step by step?
- Take inventory - record the software each system needs, based on the asset inventory and the vendor’s documentation.
- Choose the mechanism - Windows has AppLocker and App Control for Business (formerly WDAC) built in, managed centrally via Group Policy or Active Directory; for older systems, specialist vendors offer lightweight lockdown agents.
- Start in audit mode - let the rules run for several weeks so that product changeovers, batch closures and maintenance work are also covered.
- Analyse the logs - forward events to central logging or a SIEM and complete the rules.
- Enforce zone by zone - start with engineering stations and jump hosts, then HMIs and servers, with a fallback plan.
- Embed the management - tie rule changes to change management and patch management, so that every update comes with a tested rule change.
⚖️ What are the benefits and limitations?
Benefits:
- Protection against unknown malware - new variants and zero-day malware without a signature are blocked too, because they are not on the allowlist
- Smaller attack surface - insiders and attackers cannot launch their own tools
- More stable systems - no unintended software is added that could disrupt process control
- Suitable for older systems - works without daily signature updates and with little computing power
Limitations:
- No protection inside allowed processes - an exploit in an allowed application or abuse of allowed system tools (Living Off The Land) is not automatically stopped
- Management effort - every update to approved software needs attention to hash, path or certificate
- Risk of disruption - overly strict rules can block a needed tool during an emergency intervention
Combine Application Control with least privilege, hardening, EDR and monitoring through a SIEM.
❓ Frequently asked questions
What is the difference between Application Control and application whitelisting?
Application Control is the umbrella term for all rules that decide which software may run, including denylists, audit mode and user rules. Application whitelisting, also called allowlisting, is the strictest form of Application Control, in which only explicitly approved software may start.
Does Application Control replace antivirus?
Application Control does not fully replace antivirus, but it does make antivirus less critical in OT. Application Control blocks unknown programs up front, while antivirus or EDR can also recognise malicious behaviour and files inside allowed processes. Many OT vendors recommend a combination.
Does Application Control work on old Windows systems?
Yes, with limitations. AppLocker has existed since Windows 7 and Windows Server 2008 R2, and App Control for Business since Windows 10. For older systems such as Windows XP there are separate lockdown agents, which you should align with the OT vendor’s support requirements.
What is Application Control audit mode?
In Application Control audit mode the rules are applied without blocking: every violation is only logged. This shows you which software actually runs, so you can complete the rules before blocking could disrupt a production process.
Can Application Control disrupt a production process?
Yes, if the rules are incomplete, Application Control can block a required program or script. That is why you start in audit mode, test changes on a test system first and keep a documented emergency procedure for adjusting the rules temporarily.
Is Application Control mandatory under IEC 62443?
IEC 62443-3-3 requires protection from malicious code (SR 3.2) and least functionality (SR 7.7), but does not prescribe a specific technology. Application Control is a common and effective way to meet those requirements in OT, especially on systems where antivirus is hard to run.
📌 In summary
Application Control lets only approved software run and blocks everything else, making it one of the most effective measures against malware on HMIs, engineering stations and SCADA servers. With well-chosen hash, publisher or path rules, a start in audit mode and management through change management, Application Control supports compliance with IEC 62443, ISO 27001 and the Dutch Cyberbeveiligingswet, without depending on signature updates.