SCADA security: a practical guide for industrial environments

SCADA operations depend on recoverable servers and workstations as well as protected networks and controllers. A failed supervisory host can extend downtime even when field control remains intact. This guide maps the complete SCADA security stack and shows where PC-based backup and recovery fit without presenting Acronis as a SCADA network security platform.

For broader OT and ICS foundations, see Acronis' OT and ICS cybersecurity guide. This SCADA-specific companion focuses on supervisory architecture, incident patterns, control ownership, sector requirements and recovery. 

Key takeawaysSCADA security requires complementary network, access, host and recovery controls.Specialist OT-network controls primarily address asset discovery, industrial monitoring, segmentation and secure remote access.Acronis supports backup and recovery for supported PC-based SCADA and OT systems, with applicable host-level security capabilities depending on the edition, operating system and configuration. It does not replace process-aware network monitoring.Recoverability must be demonstrated through protected copies, documented dependencies and approved restore tests.

Quick definition: SCADA securitySCADA security protects the supervisory systems, operator interfaces, communications paths, field relationships and supporting PC-based systems used to monitor and control distributed physical processes while preserving safety, availability, reliability and timing. 

Scope boundaryIn this guide, Acronis is positioned at the supported PC-based workstation and server layer. It does not provide controller-native PLC or RTU inventory, industrial-protocol asset discovery, process-aware traffic analysis, segmentation enforcement or secure remote-access brokering.

SCADA security protects supervisory servers, human-machine interfaces, engineering workstations, communication paths, remote-access mechanisms and field-system relationships used to monitor and control distributed industrial processes. It combines governance, architecture, access control, process-aware monitoring, host protection and tested recovery while preserving safety, availability, reliability and timing. Different control categories address different parts of this operational and cyber-resilience stack across industrial environments today.

This is broader than SCADA network security. The security of SCADA systems also depends on engineering governance, account control, endpoint hardening, configuration integrity, process safeguards and recoverability. SCADA cyber security and ICS/SCADA cyber security are closely related, but SCADA is a specific supervisory architecture within the broader ICS and OT domain. It is distinguished by centralized supervision and data acquisition across dispersed field locations. 

SCADA systems separate local process control from centralized supervision. Programmable logic controllers (PLCs) and remote terminal units (RTUs) interact with instrumentation at field sites, while the master terminal unit (MTU) or control server aggregates telemetry, presents system state through human-machine interfaces (HMIs) and issues supervisory commands across the communications layer. 

• PLCs execute local control logic against process inputs and outputs.
• RTUs collect remote telemetry, support local functions and exchange commands with the supervisory system.
• The MTU or SCADA server performs centralized supervisory processing.
• HMIs present alarms, trends, process state and permitted operator commands.
• The communications layer carries telemetry and commands across serial, routed, radio, cellular, satellite or other links.

Modbus, DNP3 and similar protocols reflect requirements for dependable, deterministic communication and long-lived interoperability. They are not engineering failures. Where a deployment lacks native authentication, encryption or message integrity, compensate through exposure reduction, zones and conduits, controlled access and process-aware monitoring. Validate added controls against latency, availability and fail-state requirements before deployment. 

The main SCADA security threats are unauthorized remote access, exposed control interfaces, abuse of legitimate industrial commands, compromise of supervisory hosts and indirect operational disruption from connected IT services. The examples below illustrate different failure modes, not one generic attack pattern.

Oldsmar, 2021: Authorities reported that an operator saw remote access and a sodium hydroxide setting change, then immediately reversed it. Treatment was unaffected. CISA now states that the FBI could not confirm a targeted cyber intrusion. Oldsmar supports access-control and operator-safeguard lessons, not conclusive attribution. 

FrostyGoop, 2024: Dragos verified direct Modbus TCP communication and assessed with moderate confidence that the malware was used in a Ukrainian district-heating disruption. Adversaries sent commands to ENCO controllers and remediation took almost two days. The case shows that valid protocol activity can still be malicious. 

Canadian ICS tampering, disclosed in 2025: The Canadian Cyber Centre and RCMP reported multiple incidents involving internet-accessible ICS, including changed water-pressure values, a manipulated tank gauge and altered grain-silo conditions. The alert describes victims of opportunity and recommends inventory, reduced exposure and protected remote access. 

Colonial Pipeline, 2021: DarkSide ransomware affected Colonial's information technology network. The company disconnected systems used to monitor and control physical pipeline functions, and GAO reported that there was no indication the actors compromised the industrial control systems. This is an IT-to-OT continuity example, not a verified SCADA compromise. 

See the Acronis OT and SCADA threat catalog for additional incident-oriented reading. The claims above remain grounded in government or specialist technical sources.

Different control categories address different parts of the stack. Network visibility observes assets and communications, segmentation restricts paths, secure-access systems govern sessions, host controls protect supported operating systems and backup and recovery restore PC-based supervisory functions.

Evaluate any claimed SCADA security solution by asking which assets it protects, what telemetry it consumes, where it enforces policy, which protocols it understands and what it can restore.

Eight foundational SCADA security practices are authoritative inventory, exposure reduction, defensible segmentation, controlled remote access, process-aware monitoring, risk-based vulnerability management, host hardening and tested recovery. For a broader implementation treatment, see Acronis' eight OT security best practices for industrial environments.

1. Maintain an asset and dependency inventory. Document hardware, software, firmware, roles, communications, locations and recovery priorities. Combine records with passive or otherwise OT-safe discovery.
2. Remove unnecessary internet exposure. Identify public-facing SCADA, HMI, PLC, RTU and remote-access infrastructure, then remove exposure without an approved operational purpose.
3. Engineer zones and conduits. Separate enterprise, DMZ, site operations, supervisory and lower-level control functions. Permit only required flows and document their operational purpose.
4. Broker remote access. Use managed entry points, MFA, named accounts, least privilege, approval and session logging. Revalidate dormant vendor paths and cellular modems.
5. Monitor protocol and process behavior. Baseline expected peers, functions, command direction, configuration changes and process values. Combine network evidence with engineering context.
6. Manage vulnerabilities by operational risk. Test changes against OEM support and process behavior. Use compensating controls where patching cannot be performed safely.
7. Harden PC-based supervisory systems. Enforce least privilege, control removable media, remove unnecessary services after validation and collect security logs outside the host's immediate failure domain.
8. Prove recovery and rehearse response. Protect system images, application data, licenses, engineering files and recovery documentation. Define priorities and dependencies, then test them under approved site, OEM, incident-response and functional-safety procedures.

SCADA requirements vary by sector and jurisdiction. ISA/IEC 62443 and NIST SP 800-82 provide cross-sector structure, while pipelines, covered bulk-power entities and qualifying drinking-water systems face additional standards or laws.

As of Sept. 9, 2026, NIST listed SP 800-82 Rev. 3 as the current final publication and Rev. 4 as an initial preliminary draft issued through a pre-draft call for comments. Proposed Rev. 4 changes should not be treated as final requirements. 

See Acronis' overview of OT cyber resilience and IEC 62443 alignment, but use the standards bodies and regulators above to determine obligations.

Network defenses do not replace the backup and recovery capabilities required to rebuild a failed supervisory host. Recovering a SCADA server, HMI, engineering workstation, historian, I/O server or jump server may require the operating system, applications, drivers, configurations, data, licenses and keys that form its approved state.

NIST SP 1339 recommends integrating OT backups with change management, creating them regularly, testing them and reviewing them during recovery exercises. Historian-consistent protection depends on the platform, database engine and supported backup method, so follow current OEM and application guidance. 

Acronis Cyber Protect for OT protects supported PC-based OT systems, while Acronis Cyber Protect Local provides the on-premises deployment option for local, restricted or air-gapped environments.

Where Acronis fitsSupport backup and recovery for supported PC-based SCADA, HMI, historian, engineering and related Windows or Linux systems.Protect complete system images, applications, configurations and data.Support locally managed backup and recovery in appropriately configured offline or air-gapped environments.Support recovery to replacement hardware through Universal Restore where applicable.Enable operator-led recovery by authorized personnel under approved site procedures.Applicable host-level security capabilities depend on the edition, operating system and configuration. Acronis does not replace industrial-protocol asset discovery, process-aware network monitoring, segmentation or secure remote-access systems.

The solution supports full-image and file-level protection, local storage, long-lifecycle Windows and Linux environments subject to the current support matrix and recovery to different hardware through Universal Restore where applicable. Depending on the edition, supported operating system and configuration, host-level anti-malware and anti-ransomware capabilities can complement backup. They do not detect malicious industrial commands or replace SCADA network monitoring. 

Acronis One-Click Recovery is a current capability name for an authorized local operator initiating a predefined workflow. It is not a promise that every restoration takes one click or meets a fixed recovery time. Recovery validation and return to service remain subject to approved site, OEM, incident-response and functional-safety procedures. 

Supported architectures can use immutable storage options, but immutability depends on storage, identity, management and retention design. It does not prevent source-data exfiltration and is not an air gap. 

Before selecting a backup and recovery platform designed for OT constraints, verify supported systems, OEM requirements, recovery paths, local-operation needs, restore-point validation and authorization. See Acronis' OT backup and recovery guide and air-gapped OT guide for more context.

Build a SCADA security program as a five-step operating cycle: establish ownership, create an authoritative architecture view, reduce exposure, monitor with engineering context and prove recovery. It is an ongoing discipline, not a one-time product deployment.

1. Set governance and consequence criteria. Assign OT and IT owners, define critical processes and document the safety, availability and compliance constraints controls cannot violate.
2. Build the architecture and dependency view. Inventory hosts, controllers, communications, remote paths, third parties, software and restoration dependencies. Validate diagrams against observed flows and plant walkdowns.
3. Reduce exposure and implement layered controls. Remove unnecessary public access, establish zones and conduits, broker remote sessions and deploy specialist visibility where required.
4. Monitor, maintain and respond. Baseline communications and process behavior, govern patches and exceptions by operational risk and exercise incident-response decisions under approved site, OEM and functional-safety procedures.
5. Prove recovery. Protect PC-based supervisory hosts and required configurations, test restoration in nonproduction or otherwise approved conditions and feed lessons from changes and exercises back into inventory, detection and governance.

These questions test ownership, operational compatibility and evidence beyond the controls already covered.

OT should own process consequences and operational acceptance. IT commonly owns enterprise identity, shared infrastructure and parts of endpoint or backup administration. Joint governance should assign an accountable owner to each boundary, remote path, alert and recovery action. 

A vendor may combine controls, but evaluate asset discovery, network detection, segmentation, remote access, workstation protection and recovery separately. Consolidation does not prove equal depth across every layer.

Ask which assets it protects, what telemetry it consumes, where it enforces policy, which protocols it understands and what it can restore. Map each answer to the architecture. 

Only after asset, protocol and process risk are evaluated and the method is tested or approved. Enterprise scanning defaults should not enter a control network without engineering review and change control.

Document the exception, assign an owner and reduce exposure through segmentation, least privilege, allowlisting, removable-media controls, monitoring and a tested system image. Review it periodically. 

Evidence includes copy-integrity checks, documented dependencies, compatible hardware, retained licenses and keys, a successful approved test restore and records of required site and OEM acceptance checks. 

Yes. Air gaps reduce network exposure but not removable-media risk, maintenance error, insider action, hardware failure or temporary connections. Isolated sites still need asset accountability, controlled transfers, monitoring and offline recovery. 

Estimate the cost of OT downtimeQuantifying the operational impact helps teams prioritize recovery investment. Use the Acronis ICS/OT downtime cost calculator to estimate the financial impact of an outage and compare the business case for faster recovery.