Securing SCADA and PLC Systems: Practical Measures Without Production Downtime

TL;DR

SCADA systems and PLC (SPS) can be hardened without stopping production. The key is a step-by-step approach with thorough preparation.
The most important quick wins: Change default passwords, disable unnecessary services, secure remote maintenance access, and back up PLC programs.
Passive network monitoring is the safest way to detect anomalies in OT networks without affecting control systems.
The EU Machinery Regulation 2023/1230 requires from 2027 that safety functions of machines must not be compromisable by digital attacks.
Every measure must be validated beforehand in a test environment or during a planned maintenance window.

Why "Just Secure It" Does Not Work in OT

If you come from the IT world, system hardening is a familiar topic. You install the latest operating system, enable the firewall, disable unnecessary services, install an endpoint protection agent, and set up automatic updates. The whole process takes perhaps an hour per system, and by the next morning everything is done.

In the OT world, this does not work. And for reasons that are not negligence, but deeply rooted in the nature of these systems.

Availability has absolute priority. A PLC that controls a production line must not fail. Not for five minutes, not for one minute. Any intervention that poses even a theoretical risk to availability must be carefully planned and tested.

Vendor dependency. The software on a SCADA server or engineering workstation is certified by the machine manufacturer. If you install a patch that the manufacturer has not approved, the warranty may be voided. If you disable a service that the SCADA software requires, the plant stops.

Real-time requirements. PLC systems operate in cycle times of milliseconds. An additional software agent (antivirus, EDR) can affect this cycle time and thus degrade control quality. In safety-critical applications, this is unacceptable.

Long lifecycles. A PLC runs for 15 to 25 years. During this time, the IT world changes fundamentally multiple times, but the control system in production remains the same. You cannot expect a system from 2010 to be compatible with modern security standards.

None of this means that OT systems must remain unprotected. It means that the approach must be different from IT. Instead of "everything at once and automatically," in OT it means: "step by step, tested, and during planned maintenance windows."

Hardening SCADA Servers

SCADA servers are typically Windows-based systems running the manufacturer's SCADA software (WinCC, iFix, Ignition, Wonderware/AVEVA, etc.). They are particularly exposed because they communicate with both the control systems and provide a graphical interface for operators.

Operating System Hardening

Disable unnecessary services. A SCADA server does not need a print spooler, Bluetooth service, Windows Media Player, or remote desktop printer. Disable everything not required for operating the SCADA software and network communication. But: Create a list of all running services beforehand and verify with the SCADA vendor which ones are required.

Configure the local firewall. The Windows Firewall should be active and only allow the ports that the SCADA software and OT protocols require. Typically these are: the port for communication with the PLCs (e.g., TCP 102 for S7comm, TCP 502 for Modbus TCP, TCP 44818 for EtherNet/IP), the port for the historian connection, and the port for HMI clients.

Disable Autorun. USB drives are a common attack vector in OT environments (Stuxnet was delivered via a USB drive). Disable the autorun function for all removable media. Better yet: Restrict USB access via Group Policy to authorized devices.

AppLocker or Software Restriction Policies. Define a whitelist of programs that are allowed to run on the SCADA server. Everything else is blocked. This is one of the most effective protection mechanisms against malware and does not require a constantly updated antivirus program.

SCADA Software Hardening

Set up user accounts. Many SCADA systems are operated with a single user account, often with administrator privileges. Set up separate accounts: an operator account with restricted rights for normal operations, an engineering account for configuration changes, and an admin account for system administration. The admin account is only used when truly necessary.

Change default passwords. This sounds trivial but is astonishingly often neglected in practice. Change the passwords for: SCADA user accounts, database access (many SCADA systems use SQL Server or PostgreSQL), OPC server configuration, and web interfaces (if present).

Enable audit logging. SCADA systems typically have an audit trail function that logs changes to configuration and parameters. Enable it and forward the logs to a central syslog server (which resides outside the SCADA system so that an attacker cannot manipulate the logs).

Disable unused modules. SCADA platforms are modular. Disable modules you do not need: web server, reporting modules, remote access features, scripting engines.

Securing PLC Systems

Securing PLC systems is more challenging than securing SCADA servers because the options are more limited. PLCs are embedded systems with proprietary firmware and restricted security features. Nevertheless, there are effective measures.

Access Controls

Password protection for programming. Modern PLCs offer the ability to protect access to the control program with a password. Enable this feature. Even though the protection is not as strong as with IT systems (some manufacturers store passwords only as simple hashes), it represents an additional hurdle.

Use the operating mode switch. Many PLCs have a physical operating mode switch (RUN, STOP, PROGRAM). Set the switch to RUN during normal operations. In this position, the control program cannot be changed. An attacker who only has network access cannot change the position of the physical switch.

Access protection via IP whitelisting. Some modern PLCs allow restricting access to specific IP addresses. Only the engineering workstation and the SCADA server should be allowed to communicate with the PLC. Configure this restriction on the PLC itself (not just on the firewall) to achieve a defense-in-depth approach.

Firmware Management

Document firmware versions. Record the current firmware version and the date of the last update for each PLC. Regularly check (at least quarterly) whether the manufacturer has released new firmware versions, and assess whether an update is necessary.

Plan firmware updates. Updates should only be applied during planned maintenance windows. Beforehand: Create a backup of the current control program, read the firmware release notes, check whether known issues exist with your configuration, and contact the manufacturer's support if uncertainties exist.

Verify integrity. Some PLCs support program integrity verification (checksums). Use this feature to ensure that the control program has not been tampered with. Regularly compare the checksum with the documented target value.

Backing Up PLC Programs

Regular backups. Create regular backups of all PLC programs. Store them in a secure location (not on the engineering workstation that sits in the same network). Ideally: Offline backup on a dedicated storage medium kept in a safe.

Version control. Use a version control system for PLC programs. Some engineering tools (such as Siemens TIA Portal) offer integrated versioning features. Alternatively, you can manually manage the project files in a version control system like Git.

Recovery testing. A backup that has never been tested is not a backup. Test at least once a year whether you can restore a PLC from the backup. Preferably with a spare PLC in a test environment, not in live operations.

Securing Maintenance Access

Maintenance access is one of the most critical points in OT security. It is necessary (machine manufacturers and system integrators need access), but it is also one of the most common attack vectors.

Centralization via Jump Server

All remote access to OT systems runs through a dedicated jump server (also called a bastion host) in the Industrial DMZ. The jump server provides:

Centralized authentication with individual user accounts
Multi-factor authentication (password plus token or certificate)
Complete logging of all sessions (ideally session recording)
Time-limited access (access is enabled before the maintenance window and automatically locked afterward)
Network access only to the specific systems that need maintenance (not to the entire OT network)

Vendor Management

For each external maintenance service provider, you document:

Which systems may they access?
Which activities are authorized?
Who is the internal contact person?
How is access enabled and disabled?
How are sessions logged and reviewed?

This vendor management should be integrated into your ISMS. NIS2 explicitly requires securing the supply chain, and maintenance access is a key component of that.

USB Devices and Removable Storage

In many OT environments, updates and configurations are transferred via USB drives (because the systems have no network connection or should not have one). Define a process for the safe handling of USB media:

Use only approved USB drives (labeled, inventoried)
Scan USB drives for malware at a dedicated scanning terminal before use on OT systems
Maintain a transfer log: Who transferred which files to which system, and when?
Securely wipe USB drives after use

Monitoring: Seeing What Happens in the OT Network

Without monitoring, you are blind. You do not know who is accessing your control systems, what communication is occurring, and whether anything unusual is happening. Just as with a logging and monitoring strategy in IT, structured monitoring in OT is the foundation for any effective incident detection.

Passive Network Monitoring

The safest approach for OT monitoring is passive network monitoring. Network traffic is mirrored via a mirror port (SPAN port) on the switch and analyzed by a dedicated analysis system. The analysis system does not send packets into the OT network and does not affect the control systems.

Specialized OT monitoring solutions such as Nozomi Networks, Claroty, Dragos, or Microsoft Defender for IoT can:

Asset Discovery: Automatically identify all devices on the OT network (IP, MAC, manufacturer, firmware version, protocols)
Communication Matrix: Visualize which system communicates with which system and over which protocols
Anomaly Detection: Detect deviations from normal communication patterns (new device, unknown protocol, unusual communication)
Vulnerability Mapping: Map known vulnerabilities (CVEs) to the identified devices and firmware versions
Industrial Protocol Analysis: Analyze OT-specific protocols (Modbus, S7comm, Profinet, EtherNet/IP) at the application layer and detect suspicious commands

What You Should Monitor

Even without specialized OT monitoring software, you can implement basic monitoring:

Firewall logs at zone boundaries. Every firewall between IT and OT, between DMZ and OT, and between different OT zones should generate logs. Blocked connection attempts are particularly interesting: They show whether someone is trying to circumvent the segmentation.

Authentication logs. Log and alert on failed login attempts on SCADA servers, engineering workstations, and jump servers.

Configuration changes. Every change to PLC programs, SCADA configurations, or network devices must be logged. Changes outside planned maintenance windows are always an alarm signal.

Network baselines. Over a period of several weeks, capture which communication patterns are normal in your OT network. Which IP addresses communicate with each other? Over which ports? To what extent? Deviations from this baseline may indicate an incident.

Measures by Priority

Not all measures need to be implemented immediately. Here is a prioritized sequence:

Priority 1: Immediately (possible without a maintenance window)

Measure	Effort	Impact
Change default passwords on HMI and SCADA	Low	High
Inventory remote maintenance access	Low	Medium
Back up PLC programs (backup)	Low	High
Create network diagram	Medium	High
Review and tighten firewall rules between IT and OT	Medium	High

Priority 2: Next maintenance window

Measure	Effort	Impact
Disable unnecessary services on SCADA servers	Medium	Medium
Disable autorun on all OT workstations	Low	Medium
Configure local firewall on SCADA servers	Medium	Medium
Set operating mode switch on PLCs to RUN	Low	Medium
Enable audit logging on SCADA servers	Medium	Medium

Priority 3: Planned (3-6 months)

Measure	Effort	Impact
Set up jump server in DMZ	High	High
Set up passive network monitoring	High	High
Configure AppLocker on SCADA servers	High	High
Set up user management on SCADA systems	Medium	Medium
Develop and implement firmware update strategy	Medium	Medium

Priority 4: Long-term (6-12 months)

Measure	Effort	Impact
Refine network segmentation within the OT zone	High	High
Introduce OT-specific incident response procedure	Medium	High
Regular vulnerability assessments for OT	Medium	Medium
Recovery tests for critical control systems	Medium	High
Integration into SIEM	High	Medium

Incident Response for OT Incidents

Securing SCADA and PLC systems is one side. The other side is the question: What do you do if, despite all measures, an incident occurs?

OT-Specific Incident Response Challenges

In IT, the standard response to a compromise is: Isolate the system, analyze, remediate, bring back into operation. In OT, the first step (isolating) may already cause more damage than the attack itself.

That is why you need an OT-specific incident response plan that addresses the following questions in advance:

Who decides on shutdown? If a SCADA server is compromised, someone must decide whether the affected production line is shut down or whether it continues to run under increased manual supervision. This decision should not be discussed for the first time during the incident. Define the decision criteria and decision-makers in advance.

How does manual operation work? Many production facilities can continue to run in a limited manual mode when automation fails. Operators must know how to initiate manual operation and what limitations apply. Document the procedures for manual emergency operation and practice them regularly.

Where are the offline backups? If the SCADA server is encrypted and the network backup is also compromised, you need an offline backup of the PLC programs and SCADA configurations. Where is it? Who has access? Is it current?

Who can perform the recovery? Restoring a SCADA system or reprogramming a PLC requires specialized knowledge. If your only automation technician is on vacation, you have a problem. Document the recovery steps in enough detail that a qualified technician without specific system knowledge can perform the recovery. And keep the contact details of the machine manufacturer and system integrator current.

Tabletop Exercises for OT Scenarios

At least once a year, you should conduct a tabletop exercise with an OT-specific scenario. Participants should include: IT security, production management, maintenance, executive management, and ideally the machine manufacturer or system integrator.

A good exercise scenario: "Monday morning, 6:30 AM. The shift operator reports that all HMI panels in Hall 2 are showing only a black screen. The machines are still running, but operators have no overview of the process. The SCADA server is unreachable. At the same time, IT reports that several servers in the data center have been encrypted."

Such exercises uncover gaps that are invisible during normal operations: missing contact details, unclear responsibilities, outdated recovery documentation, untested backup media. In the article Planning a Tabletop Exercise, you will find a guide for conducting them.

The Regulatory Framework

Securing SCADA and PLC systems is not only technically sensible but is increasingly required by regulation:

NIS2 demands comprehensive risk management for all network and information systems, which explicitly includes OT systems. The required measures (patch management, access control, incident detection, backup, supply chain security) also apply to SCADA and PLC systems.

The EU Machinery Regulation 2023/1230 requires from 2027 that machines with digital elements must be protected against unauthorized access. Safety functions (emergency stop, protective devices, pressure monitoring) must not be compromisable by digital attacks. This has direct implications for securing the PLCs that execute these safety functions.

IEC 62443 provides the most detailed technical framework for securing industrial automation systems. If you are looking for a structured approach, this standard is the best guide.

In practice, this means: Securing SCADA and PLC systems is no longer optional — it is mandatory. And every measure you implement and document now will help you demonstrate in the next audit that you take the topic seriously. In ISMS Lite, SCADA and PLC systems can be captured with firmware versions, hardening measures, and recovery instructions in a structured manner.