If you’ve spent any time in OT security, you’ve heard the promises about “full network visibility.” Firewalls, intrusion detection systems, SIEMs. They all claim to show you what’s happening on your network, and in IT environments, they mostly do.
OT networks are a different animal.
The traffic flowing between PLCs, RTUs, HMIs, and other industrial devices doesn’t look anything like web traffic or email. It runs on specialized protocols, most of them built decades ago to reliably move control commands and sensor data. Security wasn’t really part of the original design.
Industrial protocol parsing is the capability that changes how you see this traffic. It’s what lets a security tool actually read what’s happening, understand what’s being commanded, and flag when something looks wrong. Very few platforms on the market can actually do it.
What Are Industrial Protocols?
Before getting into why parsing them is hard, it helps to understand what these protocols are and what they were built to do.
Industrial protocols are the communication standards that control system devices use to exchange data. Think of them as the native languages of the factory floor, the substation, the water treatment plant, the 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 places where a missed message or a delayed response can have physical consequences.
Here’s a closer look at the ones you’ll run into most often.
Modbus
Modbus has been around since 1979, originally developed by Modicon, and it’s still everywhere. That’s not a knock on it. The protocol is simple, well understood, and supported by basically every PLC and RTU vendor out there. You’ll find it in manufacturing, energy, water systems, building automation, and plenty of other sectors.
It works on a client/server model. A client (an HMI or SCADA server, for example) sends requests to server devices like PLCs or sensors, which respond with data or acknowledge the command. A small set of function codes defines what the message is doing: reading coil status, reading input registers, writing to a single coil, writing to multiple registers, and so on.
Security-wise, 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 will execute it. That’s exactly why deep parsing matters here. You need to see not just that Modbus traffic is on the wire, but which function codes are being used, which registers are being written, and whether any of it lines up with normal operations.
DNP3
DNP3, the Distributed Network Protocol 3, came out of the early 1990s and was built primarily for electric utilities, though it shows up in water and wastewater systems too. It was designed to handle SCADA communication over unreliable or noisy links, with built-in support for data integrity, timestamps, and unsolicited responses from remote devices.
It’s also a lot more complex than Modbus. DNP3 has its own application, transport, and data link layers, all defined inside the protocol. It uses the concept of objects and variations, so a single message can carry structured data about multiple points in a system at once.
One thing that makes DNP3 distinctive is unsolicited reporting. Remote devices can push data to the master when certain conditions are met, instead of waiting to be polled. That’s efficient for large SCADA deployments, but it also means parsing the traffic requires understanding the full session context, not just individual packets.
There’s a Secure Authentication extension (SA) that adds challenge/response authentication, but adoption has been spotty. Plenty of deployments still run without it.
EtherNet/IP
EtherNet/IP is a more modern industrial protocol, originally developed by Rockwell Automation and now managed by ODVA. It runs on standard Ethernet and TCP/IP infrastructure, which is part of why it’s so popular and also part of why it’s risky. Sharing infrastructure with IT systems makes it a lot easier to accidentally expose.
It uses the Common Industrial Protocol (CIP) as its application layer. CIP also shows up in DeviceNet and ControlNet, and it defines a rich object model for industrial devices covering I/O exchange, configuration, and diagnostics. Connections can be explicit (request/response, like reading a parameter) or implicit (streaming I/O data continuously).
Rockwell’s ControlLogix and CompactLogix lines communicate over EtherNet/IP, which means it’s basically everywhere in North American manufacturing. To parse it correctly, you have to handle the Ethernet and TCP layers, the CIP encapsulation sitting on top, and the specific object and service codes being used.
PROFINET
PROFINET is the industrial Ethernet standard developed by Siemens and supported by PROFIBUS and PROFINET International. If you’re working in European manufacturing, or anywhere Siemens automation gear is installed (which is a huge chunk of the global industrial base), you’ll see it constantly.
It runs 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 that need very precise timing, like motion control.
Here’s where things get tricky for monitoring tools. PROFINET’s real-time communication runs directly over Ethernet, no TCP/IP, using its own protocol stack. Standard network monitoring tools that only understand TCP/IP will completely miss a big chunk of what’s actually happening on a PROFINET network. Real parsing means handling both the IP-based management traffic and the raw Ethernet frames carrying real-time I/O.
BACnet
BACnet, Building Automation and Control Networks, was developed by ASHRAE specifically for building systems. If you’re dealing with HVAC, lighting, access control, fire safety, or elevators in a commercial or industrial building, you’re dealing with BACnet.
Its defining feature is the object model. Every device, and every data point inside a device, is represented as a BACnet object with a defined set of properties. An air handler, for instance, might be modeled as multiple objects covering its supply fan, cooling coil, heating coil, temperature sensors, and dampers. The protocol defines standard object types like Analog Input, Binary Output, and Schedule, and it allows proprietary objects for vendor-specific features.
It can run over a few different transports: BACnet/IP (the most common modern flavor), BACnet MS/TP (a serial protocol common in field devices), and Ethernet. As building systems get pulled onto corporate networks and connected to cloud platforms for smart building features, BACnet security has become a much bigger concern than it used to be.
IEC 61850
IEC 61850 is the international standard for substation communication, and it’s showing up more and more in renewable energy systems, microgrids, and distributed energy resources. It’s one of the more sophisticated industrial protocols in use, with a comprehensive data model and several different communication services defined inside the standard.
The protocol 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, which makes it theoretically interoperable across 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 is the part that gets the most security attention. These messages run outside TCP/IP, sent directly over Ethernet at very high priority. Spoofed or replayed GOOSE traffic could cause protection relays to operate incorrectly, with consequences that affect grid stability. Catching that kind of attack means parsing IEC 61850 down to the Ethernet frame level.
OPC-UA
OPC Unified Architecture is a newer, platform-independent standard from the OPC Foundation. Unlike most of the protocols above, OPC-UA was designed with security in mind from the start. It has built-in support for authentication, authorization, and encrypted transport.
You’ll see OPC-UA 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 a lot of Industry 4.0 and IIoT designs because it can represent complex data structures and expose them in a standardized way.
Even with stronger security than older protocols, parsing OPC-UA still matters. Misconfigured servers, anonymous access endpoints, and overly permissive accounts are common in real deployments. Knowing what nodes are being read or written, what methods are being called, and what subscriptions are being established is important for catching both external attackers and insider threats.
What Industrial Protocol Parsing Actually Means
Visibility into your OT network is not the same as understanding what’s happening on it.
A standard network monitoring tool can tell you a packet went from 192.168.1.10 to 192.168.1.20 on port 502. Great, that’s a Modbus connection. But what function code was used? Which register got written? What was the value? Is that something that happens during normal operations, or is it completely out of place?
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, all the way down to 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 went to coil addresses that should be 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 after the fact.
Standard deep packet inspection engines understand HTTP, DNS, TLS, SMB, and the rest of the IT stack in detail. When they hit Modbus or PROFINET traffic, they may identify the protocol by port number or a simple signature, but they can’t decode what’s inside the payload. The actual content stays opaque.
That’s a serious blind spot. A lot of the most meaningful indicators of compromise in an OT environment only show up 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 talking to. A GOOSE message appears during a window when no switching operations are scheduled. None of that surfaces as an obvious threat in a tool that’s only looking at IP headers and port numbers.
The result is a false sense of coverage. Organizations see network traffic, see connection logs, and 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 sits at the heart of how the platform works.
Where 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 contents of that traffic, which is where the operationally relevant information actually lives. That deeper level of inspection is what separates real OT security visibility from a list of IP connections.
Here’s the honest take: industrial protocol parsing is genuinely hard work. The protocols 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 telling you otherwise is worth a second look. Valkyrie focuses on doing this well for the protocols that matter most, and we keep deepening that coverage over time.
If you want to know exactly which protocols Valkyrie supports today and at what level of depth, the best move is a direct conversation with our team. Coverage is an active area of development, and we’d rather give you an accurate answer than an impressive-sounding one.
For organizations that need help in the field, our OT professional services pair the platform with hands-on engineering support. And when an assessment has to happen in a remote location with no cloud or internet access, that’s where Cygnet comes in. Same Valkyrie capabilities, packaged as a flyaway kit that runs fully offline.
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 in an OT environment.
The protocols running industrial infrastructure weren’t designed with security in mind. They’re powerful, they’re 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 parsing depth 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 a closer look at what you might be missing.
Ready to see what Valkyrie can find on your network? Request a demo and watch industrial protocol parsing in action
