IT Protocols Inside OT Networks

Underneath almost every modern control network, including the industrial protocols covered in Lesson 5, sits the same Ethernet and TCP/IP stack that carries email and web traffic on any office network. This convergence is exactly what Lesson 1 described: OT abandoned proprietary serial links and adopted commodity Ethernet hardware because it was cheaper, faster, and easier to find replacement parts for. The addressing rules, the framing, the routing logic — all of it is the same TCP/IP your students already teach in a networking course.

What's different is what's connected to it and how forgiving that traffic is expected to be. An office workstation that receives a malformed or unexpected packet typically drops it and moves on without anyone noticing. Many field devices — PLCs and RTUs built with limited processing headroom and firmware that hasn't been updated in years — handle the same situation far less gracefully: a burst of unexpected broadcast traffic, a port scan, or even a legitimate but unfamiliar packet type can occasionally cause a controller to stall, or in rarer documented cases, fault outright. This is one reason OT network engineers configure switches to restrict what can reach a given device far more tightly than a typical office switch would.

A VLAN (virtual local area network) logically divides one physical switch, or a stack of switches, into multiple separate broadcast domains — groups of ports that can talk to each other freely but cannot reach ports in a different VLAN without passing through a router or firewall. The key word is logically: the plant-floor HMI and the front-office accounting PC can be plugged into the same physical switch cabinet and still be completely unable to reach each other on the network, because they've been assigned to different VLANs.

Segmentation is the broader security goal that VLANs are one common tool for achieving: dividing a network into isolated zones connected only through governed conduits, so that a fault or compromise in one zone doesn't automatically reach another. This is the zones-and-conduits vocabulary from Lesson 2's Purdue model discussion made concrete — a VLAN boundary is frequently how a Purdue level boundary is actually implemented on real switching hardware, alongside firewalls and routers that control what's allowed to cross between VLANs.

DHCP (Dynamic Host Configuration Protocol) automatically hands a connecting device an IP address, a subnet mask, a default gateway, and often a DNS server address, so nobody has to configure any of it by hand. It's the reason a laptop or phone just works the instant it joins any office or home network. In OT, DHCP is frequently disabled in favor of static addressing — every device is configured, by hand, with a permanent IP address that never changes — precisely because "it just works automatically" is not actually the priority; "it comes back exactly the way it was" is. A PLC that loses power in a plant-wide outage needs to reappear at the same address every technician's documentation, every HMI configuration, and every firewall rule already expects, without depending on a DHCP server being reachable — or even powered on — during that restart.

DNS (Domain Name System) resolves a human-readable hostname like historian01 into the IP address a device actually needs to connect to. It's essential on the open internet, where sites change IP addresses constantly. In a control network, the set of devices that need to talk to each other is small, known, and stable — so many OT environments skip DNS for critical control paths entirely, using static hosts files or hard-coded IP addresses instead. The logic is the same as with DHCP: a name-resolution service is one more thing that can fail, and a failure in DNS shouldn't be able to stop an HMI from reaching a PLC it's talked to the exact same way for the last five years.

NTP (Network Time Protocol) keeps every device's clock synchronized to a common time source, typically to within milliseconds. On an office network, that source is almost always somewhere on the internet — a public NTP pool, or a time service baked into the operating system. In a control network, that same internet path frequently doesn't exist, and even where it does, OT time sync is commonly pointed instead at a local, GPS-disciplined clock: a small appliance that receives an extremely precise time signal from GPS satellites and distributes it to every device on the plant network, with no dependency on any external network path at all.

Accurate, consistent time matters far more in OT than the everyday case of "the clock on my laptop is a few seconds off" suggests. Protective relays (the IEDs from Lesson 3) need synchronized time to sequence-of-events records that determine, down to the millisecond, which device tripped first during a fault — the entire point of that record is figuring out cause and effect. And during any incident investigation, whether it's a physical fault or a cybersecurity event, alarm and log timestamps from every device involved need to agree, or reconstructing what actually happened in what order becomes difficult or impossible.

Select a service below to see its role and its typical OT-appropriate configuration, then use Simulate an Office-Style Misconfiguration to see what happens if that service is left configured the way it would be on a typical office LAN instead. Nothing here touches a real device, network, or protocol; it's a model built to compare consequences across configuration choices.

Five questions covering the lesson's key distinctions. Answer each, then select Grade My Quiz to see your score and an explanation for every item.

• 📄 Download: IT Protocols in OT Networks — Quick Reference (PDF) — a printable one-page comparison of IT-default versus OT-appropriate configuration for Ethernet/TCP-IP, VLANs, DHCP, DNS, and NTP, suitable for classroom handout.
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security — the standard federal reference for OT network architectures and controls, including segmentation and addressing guidance relevant to this lesson.
• Foundations of OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (CISA) — practical grounding for knowing what's actually connected to the network before configuring it.