IoT, OT, and Industrial Security
Design security architecture for IoT and operational technology environments including industrial control systems, SCADA, and OT network segmentation.
IoT, OT, and Industrial Security
Why OT Security Is Fundamentally Different
If you come from an IT security background, OT security will challenge your instincts. Every principle you’ve internalised — patch early, encrypt everything, deploy agents, scan regularly — either doesn’t apply or is actively dangerous in OT environments.
Here’s why:
Availability over confidentiality. In IT, we protect data. In OT, we protect processes. A manufacturing line that stops costs hundreds of thousands of dollars per hour. A power grid that fails affects millions of people. A water treatment plant that malfunctions creates a public health emergency. The CIA triad in OT is reordered: Availability → Integrity → Confidentiality.
Legacy systems with decades-long lifecycles. IT refreshes hardware every 3-5 years. OT equipment runs for 20-30 years. That programmable logic controller (PLC) managing a production line might be running Windows XP Embedded — not because anyone is negligent, but because the manufacturing process was certified on that platform and recertification costs millions.
Proprietary protocols. OT devices communicate using industrial protocols like Modbus, DNP3, BACnet, and OPC-UA. Traditional IT security tools don’t understand these protocols and can’t inspect their traffic.
No agent deployment. You cannot install software on most OT devices. PLCs, RTUs (Remote Terminal Units), and HMIs (Human-Machine Interfaces) often don’t support third-party software. Even if they did, installing an agent could invalidate the vendor’s warranty or the system’s safety certification.
Physical safety implications. A misconfigured IT server causes data loss. A misconfigured OT controller can cause an explosion, chemical release, or mechanical failure that endangers human lives.
| Aspect | IT Security | OT Security |
|---|---|---|
| Top priority | Confidentiality (protect data) | Availability (keep processes running) |
| Patching | Regular patch cycles (monthly) | Rarely — requires planned outages and recertification |
| System lifecycle | 3-5 years | 15-30 years |
| Agent deployment | Standard practice | Usually impossible or prohibited |
| Network scanning | Regular vulnerability scans | Can crash OT devices — passive monitoring only |
| Protocols | TCP/IP, HTTP, TLS | Modbus, DNP3, BACnet, OPC-UA, Profinet |
| Security tools | EDR, SIEM, vulnerability scanners | Network detection, anomaly analysis, passive monitoring |
| Change management | Agile, frequent deployments | Extremely rigid, planned months in advance |
| Failure impact | Data breach, financial loss | Physical safety, environmental damage, loss of life |
| Regulatory framework | GDPR, SOC 2, PCI DSS | IEC 62443, NIST 800-82, NERC CIP |
The Purdue Model: OT Network Architecture
The Purdue Enterprise Reference Architecture is the standard model for OT network design. It defines levels of the industrial network, each with increasing proximity to the physical process:
Level 0 — Physical Process: Sensors and actuators that interact with the physical world. Temperature sensors, pressure valves, motors.
Level 1 — Basic Control: PLCs and RTUs that directly control Level 0 devices. These execute control logic — “if temperature exceeds 200°C, open relief valve.”
Level 2 — Area Supervisory: HMIs and SCADA servers that provide operator visibility and control. Operators monitor processes and send commands from this level.
Level 3 — Site Operations: Manufacturing execution systems (MES), historians (databases storing process data), site-level management servers.
Level 3.5 — Industrial DMZ: The critical boundary between OT (Levels 0-3) and IT (Levels 4-5). This DMZ should contain jump servers, data diodes, and firewalls that strictly control what crosses the IT/OT boundary.
Level 4 — Enterprise IT: Business systems — ERP, email, databases, standard IT infrastructure.
Level 5 — Enterprise Network: Internet-facing services, cloud connectivity, remote access.
The Architect’s Key Design Principle
No direct communication between IT and OT. Every connection must pass through the Level 3.5 DMZ. If the enterprise network needs production data (e.g., for business analytics), a data historian in the DMZ replicates OT data for IT consumption. IT systems never query OT devices directly.
This principle also applies to remote access. Maintenance engineers who need to connect to OT systems must go through a jump server in the DMZ with full session recording and multi-factor authentication.
Microsoft Defender for IoT
Defender for IoT provides agentless network detection and response for OT environments. It works by passively monitoring network traffic — no agents on OT devices, no active scanning that could crash sensitive equipment.
How It Works
-
Network sensor deployment: A physical or virtual sensor connects to a SPAN port or network TAP on the OT network. It receives a copy of all network traffic without injecting any packets.
-
Asset discovery: The sensor analyses OT protocols to automatically identify every device on the network — PLCs, HMIs, engineering workstations, even devices the operations team didn’t know existed (shadow OT).
-
Vulnerability assessment: Based on identified devices and their firmware versions, Defender for IoT maps known vulnerabilities (CVEs) to your OT inventory.
-
Behavioural baseline: The sensor learns normal communication patterns — which devices talk to which, using which protocols, at what frequency. This becomes the baseline.
-
Anomaly detection: Any deviation from the baseline generates an alert. A PLC that suddenly starts communicating with the internet. An engineering workstation sending commands at 3 AM. A new protocol appearing on the network.
-
Integration with Sentinel: All alerts flow to Microsoft Sentinel for correlation with IT security events. This enables detecting attacks that span the IT/OT boundary — an attacker compromises an IT system, pivots through the DMZ, and accesses OT devices.
Deployment Architecture
For a single site, you deploy sensors on each network segment. For multi-site organisations with cloud connectivity, OT sensors at each site send alerts to the Azure portal for centralised management, with Microsoft Sentinel integration for cross-site correlation.
For air-gapped environments (common in government and critical infrastructure), each OT sensor operates independently using its local console, CLI, or APIs. Alerts can be exported to third-party SIEM or management platforms via the sensor API for multi-site visibility without cloud connectivity.
Compensating Controls for Unpatchable Systems
When you can’t patch, you compensate. This is the architect’s toolbox for protecting systems that will never receive a security update:
Network segmentation — Isolate the vulnerable system in its own network segment. Firewall rules allow only the specific protocols and ports required for its function, from specific source addresses.
Microsegmentation — Go beyond VLANs. Use next-generation firewalls or software-defined networking to create policies at the individual device level. A PLC only communicates with its HMI and the historian — all other traffic is blocked.
Virtual patching — Deploy intrusion prevention systems (IPS) that block exploitation of known vulnerabilities in network traffic before it reaches the vulnerable device. The device isn’t patched, but the network blocks the exploit.
Application allowlisting — On systems that support it (typically HMIs and engineering workstations running Windows), use application control to only allow known-good executables to run.
Monitoring — What you can’t prevent, you detect. Defender for IoT’s anomaly detection catches unauthorised access or unusual behaviour, even on unpatched systems.
Physical controls — USB port locks, physical access restrictions to OT areas, removal of unnecessary network interfaces.
🏛️ Scenario: Torres Secures Federal Industrial Systems
Commander Torres has discovered that the Department of Federal Systems operates water treatment facilities with SCADA systems running on Windows Server 2008 — unsupported, unpatched, and controlling critical infrastructure.
“We can’t upgrade these systems,” Colonel Reeves explains. “The SCADA software was certified for this platform. Recertification takes 18 months and costs $2 million per facility.”
Torres designs a layered protection strategy:
Layer 1: Network isolation. Each facility’s OT network is isolated from the IT network with a firewall implementing the Purdue model. The DMZ contains a data historian that mirrors production data for enterprise reporting — no direct IT-to-OT connectivity.
Layer 2: Monitoring. Torres deploys Defender for IoT sensors on SPAN ports at each facility. The sensors passively map all OT assets and establish behavioural baselines. Because these are federal facilities in air-gapped networks, each sensor operates independently using its local console and CLI. Alerts are exported via the sensor API to the agency’s on-premises SIEM for centralised visibility without cloud connectivity.
Layer 3: Compensating controls. The Windows Server 2008 SCADA servers get application allowlisting — only the certified SCADA software can execute. Virtual patching through IPS rules blocks exploitation of known Windows Server 2008 vulnerabilities in network traffic.
Layer 4: Access control. All remote access to OT systems goes through hardened jump servers in the DMZ with MFA and full session recording. Access is limited to specific maintenance windows with Colonel Reeves’ approval.
“We haven’t patched the SCADA servers,” Torres tells Specialist Diaz. “But we’ve made it exceptionally difficult for an attacker to reach them, and if they do, we’ll see them immediately.”
🌐 Scenario: Elena Protects Manufacturing OT
Meridian Global Industries operates 12 manufacturing plants across 8 countries. Each plant has its own OT network with PLCs, HMIs, and SCADA systems controlling production lines. Historically, each plant managed its own OT security — which meant some had none.
Elena’s design creates a standardised OT security architecture:
Network architecture: Every plant implements the Purdue model. The Level 3.5 DMZ is standardised — same firewall rules, same jump server configuration, same data historian replication pattern. Li Wei’s team creates deployment templates for consistency.
Monitoring: Defender for IoT sensors at each plant, with the cloud-connected management option. All alerts flow to Meridian’s central Sentinel instance. Elena’s SOC team (who previously only monitored IT systems) now has visibility into OT environments.
The critical discovery: Within the first week, Defender for IoT’s asset discovery reveals that one plant in Germany has a PLC directly accessible from the IT network — no DMZ, no firewall, no segmentation. A PLC controlling a paint booth’s air handling system. An attacker in the IT network could potentially manipulate air flow and pressure in a space where employees work.
“This is why passive discovery matters,” Elena tells Marcus Chen. “The plant manager didn’t even know this PLC had an IP address. It was configured 15 years ago and forgotten.”
Exam Strategy: IoT/OT Security Questions
SC-100 IoT/OT questions test whether you understand the unique constraints of industrial environments. Key patterns:
- “Cannot be patched” → compensating controls: network segmentation, virtual patching, monitoring, application allowlisting. Never answer “patch it” for OT systems.
- “Agentless” → Defender for IoT with passive network monitoring. If a question says “no software can be installed on devices,” this is the answer.
- “IT/OT boundary” → DMZ (Level 3.5 in the Purdue model). The answer is never “direct connection between IT and OT.”
- “Availability is the top priority” → OT context. Solutions must not disrupt operations. This rules out active scanning, forced reboots, or any control that could stop the process.
- “Shadow OT” or “unknown devices” → Asset discovery through Defender for IoT’s passive analysis. You can’t protect what you don’t know about.
- “Air-gapped” → Defender for IoT OT sensors with local console/CLI management and API-based integration with on-premises SIEM. Don’t recommend Azure-only solutions for air-gapped environments.
- Look for questions that combine IT and OT — e.g., “An attacker compromises an IT system and accesses the OT network.” The answer involves Sentinel correlation of IT and OT alerts.
A manufacturing company has PLCs controlling chemical mixing processes. These PLCs run firmware that hasn't been updated in 8 years, and the vendor no longer exists. The PLCs have known vulnerabilities but cannot be replaced for 2 years due to capital budget constraints. What security architecture should be designed?
An energy company wants to integrate OT security monitoring from 20 power substations into their existing Microsoft Sentinel SIEM. Some substations are in remote locations with intermittent internet connectivity. What deployment architecture should the security architect recommend?
🎬 Video coming soon
Next up: Network Security Architecture — design network segmentation, traffic filtering, and monitoring strategies for cloud and hybrid environments.