Engineering and network security: the missing link in cyber-physical risk management
Professor Ross Anderson stated in his seminal book, Security Engineering: A Guide to Building Dependable Distributed Systems, that security engineering is about building systems that remain dependable in the face of malice, error or mischance. The limited integration of cybersecurity and engineering disciplines creates a critical gap: the ability to limit consequences when cyberattacks succeed or when non-malicious failures occur. That is, organizations must not only focus on preventing compromise; they must also understand and limit the consequences when compromises occur.
Moreover, not all control system cyber incidents involve compromising Ethernet networks. Physics-based attacks such as the Aurora generator attack manipulate physical equipment through legitimate control pathways and may involve no malware at all. Cyber risk is commonly expressed as the combination of likelihood and consequence. If the potential physical consequences are not understood, control system cyber risk cannot be accurately assessed. Until this knowledge gap is addressed through collaboration between engineering and network security disciplines, critical infrastructure cannot be fully cybersecure or safe.
Why the culture gap exists
Dr. Darrell Eilts, CIO of the Sewage and Water Board of New Orleans, and I published our paper, "Packets and Process: What Network Security and Engineering Get Wrong About Each Other," in the June 2026 issue of IEEE Computer magazine. Rather than focusing on IT/OT convergence, the paper addresses a more fundamental challenge: the need for meaningful collaboration between engineering and network security. Dr. Eilts explains why network security professionals often struggle to engage with engineering disciplines, while I examine why engineers are frequently reluctant to engage with cybersecurity organizations.
Examples of the OT cybersecurity knowledge gap:
- Recent discussions within the OT cybersecurity community have suggested that distinctions between OT, ICS, CPS, ACS, IACS and SCADA are largely semantic and that experienced IT cybersecurity professionals can transition to OT cybersecurity in a relatively short period of time. While these perspectives are increasingly common, they may underestimate the engineering knowledge required to understand process dynamics, instrumentation, safety systems and control-system behavior. Additionally, discussions of Modbus, CANBus, DNP3, GOOSE and other control-system protocols frequently focus on the vulnerabilities of the protocols. Far less attention is given to understanding the safety, reliability, environmental and production consequences that could result if those compromises occur. Vulnerabilities alone do not define cyber risk; consequences must also be understood.
- Network cybersecurity (IT and OT) and control system organizations have fundamentally different objectives and criteria when it comes to identifying and addressing cyber incidents. Several OT cybersecurity reports have concluded that most OT incidents originate in IT environments. While such findings may be valid within their methodologies, those methodologies often define OT incidents through a network-security lens whereas hundreds of catastrophic control system incidents have occurred that do not involve Ethernet networks. When cyber incidents are defined primarily through a network-security lens, entire classes of control-system incidents can disappear from view. The issue is ultimately one of governance and risk management, not terminology. As New Jersey Transit CISO Rafi Khan observed, network-centric monitoring provides valuable visibility, but it cannot detect every type of operational incident. Sensor-level compromises, serial communications manipulation, analog instrumentation issues and physics-based attacks may occur outside Ethernet-based monitoring architectures. Consequently, some of the most consequential incidents may remain invisible to traditional network-security tools. The March 23, 2005, BP Texas City refinery explosion illustrates how erroneous process measurements and instrumentation failures can create catastrophic consequences that are invisible to traditional network-security monitoring. Neither firewall logs nor network monitoring systems would have identified the faulty level indication that contributed to incorrect operator decisions. Understanding the significance of the failure required engineering knowledge of the process itself. Although BP Texas City was not a cyberattack, it illustrates the broader principle that catastrophic operational failures can arise from erroneous process information that is invisible to network-security monitoring. This case also reinforces Professor Anderson’s thesis that security engineering needs to address error and mischance as well as malicious acts.
Get your subscription to Control's tri-weekly newsletter.
- On May 22, 2026, the Office of Management and Budget issued M-26-14, a Memorandum to the Heads of Executive Departments and Agencies, “Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats.” The memorandum appropriately emphasizes logging and network visibility. However, visibility into network activity does not necessarily provide visibility into process safety, equipment condition or operational consequences. Agencies operating dams, electric systems, water infrastructure and other cyber-physical assets require both cybersecurity monitoring and engineering-based consequence analysis.
Unaddressed engineering issues
Engineers routinely evaluate failure modes, process hazards, equipment tolerances, operating envelopes and consequence mitigation. These disciplines provide the context necessary to determine whether a compromised sensor, controller, actuator or algorithm could create safety, environmental, reliability or production impacts. Without that understanding, cybersecurity assessments can identify vulnerabilities without understanding their true significance. This applies to all types of operational facilities – industrial, manufacturing, buildings, transportation, healthcare, etc.
Sinclair Koelemij argues in his LinkedIn article, “After the Firewall Fails: Designing Process Automation for Cyber-Physical Resilience”, the critical question is not only how to prevent intrusions but also how to limit damage after preventive measures fail. His observation highlights a fundamental limitation of network-centric security approaches: Preventing intrusion is important, but resilience also requires understanding and mitigating the physical consequences of successful attacks or unintentional incidents.
Summary
Although control systems increasingly employ standard IT networking technologies, they differ fundamentally in that they directly monitor and control physical processes. Network security technologies are essential for reducing the likelihood of compromise.
However, they are not sufficient to address the consequences of cyberattacks, equipment failures, sensor malfunctions or engineering errors once they occur. Engineering disciplines focus on understanding and managing physical consequences. Cybersecurity disciplines focus on preventing compromise, detecting malicious activity and responding to threats. Critical infrastructure requires both perspectives.
Until engineering and network security organizations develop genuine collaboration around cyber-physical consequences, not merely network convergence, critical infrastructure operators will continue to face significant blind spots in their ability to secure, operate and defend essential systems and to accurately assess cyber risk. Cybersecurity reduces the likelihood of compromise. Engineering reduces the consequences of failure. Effective cyber-physical risk management requires both.
About the Author
Joe Weiss
Cybersecurity Contributor
Joe Weiss P.E., CISM, is managing partner of Applied Control Solutions, LLC, in Cupertino, CA. Formerly of KEMA and EPRI, Joe is an international authority on cybersecurity. You can contact him at [email protected]

Leaders relevant to this article:
