Lesson Overview
Lesson 4 gave you the Ethernet, TCP/IP, and network-service foundation that industrial traffic now rides on. This lesson climbs one layer up, to the protocols devices actually use to ask each other for data and issue commands: Modbus TCP, DNP3, EtherNet/IP, PROFINET, BACnet/IP, and OPC UA. Each one was built for a different corner of industry — discrete manufacturing, electric and water utilities, building automation — often a decade or more before "cybersecurity" was part of the design conversation at all. That history is not trivia; it directly explains why five of these six protocols will happily execute a command from anyone able to reach them on the wire, no password required, and why OPC UA looks so different from the rest.
We'll take the protocols roughly in the order most faculty will encounter them in the field: Modbus TCP first, because its simplicity makes it the easiest place to learn to read function codes and framing in a packet capture; then DNP3, built specifically for utility SCADA; then the two competing industrial-Ethernet standards, EtherNet/IP and PROFINET; then BACnet/IP, the protocol running the building your classroom is probably in right now; and finally OPC UA, the one protocol on this list that was designed after the industry already understood these systems were being attacked.
Think of these six protocols as six different languages spoken at six different job sites, each shaped by the era and the trust level of the room it was born in. Modbus is a two-word pidgin invented in 1979 for machines that only ever talked to other machines on the same factory floor — it has no concept of "prove who you are" because that idea never came up. OPC UA is a modern language built by committee decades later, after everyone in the room had already been burned by strangers walking in and giving orders in the old pidgin — so it comes with an ID-check built into every conversation from the start. Same general job — describing and requesting data — but the assumptions baked into each language are a generation apart.
Learning objectives
By the end of this lesson, you will be able to:
- Explain the historical origin and intended use case of Modbus, DNP3, EtherNet/IP, PROFINET, BACnet/IP, and OPC UA.
- Identify the function code, addressing, and framing fields of a Modbus TCP request and response in a packet capture.
- Compare DNP3's utility-SCADA design, including unsolicited event reporting, against Modbus's simpler master/slave model.
- Describe why Modbus, DNP3, EtherNet/IP, PROFINET, and BACnet/IP carry no native authentication by default.
- Evaluate how OPC UA's built-in security model differs from that of the five legacy protocols in this lesson.
- Configure a simulated Modbus TCP read or write request and correctly interpret every field in its response.
Modbus TCP: the simplest language on the floor
≈ 40 minModbus is the oldest protocol in this lesson by a wide margin. Modicon (now part of Schneider Electric) published it in 1979 as a serial protocol for its own PLCs, and it was deliberately minimal: one master device polls one or more slave devices for data using a small set of numbered function codes, and the slave replies in kind. There was no committee, no security review, and no expectation the protocol would ever leave a single factory's wiring closet. In 1999, Schneider published Modbus TCP, which wraps that same simple request/response structure inside a standard TCP/IP packet on port 502 — swapping the old serial wiring for Ethernet without changing the underlying conversation at all. That age and simplicity are exactly why Modbus remains one of the most widely implemented industrial protocols on earth: it is easy to build into a $40 sensor, and after 45 years almost every SCADA and HMI package on the market already speaks it.
A Modbus TCP message has two parts. The MBAP header (Modbus Application Protocol header) is seven bytes that TCP itself needed but the original serial protocol never had: a two-byte transaction identifier the master picks to match each response to its request, a two-byte protocol identifier that is always zero for Modbus, a two-byte length field counting the bytes that follow, and a one-byte unit identifier for addressing a specific device behind a gateway. After that comes the PDU (protocol data unit): a one-byte function code — such as 0x01 Read Coils, 0x03 Read Holding Registers, 0x06 Write Single Register, or 0x10 Write Multiple Registers — followed by whatever address, quantity, or value data that function code requires. Nothing in either part identifies who is asking, or checks whether they are allowed to ask.
Diagram: every Modbus TCP frame is a fixed seven-byte MBAP header followed by a PDU that starts with a one-byte function code. Nowhere in this structure is there a field for a username, password, or certificate — the frame has no concept of identity at all.
At a small water treatment plant, a SCADA client polls a level transmitter's Modbus TCP gateway every ten seconds. The request is 00 01 00 00 00 06 01 03 00 00 00 02 — transaction ID 1, protocol ID 0, length 6, unit ID 1, function code 03 (Read Holding Registers), starting address 0000, and quantity 0002. The gateway replies 00 01 00 00 00 07 01 03 04 00 80 00 2D: same transaction ID, length 7, unit ID 1, function code 03, byte count 4, and two register values — 0080 hex (128 decimal) for holding register 0, which this plant scales as tank level in tenths of a foot (12.8 ft), and 002D hex (45 decimal) for holding register 1, effluent turbidity in hundredths of an NTU (0.45 NTU). Any device on that network segment that can form the same twelve bytes gets the identical answer — there is no login step to skip, because none exists.
| Code | Name | What it does |
|---|---|---|
| 0x01 | Read Coils | Reads one or more single-bit discrete outputs (e.g. a pump run command) |
| 0x02 | Read Discrete Inputs | Reads one or more single-bit field inputs (e.g. a limit switch) |
| 0x03 | Read Holding Registers | Reads one or more 16-bit read/write values (e.g. a setpoint or scaled sensor reading) |
| 0x04 | Read Input Registers | Reads one or more 16-bit read-only values (e.g. a raw analog input) |
| 0x05 | Write Single Coil | Sets one discrete output on or off |
| 0x06 | Write Single Register | Writes one 16-bit value, such as a setpoint |
| 0x10 | Write Multiple Registers | Writes several consecutive 16-bit values in one message |
Students with an IT background often expect a "read" operation to be inherently safe. Worth pausing here: Modbus function code 0x03 is a read, but 0x06 and 0x10 write directly to a controller's memory, and the protocol has no way to check whether the requester was supposed to be allowed to do that. The verb "read" versus "write" is the only safety distinction the protocol itself makes.
DNP3: built for the substation, not the factory floor
≈ 35 minDNP3 (Distributed Network Protocol version 3) was developed in the early 1990s by Westronic, later absorbed into GE Harris, drawing heavily on the still-unfinished IEC 60870-5 standard. It was purpose-built for a problem Modbus never had to solve: electric and water utility SCADA systems spread across dozens or hundreds of miles, where a central master station supervises many remote outstations — substations, pump stations, reclosers — often connected over slow, unreliable, or metered communication links like leased phone lines or radio. That environment shaped everything about DNP3's design. Rather than a master constantly polling every point the way a Modbus client does, a DNP3 outstation can send an unsolicited response the instant something changes — a breaker trips, a tank overflows — so the master learns about the event immediately instead of waiting for its next scheduled poll, which matters enormously when the link between them is expensive or intermittent.
DNP3 organizes data into typed object groups — binary inputs, analog inputs, counters, binary outputs — each assigned to an event class (Class 0 for static/current values, Classes 1–3 for events by priority). A master periodically performs an integrity poll, requesting Class 0 plus all pending events, to reconcile its picture of the system in case any unsolicited responses were lost in transit — a real concern on the unreliable links DNP3 was designed for. Like Modbus, the base protocol was published with no authentication: any device that can reach a master or outstation on the wire can issue commands or inject data. A later extension, DNP3 Secure Authentication (SAv5, standardized in IEEE 1815-2012), added challenge-response authentication and message integrity checks, but it is an optional add-on that many fielded utility systems still do not run.
Modbus is a supervisor walking the factory floor every few minutes, asking each machine in turn, "what's your status?" DNP3 is closer to a 911 dispatch system covering a county: most of the time the dispatcher checks in on a schedule, but if a house catches fire, the alarm calls in immediately without waiting to be asked — and periodically the dispatcher still double-checks with every station to make sure no call was missed along the way. Different geography, different failure modes, different design.
A distribution utility's SCADA master polls 40 recloser outstations every fifteen minutes for an integrity poll (Class 0 plus events). At 3:14 a.m., a fault causes Recloser 17 to open. Rather than wait up to fifteen minutes for the next scheduled poll, Recloser 17 immediately sends an unsolicited response reporting a Class 1 binary-input event: "breaker status changed to OPEN," complete with a timestamp. The master acknowledges the unsolicited response, updates its display, and still performs its next scheduled integrity poll at 3:15 to confirm no other event was missed on that same outstation.
A good discussion prompt: without DNP3 Secure Authentication enabled, what stops someone who can reach a recloser's DNP3 port from sending it an unsolicited-looking "breaker OPEN" command of their own? The honest answer — nothing in the base protocol — is exactly the motivator for Lesson 6's threat landscape discussion.
EtherNet/IP and PROFINET: two continents, two industrial Ethernets
≈ 35 minEtherNet/IP ("IP" here means Industrial Protocol, not internet protocol) was introduced around 1998–2000, driven by Rockwell Automation and standardized by ODVA (Open DeviceNet Vendors Association). It doesn't invent a new wire format; instead it carries the vendor-neutral Common Industrial Protocol (CIP) — the same object-and-service model used by ControlNet and DeviceNet — inside standard Ethernet and TCP/IP frames, using TCP port 44818 for explicit (request/response) messaging and UDP port 2222 for implicit (real-time I/O) traffic. That heritage made EtherNet/IP the dominant industrial-Ethernet choice across North American discrete manufacturing, especially anywhere Rockwell/Allen-Bradley PLCs are already installed.
PROFINET took a different path. Released in 2003 by PROFIBUS & PROFINET International (PI), with Siemens as the primary driver, it grew out of the PROFIBUS fieldbus community and was built to squeeze hard real-time performance directly out of Ethernet frames rather than riding on top of standard TCP/IP for time-critical traffic. PROFINET defines three conformance classes: RT (Real-Time, using standard Ethernet hardware for millisecond-range determinism), IRT (Isochronous Real-Time, requiring PROFINET-aware switches for microsecond-range determinism used in motion control), and a TCP/UDP-based class for non-time-critical configuration and diagnostics traffic. That heritage made PROFINET the dominant choice across European manufacturing, particularly for motion-control-heavy applications like packaging and printing lines.
EtherNet/IP
Common Industrial Protocol over standard Ethernet/TCP-IP. Dominant in North American discrete manufacturing.
PROFINET
Real-time Ethernet with RT and IRT classes. Dominant in European manufacturing and motion control.
Text alternative: two cards summarize EtherNet/IP and PROFINET side by side — their originating organization and year, what each carries over Ethernet, and the region and application type where each is most commonly deployed.
EtherNet/IP and PROFINET are like two countries that both adopted the automobile around the same decade but ended up with different road standards. Both chose "Ethernet" the way both chose "cars" — but one grew its own conventions out of an existing device ecosystem (CIP objects, in EtherNet/IP's case, tracing back to DeviceNet) and the other rebuilt the roads themselves for higher precision (PROFINET's RT and IRT classes). A vehicle built for one country's roads doesn't natively drive on the other's without a translator — which is exactly why a PLC that only speaks EtherNet/IP cannot talk directly to a drive that only speaks PROFINET.
A bottling line in Ohio uses Allen-Bradley ControlLogix PLCs talking EtherNet/IP to remote I/O racks and VFDs over standard managed Ethernet switches — no special hardware required beyond industrially rated switches. A sister plant in Germany runs the same bottling process on Siemens S7 PLCs using PROFINET IRT to synchronize servo-driven capping heads to within microseconds, which requires PROFINET-aware switches that reserve time slots for the isochronous traffic. Both lines do the same job; neither PLC's native protocol can talk directly to the other plant's field devices without a protocol gateway in between.
Like Modbus and DNP3, neither EtherNet/IP nor PROFINET's real-time (RT) class includes authentication by default — the same "we trusted the wire" design assumption from a decade earlier. PROFINET Security extensions and CIP Security exist as optional, newer additions, mirroring DNP3 Secure Authentication's story: security bolted on after the fact, not built in from day one.
BACnet/IP: the protocol running the building you're standing in
≈ 25 minBACnet (Building Automation and Control network) began in 1987 as an ASHRAE committee project aimed at a problem the HVAC industry still has today: getting thermostats, chillers, air handlers, lighting panels, and access-control systems from different manufacturers to talk to one another instead of each vendor requiring its own proprietary front end. ASHRAE published the standard as ANSI/ASHRAE 135 in 1995, originally over its own data-link options (including a native Ethernet framing and an RS-485 variant called MS/TP). In 1999, Annex J added BACnet/IP, tunneling BACnet messages inside UDP on port 47808 (hex 0xBAC0 — a deliberate nod to the protocol's name) so BACnet devices could ride ordinary IP networks and be reached across a campus rather than only a single wiring segment.
Where Modbus addresses raw registers and DNP3 addresses typed points inside object groups, BACnet takes an explicitly object-oriented approach: every controllable or readable value on a device is a numbered object — an Analog Input, Analog Output, Binary Input, Binary Value, Multi-State Value, and so on — each with a standard set of properties (Present_Value, Units, Status_Flags). A single Device object identifies the controller itself on the network by a unique Device Instance number. That structure is why a building engineer can point a single BACnet workstation at controllers from a dozen different HVAC vendors and see consistent object types across all of them, something neither Modbus nor DNP3's more numeric addressing was designed to guarantee across vendors.
A community college's building automation system polls an air-handling unit's BACnet controller (Device Instance 4021) for Analog Input object AI-3, Present_Value property — the supply-air temperature sensor — and receives back a real value of 54.2°F. The same controller exposes Binary Output object BO-1 for the supply fan's run command and Multi-State Value object MSV-2 for the unit's current operating mode (Occupied / Unoccupied / Warm-up / Cool-down). None of that traffic, by default, requires the requesting workstation to authenticate — any device on the same BACnet/IP network segment can issue the identical read, and in most fielded systems, the identical write to BO-1.
Faculty are often surprised BACnet/IP belongs in an OT cybersecurity course at all, since "the building" doesn't sound like critical infrastructure. Worth naming directly: HVAC, access control, and life-safety systems in hospitals, labs, and data centers all commonly run on BACnet, and a compromised building controller can affect physical safety and equipment (like server-room cooling) well beyond comfort. A newer extension, BACnet/SC (Secure Connect), adds TLS-based encryption and certificate authentication, following the same "security added later" pattern as DNP3 SAv5.
OPC UA: designed after the industry already knew better
≈ 30 minThe story of OPC UA (OPC Unified Architecture) starts with its predecessor. OPC Classic — originally "OLE for Process Control" — appeared in 1996 as a way to let Windows-based HMI and SCADA software talk to PLCs from many vendors through a common interface, but it was built directly on Microsoft's DCOM (Distributed Component Object Model), which meant it was Windows-only, notoriously difficult to configure through firewalls, and inherited whatever security DCOM itself provided — which was not designed with industrial exposure in mind. By the mid-2000s, the OPC Foundation set out to replace that foundation entirely. OPC UA, released in 2006, is platform-independent (it runs on Windows, Linux, and embedded systems alike), transport-independent (commonly TCP port 4840, but also HTTPS and WebSocket bindings), and built around a self-describing, service-oriented information model rather than DCOM's fragile remote-object plumbing.
The part that matters most for this lesson is what changed about security. Every one of the five protocols covered earlier in this lesson assumes that whoever can reach the wire is authorized — a design decision that made sense when these protocols lived on physically isolated serial links or dedicated plant networks, and that has aged very badly as those networks became routable and, in some documented incidents, internet-reachable. OPC UA was designed after that lesson had already been learned the hard way. It builds in X.509 certificate-based authentication between client and server, message signing and encryption at the transport level, and a separate user-authentication layer (username/password, certificates, or other credentials) — none of which is bolted on as an optional extension the way DNP3 SAv5, CIP Security, and BACnet/SC are for their respective protocols. Security was part of OPC UA's specification from its first release, not a later patch.
If Modbus, DNP3, EtherNet/IP, PROFINET, and BACnet are all buildings that were constructed with a front door but no lock — because in 1985, or 1993, or 2003, nobody serious thought a stranger would ever be standing at that door — OPC UA is a building designed in the 2000s by an architect who had already read the incident reports. The door comes with a lock, a peephole, and a sign-in sheet built into the blueprint, not added afterward by a tenant who got burglarized.
A manufacturer migrating an aging OPC Classic historian connection replaces it with an OPC UA server on the PLC and an OPC UA client on the historian. During setup, the two endpoints exchange X.509 certificates and the engineer configures a security policy requiring signed and encrypted messages; the historian's service account is granted read-only access to a defined set of tags, while a separate operator account with write access to setpoints requires its own credential. An unauthorized laptop plugged into the same switch can see OPC UA traffic on the wire, but without a trusted certificate and valid credentials, it cannot establish a session with the server at all — a categorically different outcome than the same laptop pointed at a Modbus or BACnet/IP device on that same network.
It's worth being precise with students: OPC UA's security features are only as strong as their configuration. A deployment left at "Security Policy: None" for compatibility reasons gets none of these protections despite running the newer protocol. The protocol changed what's possible; it did not remove the need for someone to actually configure it correctly.
Side-by-Side: Six Protocols, Six Origins
≈ 10 minThe table below puts the history, transport, and — most importantly for a security course — the native authentication story for all six protocols in one place.
| Protocol | Origin / year introduced | Transport & port | Typical domain | Addressing / data model | Native authentication |
|---|---|---|---|---|---|
| Modbus TCP | Modicon, 1979 (serial); TCP variant, 1999 | TCP port 502 | General industrial, discrete manufacturing | Numbered coils and registers, accessed by function code | None — no authentication or encryption |
| DNP3 | Westronic / GE Harris, 1993, based on IEC 60870-5 | TCP/UDP port 20000 | Electric and water utility SCADA | Typed object groups with class-based unsolicited event reporting | None by default; optional DNP3 Secure Authentication (SAv5) |
| EtherNet/IP | Rockwell Automation / ODVA, 1998–2000 | TCP 44818 (explicit), UDP 2222 (implicit I/O) | North American discrete manufacturing | Common Industrial Protocol (CIP) objects and services | None natively; optional CIP Security extension |
| PROFINET | PROFIBUS & PROFINET International / Siemens, 2003 | Real-time Ethernet frames (RT/IRT); TCP/UDP for non-real-time traffic | European manufacturing, motion control | Device/module data defined per GSD device description | None natively in RT/IRT; optional PROFINET Security extensions |
| BACnet/IP | ASHRAE, 1995 (BACnet); Annex J, 1999 (IP tunneling) | UDP port 47808 (0xBAC0) | Building automation — HVAC, lighting, access control | Object-oriented (Analog/Binary/Multi-State objects, Device Instance) | None by default; newer BACnet/SC adds TLS and certificates |
| OPC UA | OPC Foundation, 2006 (successor to OPC Classic/DCOM, 1996) | TCP port 4840; also HTTPS/WebSocket bindings | Cross-domain — manufacturing, utilities, IT/OT convergence | Self-describing, service-oriented information model | Built in — X.509 certificates, message signing/encryption, user auth |
A useful in-class prompt: ask faculty to notice the pattern in the rightmost column before you say it out loud. Five protocols built for trusted, isolated networks share "none by default." The one protocol built after those networks stopped being isolated has authentication built into its specification. That contrast is this lesson's central takeaway.
Activity: Match the Protocol to Its Defining Trait
Individual, then pair-share ≈ 20 minIndividual (10 min): For each protocol, select the description that best captures its origin and design purpose. Pair-share (10 min): Compare answers with a neighbor — several descriptions can sound plausible for more than one protocol, but each has one best fit. Use this as a low-stakes way to explore the six protocols before the simulation below.
| Protocol | Best-fit description |
|---|---|
| Modbus TCP | |
| DNP3 | |
| EtherNet/IP | |
| PROFINET | |
| BACnet/IP | |
| OPC UA |
Simulation: Modbus TCP Frame Builder
≈ 25 minChoose a function code and fill in the fields below to build a realistic Modbus TCP request against the same simulated water-treatment holding registers from the worked example above, then see the exact response bytes the gateway would return. This tool builds byte sequences entirely in your browser — nothing is sent anywhere, and no real device is contacted.
Registers 0–4 are pre-loaded in this simulation: 0 = Tank Level (ft ×10), 1 = Effluent Turbidity (NTU ×100), 2 = Pump 1 Speed (Hz ×10), 3 = Pump 2 Speed (Hz ×10), 4 = Chlorine Residual (mg/L ×100). Coils 0–3: 0 = Pump 1 Run, 1 = Pump 2 Run, 2 = Alarm Horn, 3 = Bypass Valve Open.
Review & Knowledge Check
≈ 15 minFive questions covering the lesson's key distinctions. Answer each, then select Grade My Quiz to see your score and an explanation for every item.
Have each faculty member choose one protocol from this lesson (not Modbus, to push beyond the most-covered example) and produce a half-page "protocol profile" covering: its origin and the problem it was built to solve, one worked scenario in that protocol's typical domain, and an honest statement of its native authentication story — including any optional security extension and why fielded systems might not be running it. This mirrors the comparison table's structure and confirms the history-to-security connection transferred before Lesson 6's threat-landscape discussion.
Further Reading
- OT Protocols Overview — a broader course-site reference covering the industrial protocol landscape beyond this lesson's six.
- Modbus Deep Dive — extended detail on Modbus function codes, register types, and serial-versus-TCP variants.
- EtherNet/IP Deep Dive — additional detail on CIP objects and explicit versus implicit messaging.
- BACnet Deep Dive — additional detail on BACnet object types and the MS/TP and IP data-link options.
- OPC UA Deep Dive — additional detail on OPC UA's security model and information modeling.