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.

Best Practice 6: Implement Secure Remote Access

Remote access to SCADA systems surged during and after the COVID-19 pandemic, and it introduced significant security risk. The Colonial Pipeline attack in 2021 originated through a compromised VPN credential. Secure remote access for SCADA environments requires a different approach to enterprise remote access:

  • Never allow direct VPN termination into the OT network: All remote access should terminate in a DMZ jump server. The vendor or engineer connects to the jump server, then accesses the SCADA system through a controlled connection from the DMZ. The OT network itself is never directly reachable from the internet.
  • Multi-factor authentication for all remote sessions: Passwords alone are insufficient. Hardware tokens, authenticator apps, or smartcards must be required for all remote access accounts. This is non-negotiable for any SCADA access from outside the plant network.
  • Session recording: Record all remote access sessions and retain recordings for a defined period (90 days minimum). Session recordings are valuable for incident investigation and vendor accountability.
  • Time-limited access: Remote access sessions for vendors and contractors should be time-limited (active only during the maintenance window) and revoked immediately after the work is complete. Permanent “always on” vendor VPNs are a persistent vulnerability.

Best Practice 7: Maintain a SCADA-Specific Incident Response Plan

Standard IT incident response plans do not account for the operational constraints of SCADA environments. A SCADA-specific incident response plan addresses:

  • Isolation decisions: When should a compromised SCADA server be isolated from the network, and what happens to plant operations when it is? The plan must specify which disconnections are safe and which would cause loss of control.
  • Safe fallback modes: If the SCADA system is taken offline, what are the manual operating procedures? Are operators trained and current on manual operation? Are process values still visible through local field instrumentation?
  • Communication protocols: Who is notified internally and externally? Regulatory reporting timelines (NERC CIP-008 requires notification to E-ISAC within one hour for certain incidents) must be built into the plan.
  • Forensic preservation: How will SCADA logs, historian data, and network captures be preserved for incident analysis without disrupting ongoing operations?

Conduct tabletop exercises against the incident response plan at least annually. A plan that has never been tested is unreliable under the stress of a real incident.

Building a SCADA Security Culture

Security controls fail when the people operating SCADA systems bypass them for convenience. USB drives get plugged into engineering workstations to move files quickly. Vendor accounts are shared between multiple people because creating individual accounts is inconvenient. Firewall rules are opened “temporarily” and never closed.

Technical controls must be matched by a security culture where engineers and operators understand why the controls exist, not just what the rules are. Security awareness training specific to OT environments — covering phishing, social engineering, physical security, and why SCADA systems are attractive targets — is more effective than generic cybersecurity training that does not resonate with operations staff.

The most secure SCADA environments are those where security is treated as an engineering discipline — designed into the system, tested like any other control function, and maintained with the same rigour as process safety. That cultural shift, more than any technology purchase, is what separates resilient SCADA operators from vulnerable ones.