# Industrial Protocol Security
Industrial communication protocols are the languages that operational technology (OT) devices use to exchange commands and data. A programmable logic controller (PLC) receiving a setpoint from a human-machine interface (HMI), a remote terminal unit (RTU) reporting a meter reading to a SCADA master, a building controller adjusting HVAC output in response to temperature data: all of these exchanges happen over specific protocols that define the message format, addressing, and timing.
These protocols were designed in an era when the systems using them were physically isolated. A water treatment plant's SCADA network was connected to a control center and nothing else. A power substation's protection relays communicated over dedicated serial lines. The word "internet" did not appear in the design specifications for Modbus, DNP3, or BACnet because connecting these systems to the internet was unthinkable when the protocols were created. Security properties, authentication to verify who is sending a command, encryption to protect command contents from interception or modification, were either absent by design or considered unnecessary.
That world no longer exists. OT networks are now routinely connected to corporate IT networks for monitoring and efficiency purposes. Remote access for vendors and operators is delivered over IP connections. Cloud-based monitoring platforms aggregate data from field devices. In many cases, OT devices are directly internet-accessible, either intentionally or through misconfiguration. The protocols have not changed to match this new reality. Modbus, designed in 1979, is still the most widely deployed SCADA protocol in the world, still without authentication or encryption.
Industrial protocol security is the discipline of understanding where these protocols fail under adversarial conditions, how attackers exploit those failures, and what mitigations are available to defenders operating in environments where replacing the protocols is often not possible.
Within CDA's Planetary Defense Model, industrial protocol security spans two domains. VSD (Vulnerability and Surface Defense) owns the protocol exposure: the attack surface created by unauthenticated, unencrypted communication channels accessible from IP networks. SPH (Security Posture and Hygiene) owns the operational security practices around those protocols: network segmentation, access control, monitoring, and the ongoing hygiene discipline required to keep OT environments from drifting into an uncontrolled state.
Modbus was developed by Modicon in 1979 as a communication protocol for its PLCs. It is a request-response protocol originally designed for RS-232 and RS-485 serial communication, later extended to TCP/IP as Modbus TCP. A Modbus network has one master and one or more slaves. The master sends requests; slaves respond. Requests read or write four data types: coils (single-bit read-write), discrete inputs (single-bit read-only), holding registers (16-bit read-write), and input registers (16-bit read-only). That is the entire protocol.
Modbus has no authentication. Any device on the network that can send a valid Modbus TCP frame to a device's IP address and port 502 can read any register and write any register the device exposes. There is no username, no password, no certificate, no shared secret. The protocol's designers assumed that only trusted devices would be connected to the network. If an attacker is on the network, the assumption has already failed, and Modbus provides no second line of defense.
Modbus also has no message integrity protection. There is no cryptographic signature or checksum that would allow a receiving device to verify that a command has not been modified in transit. A man-in-the-middle attacker who can intercept Modbus TCP frames can alter them and forward modified versions without any indication of tampering reaching the destination.
Modbus remains dominant because it is simple, reliable, and supported by virtually every OT device on the market. Replacing it requires replacing hardware that may have a 20 to 30 year service life. For most organizations, Modbus stays, and the security work focuses on controlling who can reach Modbus-speaking devices.
DNP3 (Distributed Network Protocol 3) was developed in 1990 by Westronic (later acquired by GE) for electric and water utility communication between control centers and field devices. It is more sophisticated than Modbus: it supports data timestamps, event-driven reporting (devices push data when values change rather than waiting to be polled), and a broader range of data types. DNP3 runs over both serial connections and TCP/IP (DNP3 over TCP port 20000).
Like Modbus, the original DNP3 specification had no authentication. A 2010 revision introduced DNP3 Secure Authentication version 5 (SA v5), which adds HMAC (Hash-based Message Authentication Code)-based authentication to DNP3 messages. SA v5 is a meaningful improvement: it allows field devices to verify that commands come from an authenticated source and have not been tampered with in transit. The problem is deployment. SA v5 requires both the master station and the field device to support it, requires key management infrastructure, and requires configuration. Many deployments, especially older infrastructure, have not upgraded. The result is that DNP3 with no authentication remains in widespread use in electric and water infrastructure.
The Industroyer (also known as CrashOverride) malware, deployed against the Ukrainian power grid in December 2016, included a DNP3 module specifically designed to send DNP3 commands to substation automation systems. Industroyer sent unauthorized commands to open circuit breakers, causing a power outage. The attack was possible because the targeted DNP3 implementations had no authentication.
BACnet (Building Automation and Control Networks) was developed by ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) in 1995 and is the dominant protocol for building automation systems. It controls HVAC equipment, lighting systems, fire alarm systems, and elevator controls. BACnet supports multiple network layers including BACnet/IP (over UDP, typically port 47808) and BACnet MS/TP (master-slave/token-passing over RS-485).
BACnet/IP uses UDP broadcast messages for device discovery and communication. Any device on the network that sends a BACnet Who-Is broadcast will receive responses from all BACnet devices on that network segment, revealing every device and its capabilities. Native BACnet has no authentication; any device can read or write any object on any other device. BACnet/SC (Secure Connect), an extension published in 2020, adds TLS-based security to BACnet communication, but adoption is early and many existing BACnet deployments have no path to upgrade without replacing controllers.
The practical consequence is that buildings using BACnet for HVAC and access control are running unauthenticated, unencrypted control traffic on IP networks, often accessible from the corporate IT network or the internet. The Target breach (described in the Smart Building Cybersecurity article) followed exactly this path.
OPC UA (Unified Architecture) was developed by the OPC Foundation in 2008 as the successor to the original OPC (OLE for Process Control) specifications. Unlike Modbus, DNP3, and BACnet, OPC UA was designed with security as a first-class requirement from the beginning. It supports:
Certificate-based authentication: OPC UA clients and servers exchange X.509 certificates to verify identity before establishing a session.
Message signing: Every OPC UA message can be signed, allowing recipients to verify the message has not been tampered with in transit.
Message encryption: OPC UA messages can be encrypted end-to-end using symmetric keys negotiated during session establishment.
Session management: OPC UA sessions are explicitly established and terminated, with defined timeouts, unlike stateless protocols where any device can send commands at any time.
The security policy defines which combination of these features is required. The strongest policy (Basic256Sha256 with both signing and encryption) provides a security posture comparable to a modern web application using TLS. The weakest policy, "None," disables all security features.
The critical problem with OPC UA in practice is that many deployments set the security policy to "None" for compatibility reasons. Legacy field devices that cannot handle the computational overhead of certificate operations, configuration complexity, and support tool limitations all push operators toward disabling security. An OPC UA deployment with security policy "None" provides none of the protocol's security features and is indistinguishable in risk profile from Modbus.
EtherNet/IP (Ethernet Industrial Protocol) was developed by Allen-Bradley (Rockwell Automation) and is widely used in manufacturing automation. It carries the CIP (Common Industrial Protocol) over standard Ethernet infrastructure using TCP port 44818 for explicit messaging and UDP port 2222 for I/O data. CIP is a comprehensive automation protocol supporting device configuration, diagnostics, and real-time I/O.
EtherNet/IP's security extensions are available in newer versions of the specification, including certificate-based authentication and encrypted communications for CIP Security. Adoption is growing in new deployments, particularly in environments where the consequences of process manipulation are well understood. However, the installed base of EtherNet/IP devices lacking security support is large, and the migration path requires hardware replacement in most cases.
The consequence of compromising industrial protocol communications is qualitatively different from compromising enterprise IT systems. Unauthorized access to a corporate email server produces a data breach. Unauthorized commands sent to an industrial control system can cause physical damage to equipment, disrupt production processes, trigger safety system responses, or, in the most severe cases, endanger workers and surrounding communities.
The documented history of industrial protocol attacks is short but instructive. Stuxnet (2010) sent unauthorized Modbus commands to Siemens S7 PLCs controlling centrifuge motor speeds at the Natanz enrichment facility, causing physical damage to approximately 1,000 centrifuges while spoofing normal readings back to the monitoring systems. Industroyer (2016) used native DNP3 and IEC 104 commands to manipulate power grid switching equipment in Ukraine. Triton (2017) targeted Schneider Electric safety instrumented system (SIS) controllers, attempting to disable safety systems that prevent runaway process conditions. These are not theoretical attacks. They happened against real infrastructure using the exact protocol weaknesses described above.
The scale of exposure is significant. Shodan, the internet-connected device search engine, regularly indexes thousands of Modbus-accessible and BACnet-accessible devices directly reachable from the internet. These are not always intentional exposures; they are frequently the result of network misconfiguration or devices placed behind routers without proper firewall rules.
Replay attacks: An attacker who captures a legitimate Modbus or DNP3 command can retransmit it later to cause the same action. Without sequence numbers and timestamps tied to authentication, receiving devices cannot distinguish a replayed command from a legitimate one. Replay attacks against control systems can repeatedly trigger a valve operation or pump command at adversary-controlled timing.
Man-in-the-middle command manipulation: Without message integrity protection, an attacker positioned between a master station and a field device can modify command values before they reach the destination. A command instructing a pump to operate at 60 percent capacity can be modified to 100 percent. The master station's display shows the sent value; the actual device receives the modified value.
Unauthorized command injection: Any device that can reach a Modbus or unauthenticated DNP3 endpoint can send commands. No credentials are required. Network access is the only barrier. An attacker who compromises a workstation on an OT network or pivots from an IT network into an OT network with no segmentation boundary has immediate, unobstructed ability to send control commands to every reachable device.
Device enumeration and fingerprinting: Industrial protocols broadcast detailed device information in response to discovery requests (particularly BACnet Who-Is) or can be queried for device identification registers (Modbus Function Code 43). This allows an attacker to build a complete map of the OT network, including device types, firmware versions, and capabilities, without any authentication.
Protocol-aware intrusion detection systems are the primary monitoring tool for OT environments. Standard network IDS rules designed for IT traffic cannot parse Modbus, DNP3, or BACnet messages and cannot detect anomalous commands within those protocols. Specialized OT security platforms including Claroty, Dragos Platform, Nozomi Networks Guardian, and Tenable OT Security (formerly Indegy) passively monitor industrial protocol traffic, build a behavioral baseline of normal communication patterns, and alert on deviations.
Key detection signals: commands written to output registers outside of normal operational windows, commands from IP addresses not previously observed communicating with a given device, polling rate anomalies indicating reconnaissance, and function codes not historically used in the environment.
Network segmentation is the primary compensating control for protocol security weaknesses. The Purdue Enterprise Reference Architecture (PERA) defines the reference model: Level 0 through Level 2 (field devices, control network) are separated from Level 3 (site operations) and Level 4/5 (enterprise IT) by firewalls or demilitarized zones (DMZ). OT-to-IT communication should be unidirectional where possible (data diodes for historian replication), and all bidirectional communication should be explicitly proxied and logged.
Industrial application firewalls that understand OT protocols provide deeper enforcement: they can whitelist specific function codes and restrict which registers a given source IP is allowed to write, rather than treating all Modbus traffic as equivalent.
Industrial protocol security demonstrates a core tension that CDA's Planetary Defense Model is built to address: security and operational continuity pull in opposite directions in OT environments. The CSR methodology (Continuous Surface Reduction) applied to industrial protocols cannot mean "disable Modbus" or "block DNP3." Production operations depend on these protocols. CSR in this context means reducing the accessible surface, limiting which network paths can reach protocol-speaking devices, reducing the population of devices directly internet-accessible to zero, and applying the strictest access control available within the constraints of the environment.
SPH (Security Posture and Hygiene) carries responsibility for the ongoing discipline this requires. Segmentation architectures drift. Firewall rules accumulate exceptions. Remote access paths get added outside the change management process. APC (Autonomous Posture Command) applied to OT means continuous monitoring of the network topology, alerting on any new path that provides OT network access, and treating configuration drift as a security event rather than a routine maintenance item.
CDA's position on OPC UA is that security policy "None" should be treated as equivalent to no security at all, because it is. Organizations implementing new OPC UA deployments should require a minimum security policy of Sign (message signing without encryption) and target Basic256Sha256 with encryption for any path carrying commands rather than telemetry only.
The supply chain dimension of industrial protocol security is significant. Many OT devices ship with remote access credentials preconfigured by the vendor, Modbus slave addresses configured identically across all units of a model, and management interfaces accessible on the same network port as the control protocol. Vendor security assumptions must be reviewed at procurement, not after deployment.
Dragos, Inc. "CRASHOVERRIDE: Analyzing the Threat to Electric Grid Operations." Dragos, 2017. https://dragos.com/resource/crashoverride-analyzing-the-threat-to-electric-grid-operations/
Langner, Ralph. "Stuxnet: Dissecting a Cyberwarfare Weapon." IEEE Security and Privacy, 2011. https://ieeexplore.ieee.org/document/5772960
CISA. "ICS-CERT Alert: TRITON/TRISIS Malware." CISA Alert ICS-ALERT-17-318-01A, 2018. https://www.cisa.gov/news-events/ics-alerts/ics-alert-17-318-01a
NIST. "Guide to Industrial Control Systems (ICS) Security." NIST SP 800-82 Rev. 3, 2023. https://csrc.nist.gov/publications/detail/sp/800-82/rev-3/final
ICS-CERT / CISA. "Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies." CISA, 2016. https://www.cisa.gov/sites/default/files/recommended_practices/NCCIC_ICS-CERT_Defense_in_Depth_2016_S508C.pdf
CDA, LLC. Planetary Defense Model Master Reference. CDA Canon, 2026.