Cybersecurity for Process Control Engineers: What OT Security Means for Your DCS and PLC

The Control Room Is No Longer an Island

For most of the history of industrial automation, process control systems operated in isolation. The DCS ran on a closed, proprietary network. The PLC had no connection to anything outside the plant fence. Cyberattacks were an IT problem — something that happened to office computers and file servers, not to distillation columns and compressor control loops.

That isolation no longer exists. Over the past decade, plants have connected their control systems to corporate networks, cloud-based historians, remote monitoring dashboards, and vendor support platforms. The business case was compelling: faster data access, remote optimization, lower travel costs. The security implications were often an afterthought.

The consequences are now visible in the numbers. In 2025, cybersecurity firm Dragos tracked 119 ransomware groups actively targeting industrial organizations worldwide — a 49% increase in a single year ⁽¹⁾. Manufacturing accounted for more than two-thirds of all victims. The average time ransomware spent undetected inside an OT environment was 42 days ⁽¹⁾. A separate survey of over 700 OT professionals found that 76% had experienced phishing attacks and 50% reported ransomware incidents in the past year ⁽²⁾. These are not theoretical risks. They are happening now, in plants that look very much like yours.

OT Security Is Fundamentally Different from IT Security

The most important thing a process control engineer — or a plant manager — can understand about cybersecurity is that operational technology (OT) security is not the same as IT security. The difference is not technical jargon. It has real, physical consequences.

In IT, the priority is protecting data: keeping it confidential, preventing unauthorized changes, keeping systems available. In OT, the priorities are different: the process must keep running, the equipment must stay safe, and any disruption has physical consequences. You cannot take a DCS controller offline to apply a security patch the way an IT team patches a laptop. Shutting down a running reactor or a pipeline compression station carries its own risk, independent of any cyberattack ⁽³⁾.

This creates three vulnerabilities specific to OT environments:

• Legacy systems — Many DCS and PLC components run on operating systems that are years or decades out of support. They were designed to run for 20–30 years, not to receive weekly security updates.
• Unprotected protocols — Industrial communication protocols like Modbus and DNP3 were built for reliability, not security. They typically have no built-in authentication or encryption, meaning data passes between devices with no verification of who is sending it.
• Limited maintenance windows — A 24/7 continuous process has very few opportunities for security remediation. Patching, configuration changes, and network updates must be carefully planned around production schedules.

The Architecture of Defense: Layers of Separation

The established framework for protecting OT systems is the Purdue Model — a hierarchical architecture that organizes industrial systems into levels, from physical field devices and PLCs at the bottom (Levels 0–1), through supervisory DCS systems (Level 2), plant operations (Level 3), up to corporate IT networks (Levels 4–5), as illustrated in Figure 1 ⁽⁵⁾.

The security principle is straightforward: communication between levels should be controlled, minimal, and deliberate. A vulnerability in the corporate email server should not provide a direct path to a PLC. A compromised remote access account should not reach a DCS controller. The Industrial DMZ — a buffer network between OT and IT, sometimes called Level 3.5 — is the critical boundary that modern plants add to enforce this separation.

_{Figure 1. The Purdue Model for ICS network segmentation, showing Levels 0–5 and the Industrial DMZ. ⁽⁵⁾}

International standard IEC 62443 formalizes this concept into zones (groups of assets with similar security requirements) and conduits (the defined, controlled communication paths between zones). In plain terms: every connection that crosses a network boundary is a conduit – and every conduit needs to be intentional, documented, and as narrow as possible ⁽⁶⁾.

The OPC Layer: Where Data – and Risk — Cross Boundaries

OPC (OLE for Process Control) is the communication standard that most DCS, PLC, historian, and optimization systems use to exchange data. It is the connective tissue of the modern OT network — and it is also one of the most common pathways through which data, and threats, travel across network boundaries.

The older OPC-DA protocol, still widely deployed across process industry plants, was designed for trusted internal networks. It has no built-in encryption or authentication — it assumes the devices it connects to can be trusted by default. The modern standard, OPC-UA, addresses this with security built in. But the reality in most plants is a mixture of both, and many OPC connections cross network zone boundaries without the controls those crossings require ⁽³⁾.

When PiControl engineers use PiBridge — an OPC communication bridge — to connect two systems across a network boundary, such as linking a DCS historian to a corporate data platform or passing online analyzer data into a PLC, that connection is not just a data integration task. It is an architectural decision about what information crosses which network zone, in which direction, and under what conditions. Designing those connections deliberately — with minimal data exposure, defined access, and clear documentation — is the difference between a managed conduit and an unmonitored open door.

Practical Starting Points for Process Engineers and Plant Managers

Neither process engineers nor plant managers need to become cybersecurity specialists. But understanding the basics is enough to ask the right questions, identify the right risks, and push for the right conversations with both IT and operations leadership.

• Audit every external connection into your OT network. List remote vendor access accounts, IT historian feeds, optimization software links, and cloud connections. Many plants discover active connections they had forgotten existed — including old vendor accounts that were never deactivated.
• Require multi-factor authentication on all remote access. The single highest-impact measure most plants can implement immediately. The 2021 Colonial Pipeline shutdown was triggered by a single compromised password on an account with no MFA ⁽⁴⁾.
• Treat anomalous controller behavior as a potential security indicator. Unexpected mode changes, setpoints adjusting without operator input, controllers switching to manual for no process reason — these are not only performance issues. They can be signs of unauthorized access. Process engineers, who know what normal operation looks like, are uniquely positioned to spot them.
• Know your OPC connections and protocols. Understand whether your historian, DCS, and optimization tools communicate via OPC-DA or OPC-UA, and which of those connections cross network zone boundaries without authentication.

Conclusion

OT cybersecurity is not about turning process engineers into IT security professionals. It is about recognizing that the systems they design, commission, tune, and maintain are now active targets — and that the architectural decisions made every day in the control room carry security consequences alongside their performance consequences.

PiControl Solutions is not a cybersecurity company. But with over 20 years of DCS and PLC design, programming, OPC communication, and process control optimization experience across Honeywell, Siemens, Emerson DeltaV, Yokogawa, ABB, and other major platforms, the engineering team understands the architecture of these systems from the inside. Designing OPC connections, building DCS and PLC control schemes, and integrating data flows across network boundaries are engineering activities that, done thoughtfully, contribute to a defensible control architecture – not just a high-performing one.

References

_{1. Dragos, “2026 OT Cybersecurity Year in Review,” Dragos Inc., 2026. www.dragos.com/ot-cybersecurity-year-in-review}

_{2. Fortinet, “2026 State of Operational Technology and Cybersecurity Report,” Fortinet Inc., 2026. www.fortinet.com/resources/reports/state-ot-cybersecurity}

_{3. Corelight, “OT Security: Protecting SCADA, DCS and PLCs from Cyber Threats,” 2025. www.corelight.com/resources/glossary/ot-security.}

_{4. Idaho National Laboratory, “Case Study: DarkSide Ransomware Attack on Colonial Pipeline,” INL/RPT-22-67337, CyOTE Program, 2022. cyote.inl.gov}

_{5. Fortinet, “What Is the Purdue Model for ICS Security?” Fortinet Cyber Glossary, 2025. www.fortinet.com/resources/cyberglossary/purdue-model}

_{6. International Electrotechnical Commission, “IEC 62443 — Security for Industrial Automation and Control Systems,” IEC, Geneva; and National Institute of Standards and Technology, “NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security,” NIST, 2023. csrc.nist.gov/pubs/sp/800/82/r3}