The short answer
Server Hardening
Hardening a SCADA server means configuring it so that only what the SCADA needs is present and reachable: unneeded services, roles, and protocols removed or disabled, the host firewall allowing only the ports the application uses from the addresses that need them, application allowlisting so that only approved executables run, removable media controlled, administrative rights separated from daily accounts and from the accounts the application runs under, remote desktop limited to the jump host, logs forwarded to a collector, time synchronized, and antivirus with the exclusions the vendor specifies. The configuration is written down as a baseline derived from the vendor hardening guide and a benchmark such as the CIS benchmarks, applied to every server of that role, tested with the application, and audited against the baseline on a schedule.
Key points
- Start from the vendor hardening guide; it says what the application needs, which is what the benchmark cannot know.
- Remove what is not used: services, roles, protocols, features, sample files, and accounts.
- Host firewall on, with rules for the application ports from the specific addresses that need them.
- Application allowlisting is the single strongest control on a server whose software never changes.
- Separate accounts: daily, administrative, and service, none of them shared and none with more than they need.
- A baseline document and an annual audit against it; hardening decays with every change.
Why servers and not only firewalls
A firewall decides who can reach the server; hardening decides what they can do once they do. A phishing email opened on an engineering workstation, a contractor laptop on the control network, or a vulnerability in a service that was never needed each get past the firewall. On a hardened server the attacker then finds no unnecessary service to exploit, no ability to run their tools because they are not on the allowlist, no local administrator rights on the account they landed in, and logs of what they tried on a collector they cannot reach. Hardening is what limits the damage when the perimeter has already failed, which it will.
The controls
| Control | What it does | Notes |
|---|---|---|
| Baseline from the vendor guide and a benchmark | Defines the configuration for the role | Vendor guide first; benchmark settings that break the application are documented exceptions |
| Minimal installation | No roles, features, or services beyond what the application needs | No web server, no file sharing, no print spooler, no media features unless required |
| Legacy protocols disabled | Removes attack surface | Older file sharing versions, name resolution broadcasts, and similar are common footholds |
| Host firewall | Only the application ports, from the client, controller, and historian addresses | Default deny inbound; outbound restricted where the platform allows |
| Application allowlisting | Only approved executables and scripts run | Audit mode first to build the list; then enforce; the SCADA vendor usually publishes guidance |
| Antivirus with vendor exclusions | Detects known malware | Exclusions for the application directories and database files per the vendor; updates from an internal server |
| Removable media control | Blocks or restricts USB storage | A dedicated scanning station for files that must come in |
| Account separation | Daily, administrative, service, and vendor accounts distinct | No daily use of administrator accounts; service accounts with minimum rights and no interactive login |
| Remote access limited | Remote desktop only from the jump host, with multi-factor upstream | Never directly from the office or the internet |
| Logging forwarded | Security and application logs to a collector off the server | An attacker on the server cannot erase what has already left |
| Time synchronization | Logs and certificates depend on it | From the control network time source |
| Firmware and boot protection | BIOS or UEFI password, secure boot where supported | Prevents booting other media |
| Screen lock and session policy | Locks unattended sessions | Operator consoles use view-only timeout instead, so the display is never lost |
| No internet, no email, no browsing | Removes the most common infection paths | Vendor licensing and updates through a controlled path |
Applying it
- 1
Get the vendor guide
Every major SCADA vendor publishes a hardening or security guide for its product: required ports, services, accounts, antivirus exclusions, allowlisting guidance, and unsupported settings. It is the starting point.
- 2
Choose a benchmark
A recognized configuration benchmark for the operating system, applied at a level appropriate to a control server, with each setting that conflicts with the vendor guide recorded as an exception with its reason.
- 3
Build the baseline
The combined configuration as a document or a configuration script: services, features, firewall rules, policies, accounts, logging, allowlist.
- 4
Apply to a test system
A virtual machine with the application installed. Run the application through its functions: polling, alarms, history, clients, reports, failover. Fix what the baseline broke, and record it.
- 5
Apply to production
One server at a time in a redundant pair, with a snapshot or backup before, and the application tested after.
- 6
Enable allowlisting last
In audit mode for weeks to capture every executable the application and its maintenance use, then in enforcement. Keep the process for adding an approved executable when the vendor issues an update.
- 7
Document and schedule the audit
The baseline, the exceptions, the date applied, and an annual check that the configuration still matches; drift happens with every troubleshooting session.
Keeping it hardened
Servers drift. A vendor engineer enables a service to troubleshoot and does not disable it; an update turns a feature back on; a firewall rule is opened for a test. The baseline is only as good as the last time someone compared the server with it. A configuration audit, by a script that reports differences or by a checklist walked once a year, catches the drift, and the change management process records every deliberate departure so that the audit can tell drift from decision.
Frequently asked questions
- Will hardening break the SCADA?
- It can, which is why the vendor guide exists and the test system comes first. Applied per the vendor guidance and tested, hardening is routine on every major platform. The failures come from applying a generic benchmark blindly to a production server.
- Is antivirus enough without allowlisting?
- No. Antivirus catches known malware and misses new and targeted tools; allowlisting stops anything that is not approved, known or not. A SCADA server runs the same few programs for years, which makes it the ideal candidate for allowlisting. Use both.
- How do vendor updates work under allowlisting?
- The update is approved through change management, the new executables are added to the allowlist, or the allowlisting tool trusts the vendor signature, and the update is applied. The process is written down once and followed each time; it adds an hour to an update and is worth it.
- What about the operator consoles?
- They are hardened too, with the same approach and a kiosk configuration: the client starts at boot, the operator has no access to the operating system, removable media is blocked, and the session times out to view-only rather than locking. Consoles are the machines most people touch and deserve the same attention as the servers.
Related topics
- Patch ManagementApplying updates to SCADA servers and clients without breaking the plant: vendor qualification, a monthly cycle with a test system, priority from the exposed edge inward, backups and rollback, emergency patches, and handling software that cannot be patched.
- User Accounts and RolesWho can do what on the SCADA and how it is enforced: roles from view-only to administrator and their permission matrix, individual accounts including the operator console, service and vendor accounts, same-day offboarding, and the quarterly review.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
- Jump HostsThe one machine every remote session must pass through: what a jump host is, how it is hardened, what it may reach, session recording, the tools it carries, and why a vendor laptop never gets past it.
- SCADA ServersWhat the servers in a SCADA system do and what a utility should expect of them: the I/O, alarm, historian, and client roles, physical versus virtual, redundancy, sizing, placement, backup, patching, licensing, and monitoring.
- Third-Party SoftwareEverything on a control system machine that is not the SCADA: drivers, databases, runtimes, reporting tools, agents, remote support utilities. Why each is an attack surface, the inventory and approved list, rules for installs, and removing what is unused.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.