IoT/OT Security Fundamentals
Why OT flips IT's priority order to availability/safety-first, the Purdue Model, common IoT device vulnerabilities, legacy protocols like Modbus, and the air-gap myth.
Learning Objectives
- → Distinguish IT security priorities from OT security priorities (availability/safety-first)
- → Explain the Purdue Model for segmenting industrial control network levels
- → Identify common IoT device vulnerabilities: default credentials, unpatched firmware, exposed interfaces
- → Explain why legacy OT protocols (Modbus, DNP3) often lack authentication/encryption by design
- → Explain why 'air-gapped' OT networks are often not actually air-gapped in practice
IT vs OT: A Different Priority Order
Traditional IT security typically prioritizes Confidentiality > Integrity > Availability. Operational Technology (OT) — the systems controlling physical processes in manufacturing, power grids, water treatment, and similar industrial environments — usually flips this to Availability and Safety > Integrity > Confidentiality. A ransomware-encrypted file server is a costly IT incident; a ransomware-halted water treatment control system can be a life-safety incident. This single differing priority reshapes almost every security decision in OT.
The Purdue Model: Segmenting Industrial Networks
The Purdue Enterprise Reference Architecture divides an industrial network into levels, from the physical process up to enterprise IT:
| Level | Contains |
|---|---|
| Level 0 | Physical process (sensors, actuators) |
| Level 1 | Basic control (PLCs — Programmable Logic Controllers) |
| Level 2 | Area supervisory control (HMIs — Human-Machine Interfaces, SCADA) |
| Level 3 | Site operations (manufacturing execution systems) |
| Level 4/5 | Enterprise IT (business systems, the corporate network) |
Security architecture in OT is built around strictly controlling traffic between these levels — a compromise starting at Level 4/5 (enterprise IT, phished via email like any other corporate breach) should never be able to freely reach Level 0/1 (the physical process itself).
Common IoT Device Vulnerabilities
| Vulnerability | Why it's common |
|---|---|
| Default credentials | Devices ship with a known, often undocumented-to-the-user default password, rarely changed after deployment |
| Unpatched firmware | Many IoT devices have no automatic update mechanism, and manufacturers frequently stop supporting older models entirely |
| Exposed management interfaces | Web/telnet/SSH admin panels left reachable from the internet, discoverable via services like Shodan |
| Insecure APIs | Cloud-connected IoT devices often communicate through APIs with weak or missing authentication |
Legacy OT Protocols: Modbus and DNP3
Protocols like Modbus and DNP3, still widely deployed in industrial environments, were designed decades ago for reliability on isolated serial networks — with no built-in authentication or encryption. Any device that can reach a Modbus-speaking PLC on the network can typically issue commands to it with no credential check at all. This isn't a bug to patch; it's the protocol's original design assumption (a fully trusted, physically isolated network) — an assumption modern connected OT environments frequently violate.
The "Air-Gapped" Myth
Many organizations assume their OT network is air-gapped (physically isolated, no path to the internet) and therefore inherently safe from remote attack. In practice, "temporary" maintenance laptops, USB drives, vendor remote-access connections, and undocumented IT/OT network bridges routinely erode this isolation over time — Stuxnet famously crossed an air gap via infected USB drives. Treat "air-gapped" as a claim to verify, not a security control to rely on by default.
Common Pitfalls
- Applying standard IT patching cadence/urgency to OT systems, where an unplanned reboot of a live industrial process can itself cause a safety incident
- Assuming legacy protocol traffic (Modbus/DNP3) is safe because "it's always been that way," ignoring that the network's trust assumptions have changed
- Treating "air-gapped" as a verified fact rather than something to actively test and monitor for violations
- Deploying IoT devices with default credentials still in place, discoverable via simple internet-wide scanning
An unplanned outage in OT can mean a physical safety incident, not just a cost or inconvenience.
In OT environments, which priority typically takes precedence over confidentiality?
Enterprise IT (Level 4/5) gets phished and breached like any other corporate network — the question is whether that breach can reach the physical process.
Why is traffic between Purdue Model levels tightly controlled, especially between Level 4/5 and Level 0/1?
Stuxnet famously crossed a claimed air gap via infected USB drives, not a network connection.
Why can't an organization safely assume its OT network is air-gapped without active verification?
💪 Exercises & Challenges
IoT/OT Security Fundamentals MCQ
Test your understanding of IoT/OT Security Fundamentals.
Segment a Simple Industrial Network by Purdue Level
A small manufacturing facility has: (1) office PCs and email on the corporate network, (2) an HMI/SCADA workstation monitoring production, (3) PLCs directly controlling machinery, (4) sensors wired to
Diagnose Two Independent OT Findings
An OT security assessment finds: (1) a Modbus-speaking PLC on the plant floor accepts commands from any device that can reach it on the network, with zero authentication, (2) the plant's IT director i