SCADA (Supervisory Control and Data Acquisition) systems sit at the intersection of operational technology and information technology – communicating with field devices, aggregating process data, and increasingly connecting to corporate networks and cloud platforms. This architecture makes them high-value targets: compromise a SCADA system and an attacker gains visibility across the entire process, plus potential control of remote field sites. The following five practices are not theoretical – they are operationally proven controls that reduce real attack surface.

1. Network Segmentation and the DMZ

The single most impactful SCADA security control is proper network segmentation. SCADA systems must not be on the same flat network as corporate IT systems, engineering workstations, or the internet. IEC 62443 mandates a zone-and-conduit architecture, with a dedicated OT DMZ (typically at Purdue Level 3.5) controlling all data flows between OT and IT.

In practice this means:

  • A dedicated industrial firewall (Fortinet FortiGate RUGGED, Cisco IR series, or equivalent) at every zone boundary, with allowlisted protocol and port rules – not a default-permit policy with exceptions.
  • All data flows from OT to IT pass through a data diode or unidirectional gateway (Waterfall Security, Owl Cyber Defense) for the highest-criticality systems – physically preventing any return path from IT to OT.
  • SCADA historian servers are placed in the DMZ, not directly in the OT network. IT systems query the historian; they never query SCADA servers directly.
  • Remote access to SCADA systems is exclusively via a hardened jump server in the DMZ, with multi-factor authentication and session recording. No direct inbound VPN tunnels to the OT network.

2. Patch Management for OT/SCADA Environments

OT patch management is fundamentally different from IT patch management. You cannot apply patches on the same Tuesday-cycle schedule when your SCADA server is controlling a continuous chemical process. However, running unpatched systems indefinitely is equally unacceptable – the Stuxnet worm, the Ukrainian power grid attacks, and the Florida water treatment incident all exploited known, patchable vulnerabilities.

The OT patch management approach:

  • Maintain a complete, current asset inventory with operating system, application version, and patch level for every SCADA server, HMI workstation, and historian.
  • Test patches in a staging environment (ideally a replica SCADA environment) before production deployment. Vendor validation is required for ICS application patches – unvalidated patches can break communication drivers.
  • Use planned maintenance windows (turnarounds, planned shutdowns) for major patches requiring system restarts.
  • Where patching is not immediately possible, apply compensating controls: network segmentation to limit exposure, application whitelisting to prevent execution of unauthorised code, and enhanced monitoring for exploitation indicators.

3. Strict Access Control and Least Privilege

SCADA systems frequently suffer from shared accounts, default vendor passwords that were never changed, and operator accounts with administrator privileges. Each represents a direct attack vector.

  • Eliminate default credentials: every SCADA application server, HMI, historian, and network device must have vendor default passwords changed before installation. Document this in your commissioning checklist.
  • Role-based access control (RBAC): operators require read access and set-point changes. Engineers require configuration access. Administrators require system-level access. These roles must be distinct and enforced – not an informal convention.
  • Multi-factor authentication (MFA): for all remote access sessions and for any administrative access to SCADA systems. Software tokens or hardware tokens are acceptable; SMS OTP is not recommended for high-criticality OT access.
  • Privileged access management (PAM): vendor and contractor accounts must be provisioned just-in-time (JIT), time-limited, and revoked immediately upon completion of work. Session recording for all privileged sessions provides audit trail and forensic capability.

4. Application Whitelisting on SCADA Workstations

SCADA HMI workstations and engineering workstations should run only the approved applications required for their specific function – and nothing else. Application whitelisting tools (Microsoft AppLocker, Carbon Black App Control, or vendor-native solutions) block the execution of any binary not on the approved list, neutralising most malware delivery methods including USB-borne malware, phishing-delivered executables, and supply chain attacks.

SCADA workstations are typically static in their application profile – the SCADA client, the operating system, and potentially an antivirus agent. This makes whitelisting operationally feasible in a way that is impractical on general-purpose IT workstations. Implement whitelisting in audit mode first to identify and baseline the legitimate application set, then switch to enforce mode.

5. Continuous Monitoring and Incident Response Planning

Detection is the capability that turns a potential catastrophe into a managed incident. Deploy passive OT network monitoring (Dragos, Claroty, Nozomi, or equivalent) to establish a baseline of normal SCADA communications and alert on anomalies: unauthorised devices, unexpected protocol commands, out-of-hours engineering workstation activity, or known ICS malware signatures.

Equally important is a tested OT incident response plan (IRP). An untested plan is a hypothesis. Key elements of an OT-specific IRP:

  • Pre-defined isolation procedures for SCADA servers and network segments – tested so operators can execute under pressure.
  • Offline backups of SCADA application configurations, historian data, and PLC programs – verified restorable and stored off-network.
  • Clear escalation path from operations team to cybersecurity team to executive leadership – with pre-established communication to regulators and the public if required.
  • Defined recovery time objectives (RTOs) for critical SCADA functions – how long can the plant run in manual mode? What is the maximum acceptable downtime before switching to emergency procedures?

The Bottom Line

SCADA security is not about achieving perfect defence – no system achieves that. It is about raising the cost of attack, compressing attacker dwell time, and ensuring that when an incident occurs, the organisation can detect, contain, and recover faster than the attacker can cause lasting damage. These five practices, implemented systematically, create a security posture that measurably reduces both the probability and the consequence of a successful SCADA attack.