Secure Deployment of Industrial Communication Protocols
Why Cybersecurity Is an Architecture Problem, Not Just a Protocol Problem
Excerpt
Secure Industrial Communication Protocols are essential to modern automation, but many of them were not originally designed with cybersecurity as a primary objective. A secure deployment therefore depends less on the protocol alone and more on the overall risk-based system architecture.
Introduction
Industrial communication protocols are a foundational element of modern automation systems. They enable interoperability, real-time control, diagnostics, device integration, and data exchange across process and factory environments. But there is a structural issue: many widely deployed industrial protocols were not originally designed with cybersecurity as a primary objective.
That point matters because it changes the way security must be approached. The key question is not whether a protocol is “secure” in isolation. The real question is whether the system in which it is deployed reduces risk to an acceptable level.
In other words, industrial cybersecurity is not only a protocol feature set. It is an architecture and risk management discipline.
The central problem: protocol capability and deployment reality are not the same thing
The joint paper from FieldComm Group, ODVA, OPC Foundation, and PI makes a critical distinction between protocol families. It states that non-Ethernet industrial protocols generally lack core security capabilities such as authentication, authorization, integrity, and confidentiality, while Ethernet-based industrial protocols define security protections that include these mechanisms.
The protocols covered in scope include DeviceNet, EtherNet/IP, FOUNDATION Fieldbus, HART 4-20 mA, HART-IP, IO-Link, OPC UA, PROFIBUS PA, PROFINET, and WirelessHART.
This leads to a direct operational conclusion:
- a protocol without built-in security cannot be treated as secure because it is industrial,
- a protocol with native security still requires correct deployment,
- and interoperability requirements do not remove the need for risk treatment.
That is where many industrial projects fail. They confuse communication capability with security assurance.
The correct approach: risk-based deployment
The document explicitly follows a risk-based methodology aligned with EN 40000-1-2. That methodology includes:
- defining the context,
- assessing risk,
- treating risk,
- communicating risk,
- monitoring and reviewing risk.
This is the right framing. You do not secure an industrial protocol in the abstract. You evaluate how that protocol is used:
- in which network,
- between which assets,
- by which users,
- under which physical and operational constraints,
- and with which compensating controls.
That is a much more serious position than the usual marketing simplification of “secure-by-design” protocol claims.
IEC 62443 provides the real industrial framework
The paper also anchors its reasoning in IEC 62443, which it presents as the international framework for cybersecurity in Industrial Automation and Control Systems. IEC 62443 is explicitly lifecycle-oriented and risk-based. It determines the required Security Level for each zone and conduit, then applies the controls necessary to achieve that level using seven foundational requirements.
The document also emphasizes that responsibility is distributed across the supply chain:
- IEC 62443-2-x for asset owners and operators,
- IEC 62443-3-x for system-level requirements,
- IEC 62443-4-x for component and product suppliers.
This is a decisive point. Security is not the sole burden of the product vendor, nor of the plant owner. It is a shared responsibility model.
The zones and conduits concept is especially important. A zone groups assets with common security requirements and trust assumptions. A conduit is the controlled communication path between zones, enforcing the necessary protections at the boundary.
That is the correct mental model for industrial communication security.
Industrial communication protocols operate inside an architectural context
The document explains that these protocols are generally used to connect field devices with control systems in process and factory automation. It distinguishes Ethernet-based protocols such as EtherNet/IP, OPC UA, PROFINET, and HART-IP from non-Ethernet protocols such as HART, IO-Link, FOUNDATION Fieldbus, PROFIBUS, and DeviceNet.
They are typically deployed in industries such as water, food and beverage, power, life sciences, chemical, oil and gas, packaging, robotics, automotive manufacturing, and others. Typical uses include:
- motion control,
- transmission of safety-relevant data,
- equipment configuration,
- diagnostics,
- cyclic real-time data exchange.
The paper further notes that these protocols are typically used at Purdue levels 0 to 2, although Ethernet-based protocols are now often used at higher levels and may even extend toward cloud-connected architectures. It also notes that real-world installations often mix layered segmentation with selective connectivity rather than strictly following one idealized model.
That observation is important because the old assumption of isolated field networks is increasingly false.
Three deployment models define most real-world strategies
The document provides three high-level examples that are more useful than they look.
1. Complete isolation
In the first example, a small industrial network is completely isolated from any larger network. The paper states that this can significantly reduce risk, especially if the network remains small and physical access is tightly controlled. It also makes clear that this model depends heavily on the physical security of the environment.
This is effective, but it is not infinitely scalable. The larger the network becomes, and the more physically extended it is, the harder it is to maintain the conditions that justify the isolation model.
2. Gateway protection
In the second example, non-Ethernet protocol data is exposed to a larger network through a secure gateway. The gateway provides security functionality using mechanisms such as TLS, certificates, confidentiality, and integrity protection for the Ethernet-side communication.
This is a pragmatic model. It allows legacy or non-secure protocol segments to remain constrained while security is enforced at the translation or exposure point.
3. Secure protocol deployment
In the third example, devices use Ethernet-based industrial protocols with built-in security enabled. The document names OPC UA, EtherNet/IP with CIP Security, PROFINET Security, and HART-IP with security as examples. In this case, authentication and data-in-transit protection are provided directly by the protocol stack, allowing deployment across networks with varying trust assumptions. The paper states that this represents the best case for Ethernet-routed industrial communication and can work in a zero-trust enabled environment.
That is the clearest strategic direction in the paper.
Physical security is not optional
One of the most important sections is the one many teams skip: physical security.
The paper explicitly states that industrial protocol deployments depend on physical security and that it is not feasible for industrial protocols to defend against a direct physical attack. It assumes controlled access to the operational environment and mentions measures such as controlled conduits, restricted access to wiring, locked cabinets, and surveillance.
That is not a minor implementation detail. It is a design assumption.
Any cybersecurity argument that ignores physical exposure is incomplete.
What the document actually concludes
The conclusion is direct:
- non-Ethernet industrial protocols lack basic security capabilities,
- Ethernet-based industrial protocols define security protections,
- non-Ethernet protocols should remain isolated in secure networks,
- if their data must be exposed to larger networks, that exposure should go through gateway or translation products where security controls can be enforced,
- Ethernet-based secure protocols can be deployed in a wider variety of environments because they support stronger protections directly.
The paper also states that the market adoption and implementation of industrial Ethernet security capabilities are still evolving. As a result, one practical option for end users is to treat Ethernet industrial protocols without active security functionality the same way as non-Ethernet protocols.
That is a hard but accurate conclusion. A protocol feature existing on paper is irrelevant if it is disabled, unsupported, or not operationally enforced.
Strategic takeaway
The most useful takeaway is this:
Industrial cybersecurity is not solved by choosing a protocol. It is solved by combining protocol capabilities, segmentation, gateways, physical protection, and risk-based architectural decisions.
This shifts the discussion away from simplistic “which protocol is secure?” debates and toward the more serious question:
How should this system be designed so that communication risk is acceptably controlled?
That is the right question for product suppliers, system integrators, plant operators, and assessors alike. The paper even identifies those groups as its intended audience.
Final conclusion
Industrial communication protocols remain essential to modern automation, but they must be deployed according to their actual security properties, not their industrial reputation.
Where native protocol security exists, it should be enabled based on risk assessment. Where it does not exist, the protocol must be isolated, encapsulated, or mediated through secure gateways. And in all cases, physical protection, segmentation, and operational discipline remain necessary.
The real lesson is simple:
Secure industrial communication is a system design problem.