If you work in operational technology security, you’ve probably heard many promises about “full network visibility.” Firewalls, intrusion detection systems, and SIEMs — they all claim to show you what’s happening on your network. And for IT environments, they largely deliver on that promise.
But OT networks are different stories.
The communication that flows between PLCs, RTUs, HMIs, and other industrial devices doesn’t look anything like web traffic or email. It speaks in its own language, which is specialized protocols designed decades ago to reliably move control commands and sensor data, often insecurely. Most security tools either ignore this traffic entirely or treat it as a black box they can’t open.
Industrial protocol parsing is the capability that changes that. It’s what allows a security tool to actually read that traffic, understand what’s being commanded, and flag when something is wrong. And right now, very few platforms on the market can actually do it.
What Are Industrial Protocols?
To understand why parsing them is hard, it helps to understand what these protocols actually are and what they were built to do.
Industrial protocols are the communication standards used by control system devices to exchange data. Think of them as the native languages of the factory floor, the power substation, the water treatment plant, or the oil pipeline. They carry commands like “open this valve,” “read this sensor,” or “set this motor speed to X.” They were engineered for determinism and reliability in environments where a missed message or a delayed response could cause physical consequences.
Here’s a closer look at the most common ones you’ll encounter.
Modbus
Modbus is one of the oldest industrial protocols still in wide use today, originally developed by Modicon in 1979. Its age is a feature, not a bug, for many operators. It’s simple, well-understood, and supported by virtually every PLC and RTU manufacturer on the market. You’ll find it in manufacturing, energy, water systems, building automation, and plenty of other sectors.
Modbus works on a client/server model. A client device (like an HMI or SCADA server) sends requests to server devices (like a PLC or sensor), which respond with data or acknowledge commands. The protocol uses a small set of function codes to define what kind of action is being taken: reading coil status, reading input registers, writing to a single coil, writing to multiple registers, and so on.
From a security standpoint, Modbus has no authentication, widely unused encryption options, and no concept of authorization. Any device on the network can send a valid Modbus command, and the slave device will execute it. This makes deep parsing critical: you need to be able to see not just that Modbus traffic is present, but what function codes are being used, which registers are being written to, and whether those actions are consistent with normal operations.
DNP3
DNP3 (Distributed Network Protocol 3) was developed in the early 1990s primarily for the electric utility industry, though it’s widely used in water and wastewater systems as well. It was designed to handle the realities of SCADA communication over unreliable or noisy links, with built-in support for data integrity, timestamps, and unsolicited responses from remote devices.
DNP3 is considerably more complex than Modbus. It supports a layered architecture with application, transport, and data link layers all defined within the protocol itself. It includes the concept of objects and variations, meaning a single message can carry structured data about multiple points in a system simultaneously.
One of DNP3’s notable features is its support for unsolicited reporting, where a remote device sends data to the master when certain conditions are met, rather than waiting to be polled. This makes it efficient for large-scale SCADA deployments but also means that parsing the traffic requires understanding the full context of a session, not just individual packets.
DNP3 also has a Secure Authentication extension (SA) that adds challenge/response authentication, though adoption has been inconsistent across the industry. Many deployments still run without it.
EtherNet/IP
EtherNet/IP is a modern industrial protocol developed by Rockwell Automation and now managed by ODVA. It runs on standard Ethernet and TCP/IP infrastructure, which is part of what makes it both popular and potentially risky. Because it operates over the same physical network as IT systems, it’s easier to accidentally expose than older serial-based protocols.
EtherNet/IP uses the Common Industrial Protocol (CIP) as its application layer, which is also shared by DeviceNet and ControlNet. CIP defines a rich object model for industrial devices, supporting things like I/O data exchange, device configuration, and diagnostics. Connections can be either explicit (request/response, like reading a parameter) or implicit (streaming I/O data continuously).
Rockwell PLCs like the ControlLogix and CompactLogix lines communicate using EtherNet/IP, which means it’s everywhere in North American manufacturing. Parsing EtherNet/IP correctly requires understanding not just the Ethernet and TCP layers, but the CIP encapsulation on top of them and the specific object and service codes being used.
PROFINET
PROFINET is the industrial Ethernet standard developed by Siemens and supported by the PROFIBUS and PROFINET International organization. It’s dominant in European manufacturing environments and anywhere Siemens automation equipment is deployed, which is a significant portion of the global industrial base.
PROFINET operates at two levels. PROFINET IO handles real-time communication between controllers and field devices, exchanging cyclic I/O data on a deterministic schedule. PROFINET CBA (Component Based Automation) handles communication between larger automation components. There’s also PROFINET IRT (Isochronous Real-Time) for applications requiring very precise timing, like motion control.
One of the challenges with PROFINET is that its real-time communication runs directly over Ethernet without TCP/IP, using its own protocol stack. This means standard network monitoring tools that only understand TCP/IP traffic will miss a significant portion of what’s actually happening on a PROFINET network. True parsing requires understanding both the standard IP-based management traffic and the raw Ethernet frames used for real-time I/O.
BACnet
BACnet (Building Automation and Control Networks) was developed by ASHRAE specifically for building automation systems. If you’re dealing with HVAC, lighting, access control, fire safety systems, or elevators in a commercial or industrial building, you’re likely dealing with BACnet.
BACnet’s defining feature is its object model. Every device and every data point within a device is represented as a BACnet object with a defined set of properties. An air handler, for example, might be represented as multiple objects covering its supply fan, cooling coil, heating coil, temperature sensors, and dampers. The protocol defines standard objects like Analog Input, Binary Output, and Schedule, as well as allowing proprietary objects for vendor-specific features.
BACnet can run over several transport options including BACnet/IP (the most common modern implementation), BACnet MS/TP (a serial protocol common in field devices), and Ethernet. The convergence of building systems onto corporate networks has made BACnet security a growing concern, particularly as smart building technology becomes more connected to cloud platforms.
IEC 61850
IEC 61850 is the international standard for communication in electrical substations, and it’s increasingly used in renewable energy systems, microgrids, and distributed energy resources. It’s one of the more sophisticated industrial protocols, with a comprehensive data model and multiple communication services defined within the standard.
IEC 61850 uses a hierarchical naming scheme to identify every data point in a substation in a standardized way. A protection relay’s overcurrent element, for example, has a defined logical node name, making it theoretically interoperable between vendors. The standard includes Manufacturing Message Specification (MMS) for client/server communication, GOOSE (Generic Object Oriented Substation Event) for fast, multicast event messages between devices, and Sampled Values for streaming high-speed measurements.
GOOSE messages are particularly interesting from a security perspective because they operate outside of TCP/IP and are sent directly over Ethernet with very high priority. Spoofed or replayed GOOSE messages could cause protection relays to operate incorrectly, with potentially serious consequences for grid stability. Detecting this kind of attack requires a parsing capability that understands IEC 61850’s structure at the Ethernet frame level.
OPC-UA
OPC Unified Architecture is a newer, platform-independent communication standard developed by the OPC Foundation. Unlike most of the protocols above, OPC-UA was designed from the beginning with security in mind, including built-in support for authentication, authorization, and encrypted transport.
OPC-UA is increasingly used as an interoperability layer in modern ICS architectures, often sitting between field-level devices and higher-level systems like historians, MES platforms, and cloud analytics. It’s central to Industry 4.0 and IIoT architectures because it can represent complex data structures and expose them in a standardized way.
Even though OPC-UA has stronger security features than older protocols, parsing it still matters. Misconfigured servers, anonymous access endpoints, and excessive permissions are common in real-world deployments. Understanding what nodes are being read or written, what methods are being called, and what subscriptions are being established is important for detecting both external attacks and insider threats.
What Industrial Protocol Parsing Actually Means
Having visibility into your OT network is not the same as understanding what’s happening on it.
A standard network monitoring tool can tell you that a packet went from IP address 192.168.1.10 to 192.168.1.20 on port 502. That’s a Modbus connection. But what function code was used? Which register was written? What is the value? Is that write command something that happens during normal operations, or is it completely anomalous?
Without parsing, you don’t know. You have a log entry. With parsing, you have context.
Industrial protocol parsing means decoding the full content of these specialized protocols, down to the function codes, object identifiers, register addresses, data values, and session context. It means a security platform can tell you not just that Modbus traffic occurred, but that a write-multiple-registers command was sent to coil addresses that are normally read-only, from a source device that has never sent commands before.
That’s the difference between a network flow log and actual operational intelligence.
Why Most Security Tools Fall Short
The core problem is that most security platforms were built for IT environments and adapted for OT as an afterthought.
Standard deep packet inspection engines understand HTTP, DNS, TLS, SMB, and similar IT protocols in detail. When they encounter Modbus or PROFINET traffic, they may identify the protocol by its port number or a simple signature, but they can’t decode what’s inside the payload. The actual content of the industrial communication remains opaque.
This creates a significant blind spot. Many of the most meaningful indicators of compromise in an OT environment are only visible at the protocol level. A historian server that suddenly starts issuing write commands instead of just reading data. A new device sending EtherNet/IP requests to a PLC it has no business communicating with. An IEC 61850 GOOSE message that appears during a period when no switching operations are scheduled. None of these show up as obvious threats in a tool that’s only looking at IP headers and port numbers.
The result is that organizations get a false sense of coverage. They see network traffic, they see connection logs, and they assume they have visibility. What they actually have is a partial picture with the most operationally relevant details stripped out.
How Valkyrie Does Industrial Protocol Parsing Differently
Valkyrie was purpose-built for OT and ICS environments, and industrial protocol parsing is central to how the platform works.
While most security tools treat industrial traffic as background noise they can’t interpret, Valkyrie actually gets into the payload and reads what’s there.
Most competing tools stop at identifying that a protocol is present. They see Modbus on port 502 and log the connection. Valkyrie goes further by decoding the content of that traffic, which is where the operationally relevant information actually lives. That deeper level of inspection is what separates meaningful OT security visibility from a list of IP connections.
It’s worth being straightforward here: industrial protocol parsing is genuinely difficult work. The protocols used across OT environments are numerous, highly varied, and in some cases decades old with limited public documentation. No single platform parses every protocol perfectly, and anyone who claims otherwise is worth questioning. What Valkyrie focuses on doing this well for the protocols that matter most and continuing to deepen that coverage over time.
If you want to know exactly which protocols Valkyrie currently supports and at what level of depth, the best path is a direct conversation with our team. Protocol coverage is an area of active development, and we’d rather give you an accurate answer than an impressive-sounding one.
Closing Thoughts
Industrial protocol parsing isn’t a buzzword or a checkbox on a compliance form. It’s a fundamental requirement for any security tool that claims to provide real visibility into an OT environment.
The protocols that run industrial infrastructure were not designed with security in mind. They’re powerful, precise, and they’re completely transparent to anything that can actually read them. Leaving them unread means leaving your most operationally significant network traffic outside the scope of your security program.
Valkyrie is one of the very few platforms on the market with the depth of protocol parsing needed to close that gap. If you’re serious about OT security and you’re relying on tools that can’t decode your industrial traffic, it’s worth taking a closer look at what you might be missing.
Ready to see what Valkyrie can find on your network? Request a demo and see industrial protocol parsing in action.
