Control System Integrity in OT Environments: What It Means and How to Maintain It

Industrial facilities run on a fundamental assumption: the control logic executing in their PLCs and distributed control systems is the same logic that was reviewed, validated, and commissioned by their engineers. If that assumption is wrong, every safety interlock, every setpoint limit, and every process shutdown sequence built on top of it is unreliable.

Control system integrity is the property that ensures this assumption holds. It means that the programs running in your control devices, the configurations governing their behavior, and the commands traveling between them have not been modified by an unauthorized party. When integrity is compromised, the consequence is not a data breach. It is a process that behaves differently from how operators believe it is behaving, often without any visible alert.

According to Dragos' 2025 Year in Review, threat actors targeting OT environments specifically seek access to engineering workstations because those are the systems that hold the tools and credentials needed to modify control logic. Unauthorized logic modification has been documented as the objective of some of the most consequential ICS attacks on record, including Stuxnet and TRITON. Understanding what control system integrity means, how it is threatened, and how to maintain it is foundational to any OT security program.

 

What Control System Integrity Actually Means

Control system integrity is not a single property. It operates across four distinct layers of the industrial control environment, and each requires different technical controls to protect it.

Logic Integrity: The Control Program

Logic integrity means that the executable program running on a PLC, RTU, or DCS controller is the authorized, validated version that was placed there by the engineering team. PLCs execute their control program scan cycle after scan cycle. If that program has been modified, whether through unauthorized access to the programming port, through a compromised engineering workstation, or through a supply chain attack on a vendor software update, the device will execute the modified logic without any indication to the operator that anything has changed.

Logic integrity is the hardest layer to protect because most legacy PLC platforms have no mechanism to verify the authenticity of a program before executing it. There is no signature check, no hash validation, and no tamper detection built into the firmware.

Configuration Integrity: Settings and Parameters

Beyond the control program itself, OT devices store a wide range of configuration parameters that govern their behavior: setpoints, alarm limits, communication settings, safety function parameters, and device-level access controls. These configurations are often stored in a mix of engineering project files, device memory, and historian databases, and they drift over time as operators make adjustments, vendors update settings during maintenance, and undocumented changes accumulate.

Configuration drift is one of the most common and underappreciated integrity threats in OT environments. A compressor station SCADA system whose alarm limits have been incrementally adjusted upward over several years may no longer trigger shutdowns at the correct process values, without any single change being large enough to trigger formal change management review.

Communications Integrity: Data in Transit

Industrial protocols such as Modbus, DNP3, and EtherNet/IP were designed for reliability, not for security. Most legacy implementations have no authentication or integrity checking on the commands transmitted between devices. An attacker who can reach the network segment carrying these communications can send forged commands directly to field devices without compromising the engineering workstation or the SCADA server. This is the attack pathway that the Ukraine power grid malware used: it spoke native industrial protocols to substations, bypassing the need to compromise the supervisory control layer.

Physical and Firmware Integrity

The firmware running on OT devices defines what the device is capable of and how it behaves at the lowest level. Unauthorized firmware modification, which Stuxnet demonstrated is achievable, can give an attacker the ability to control device behavior at a level that no application-layer security control can detect or prevent. Physical access controls and supply chain security for OT device procurement are the primary defenses at this layer.

 

How Control System Integrity Gets Compromised

Unauthorized Logic Modification via Engineering Workstations

Engineering workstations are the highest-value target in most OT environments. They hold the vendor engineering software, the active project files, and the programming credentials needed to read from and write to every control device in the facility. A threat actor who compromises an engineering workstation, whether through a phishing attack on the engineer's IT account, through a vendor remote access session, or through a USB-based infection, gains the capability to modify PLC logic without leaving any trace in the OT network traffic. This is one of the most common and effective ICS attack vectors documented by industrial cybersecurity researchers.

Supply Chain Attacks on Vendor Software

OT vendors regularly release updates to engineering software, HMI applications, and PLC firmware. The update mechanism is a potential integrity threat if the vendor's software distribution is compromised or if the organization does not verify update authenticity before deployment. The 2020 SolarWinds attack, which used a trojanized software update to compromise thousands of organizations, demonstrated that this attack pathway is viable at scale. OT environments are not immune.

Configuration Drift Through Undocumented Changes

Not all integrity threats are deliberate. Configuration drift, the accumulation of undocumented changes made by operators, vendors, and maintenance personnel, is an integrity problem that compounds over time. A plant running a DCS that has not been formally audited against its baseline configuration in three years has unknown integrity. The control system is running, but whether it is running exactly as designed is an open question.

Protocol-Level Command Injection

On flat OT networks without segmentation, an attacker who gains access to any device on the industrial network can potentially send forged commands to PLCs, RTUs, and other field devices using the same protocols that those devices expect. Because most legacy OT protocols have no authentication, the receiving device cannot distinguish a legitimate command from a forged one. Network segmentation that controls which devices can reach critical control assets is the primary network-level defense against this attack class.

 

Why Integrity Is Harder to Maintain in OT Than in IT

IT environments use code signing, file integrity monitoring, endpoint detection, and hash-based verification to maintain software integrity across managed devices. Most of these tools cannot be deployed in OT environments without operational risk.

• Endpoint detection agents installed on PLCs and DCS controllers can consume processor cycles that the device needs for its real-time control scan.
• File integrity monitoring that reads device memory can interfere with communications timing on legacy embedded platforms.
• Most OT devices run proprietary operating systems or firmware that do not support the endpoint security agents available for Windows and Linux.
• Firmware hash verification requires the vendor to publish signed hash values for each firmware version, and many legacy OT vendors do not provide this.

 

Key constraint: Many legacy PLCs and DCS platforms offer no native integrity verification capability. The security program cannot rely on device-level detection. It must detect integrity threats at the network level, through access controls that limit who can reach the programming interface, and through change management processes that catch unauthorized modifications before they propagate to production.

 

Controls That Protect Control System Integrity

Formal Change Management for All OT Modifications

Every change to a control system, whether a logic update, a configuration adjustment, a firmware upgrade, or a setpoint change, should pass through a documented authorization process. This means a change request, a technical review, a test on a staging environment if available, an operational impact assessment, and a post-change verification. Linking OT security into the management of change process is the most effective single control for maintaining logic and configuration integrity over time.

Baseline Configuration Management

A baseline configuration is a documented, validated snapshot of the authorized state of an OT device: the firmware version, the software version, the control program hash if available, and the key configuration parameters. Baseline configuration management means capturing this state formally, protecting the baseline records from modification, and using them to detect drift. OT backup and recovery programs that capture regular snapshots of PLC project files and DCS configurations serve a dual purpose: they provide a recovery point after an incident and a reference state against which drift can be detected.

Restricting Access to the Engineering Workstation and Programming Interface

If unauthorized logic modification requires access to engineering software and programming credentials, then protecting that access is the most direct integrity control available. OT system hardening for engineering workstations covers full disk encryption, restricted network access to only the devices the workstation needs to reach, application whitelisting, and session logging. For the programming interface on the PLC itself, network access controls that restrict which source IP addresses can connect to the programming port remove a significant portion of the remote attack surface.

Passive Network Monitoring for Unauthorized Commands

Passive monitoring of industrial network traffic detects when programming connections are initiated, when firmware download commands are sent to PLCs, and when protocol-level commands occur outside of normal operational patterns. This does not prevent unauthorized modification, but it detects it in near real time. Combined with alerting that notifies the security team when a programming event occurs outside a scheduled maintenance window, passive monitoring provides the detection layer that device-level integrity controls cannot. OT vulnerability assessment typically includes passive traffic analysis that establishes a baseline of normal communication patterns.

IEC 62443 Requirements for System Integrity

IEC 62443-3-3 includes system integrity as a foundational security requirement category. SR 3.1 requires communication integrity controls: protection against unauthorized modification of data in transit. SR 3.2 requires malicious code protection. SR 3.3 requires security functionality verification after updates. These requirements map directly to the controls described above. For organizations using IEC 62443 as their OT security framework, the integrity requirements provide the compliance structure for a control system integrity program.

 

Which Environments Carry the Highest Integrity Risk

 

Environment Type	Primary Integrity Risk	Highest-Priority Control
Legacy PLCs with no authentication	Anyone reaching the programming port can modify the logic	Network access control limiting which devices can reach the programming interface
Continuous process DCS (refinery, chemical)	Configuration drift over long turnaround cycles; historian connections as an entry pathway	Formal change management; baseline audit at each turnaround
Remote field sites with vendor access	Vendor credentials used to make undocumented changes during maintenance	Session recording for all vendor remote access; post-maintenance verification against baseline
Safety instrumented systems	Logic or bypass modification disables safety function without operator awareness	Strict network isolation of SIS network; IEC 61511 and IEC 62443 dual compliance
Multi-vendor environments after upgrades	New integrations create unvalidated communication paths	Post-change integrity verification; updated zone architecture review

 

Frequently Asked Questions

How do we know if our PLC logic has been tampered with?

The most reliable detection method is comparing the current program on the device against the last authorized backup using vendor engineering software. Reading the program from the device and comparing it to the baseline project file will reveal any differences. This comparison should be part of your pre-startup checklist after any maintenance window where vendor or external personnel had access to the engineering workstation or programming interface. Passive network monitoring that logs all programming events is the continuous detection mechanism between audits.

 

Does IEC 62443 require control system integrity verification?

Yes. IEC 62443-3-3 System Requirement 3.1 specifically requires communication integrity protections for information passing across conduits between security zones. SR 3.3 requires the capability to verify correct operation of security functions after changes. These requirements apply to the system as a whole, which means the zone architecture, the network controls protecting programming interfaces, and the change management process for logic modifications all contribute to meeting IEC 62443 integrity requirements.

 

How often should we audit control system configurations against the baseline?

For high-criticality systems such as safety instrumented systems and primary process control PLCs, configuration verification should be performed at every planned maintenance window. For lower-criticality systems, annual audits are the minimum. Any unplanned shutdown or incident that required vendor access should trigger an integrity check of the affected devices before they are returned to normal operation.

 

Our DCS vendor released a firmware update. How do we verify its integrity before deploying it?

Request a signed hash or checksum from the vendor for the update package and verify it matches before installation. If the vendor does not provide hash verification, contact your vendor account representative and request it as a formal security requirement. Before deploying any firmware update to a production system, test it in a staging environment or on a spare device of the same model and verify that the control behavior matches the expected post-update specification.