Application allowlisting is a security control that permits only a fixed, approved set of programs to run on a machine and blocks everything else by default, inverting the usual model of trying to catch known-bad software. In OT, where HMIs and engineering workstations run a small, stable set of applications and often cannot be patched frequently, this deny-by-default approach is a natural and powerful fit. This guide explains how allowlisting works, why it is especially valuable as a compensating control on legacy systems, and how it protects the workstations that operate a SCADA process.
Application Allowlisting in one line: Application allowlisting, sometimes called whitelisting, is a control that defines an explicit list of approved executables and allows only those to run, blocking every other program by default. It is the inverse of antivirus, which tries to identify and block known-bad software; allowlisting instead permits only known-good software and treats everything else as untrusted. In OT it suits HMIs and engineering workstations because they run a small, unchanging set of applications, so a deny-by-default posture rarely gets in the way while stopping unauthorized or malicious code from executing.
Application allowlisting maintains a list of the specific programs approved to run on a system - identified by attributes such as file path, cryptographic hash, or a trusted digital signature - and refuses to execute anything not on that list. When a program tries to start, the allowlisting mechanism checks whether it is approved; if it is, it runs, and if it is not, it is blocked, regardless of whether the program is known to be malicious. The default answer for anything unrecognized is no.
This is the opposite philosophy from traditional antivirus. Antivirus operates on a blocklist model: it tries to recognize known-bad software from signatures and behavior and block those specific threats, allowing everything it does not recognize as bad. That model is always chasing new malware and can be defeated by anything novel enough to not match a signature. Allowlisting flips the burden - instead of enumerating the infinite set of bad programs, it enumerates the finite set of good ones, so a brand-new piece of malware is blocked simply because it is not on the approved list, without anyone needing to have seen it before.
The trade-off is that allowlisting requires knowing and maintaining what is supposed to run. On a general-purpose machine where users install varied software constantly, keeping the list current is a burden and blocked-but-legitimate programs are a frequent annoyance. This is exactly why allowlisting fits OT so well: an HMI or engineering workstation runs a small, well-defined, slowly changing set of applications, so the approved list is short, stable, and easy to maintain, and legitimate work rarely runs into a block.
Much OT equipment runs on old operating systems and software that can no longer be patched, either because vendor support has ended or because any change risks disrupting a validated, safety-relevant configuration. That leaves known vulnerabilities unfixed on machines that cannot simply be updated. A compensating control is a protection you put in place to reduce the risk of a weakness you cannot directly remove, and application allowlisting is one of the strongest available for this situation.
The reason it fits is that many attacks against an unpatched system still depend on getting some unauthorized executable to run - a malware payload, a dropped tool, a modified binary. If the machine only permits its known-good set of applications to execute, that payload is blocked at the moment it tries to run, even though the underlying vulnerability that let it land was never patched. Allowlisting does not fix the hole, but it can prevent the hole from being exploited to run attacker code, which is often what actually matters.
This makes allowlisting particularly valuable precisely where other controls are weakest. A modern, well-patched system has many defenses; a legacy OT workstation stuck on an unsupported platform has few, and cannot easily gain more. Locking that machine to its fixed application set is a way to add meaningful protection without touching the fragile software underneath - no patching, no version changes, just a hard boundary around what is allowed to execute. For systems that must keep running unchanged for years, that is often the most practical strong control available.
The natural targets for allowlisting in a SCADA environment are the HMIs, operator workstations, and engineering workstations that people use to view and control the process. These machines are attractive to attackers because they sit close to the control system and can command it, yet they run a predictable set of software: the HMI or SCADA client, a handful of engineering tools, and the operating system's own components. That predictability is what makes them ideal candidates for a locked-down, approved-only configuration.
In a cloud SCADA deployment such as Merobix, the operator interface is often reached through a browser or a defined client rather than a sprawl of local software, which further narrows what legitimately needs to run on the machine and makes an allowlist even cleaner to define. Whatever the interface, the principle holds: the workstation should run only what it needs to do its job, so that a malicious executable arriving by USB drive, email, or a compromised file has nowhere to run. The smaller and more fixed the legitimate software set, the more effective and less intrusive the allowlist.
Operationally, the main discipline allowlisting imposes is change management - when a legitimate new tool or an update genuinely needs to run, it must be reviewed and added to the list. In OT this is usually a feature rather than a burden, because control-system workstations should not be accumulating new software unnoticed anyway. The allowlist enforces the intended state of the machine, so that any attempt to run something outside the approved set is not just blocked but visible, turning a would-be silent compromise into an obvious, investigable event.
Antivirus uses a blocklist: it tries to recognize known-bad software and block those specific threats, allowing everything it does not identify as malicious. Allowlisting uses the opposite model, permitting only an explicit list of approved programs and blocking everything else by default. That means a brand-new piece of malware is stopped simply because it is not on the approved list, without anyone needing to have seen or signatured it first.
Legacy OT machines often run unsupported software with known vulnerabilities that cannot be fixed without risking a validated configuration. Allowlisting is a compensating control: it does not patch the hole, but because most attacks still need to run some unauthorized executable, blocking anything outside the approved set can prevent that vulnerability from being exploited to run attacker code. It adds strong protection without touching the fragile software underneath.
Rarely, because HMIs and engineering workstations run a small, stable set of applications, so the approved list is short and legitimate work almost never hits a block. The main discipline it adds is change management: when a genuinely new tool or update needs to run, it must be reviewed and added to the list. In OT that is usually welcome, since control-system workstations should not be quietly accumulating new software anyway.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.