Microsoft Defender for IoT OT Sensors — Passive DPI & Zero-Impact Monitoring

① Why OT monitoring must be passive — SPAN, TAP & agentless design

Industrial controllers — PLCs, RTUs and HMIs — are not servers. They run real-time operating systems with deterministic timing, vendor-specific firmware, and zero tolerance for unexpected network traffic. An unsolicited packet at the wrong moment can stall a ladder-logic scan cycle, trip an emergency shutdown, or corrupt a process value. That is why Microsoft Defender for IoT's OT network sensor is entirely passive and agentless: it never installs software on OT devices and never sends a single packet into the OT network.

Instead, the sensor receives a copy of traffic via one of two mechanisms. A SPAN port (port mirror) is a software feature on a managed switch: you configure selected ports or VLANs to be mirrored to a dedicated monitor port, and the sensor plugs into that port. It is easy to set up and costs nothing extra, but can drop packets under heavy switch load. A TAP (Test Access Point) is a passive hardware device spliced inline on the fibre or copper — it creates a guaranteed, full-fidelity copy regardless of traffic volume, with no dependency on switch software. TAPs are preferred for critical, high-throughput OT segments.

Either way, the OT network sees nothing. The PLCs keep polling their sensors, the HMIs keep displaying process data, and the SCADA server keeps writing setpoints — completely unaware that a security sensor is reading every packet. This zero operational impact guarantee is the foundation of the whole architecture.

② Inside the OT sensor — DPI, edge analytics & detection engines

Once traffic arrives at the sensor via SPAN or TAP, the sensor's deep packet inspection (DPI) engine decodes it far beyond IP headers. For a Modbus packet it reads the function code (Read Coils vs Write Single Register), the register address, and the value. For a Siemens S7 packet it reads the CPU command type — including dangerous commands like Stop CPU. For an IEC 60870-5-104 packet it reads the ASDU type and cause of transmission. This command-level visibility is what makes OT DPI qualitatively different from flow monitoring or basic port inspection.

Five detection engines, all running at the edge

All detection logic runs locally on the sensor — no cloud round-trip is needed to generate an alert. The five engines are: Protocol Violation (malformed or out-of-spec packets), Policy Violation (communications that should not happen — e.g. a remote IP writing to a PLC that should only accept local commands), Malware (industrial) (known ICS malware indicators), Anomaly (deviations from the learned baseline — new devices, new protocols, new peer relationships), and Operational (process-layer events such as a PLC mode change or an unusual setpoint write). The sensor also runs a behavioural self-learning phase on first deployment to build the baseline before enforcement begins.

OT and ICS protocols parsed include Modbus, DNP3, Siemens S7/S7Plus, EtherNet/IP (CIP), BACnet, OPC (DA/UA), IEC 60870-5-104, IEC 61850 (MMS/GOOSE), Profinet, Honeywell, and many more. Custom or proprietary protocols can be added via the Horizon open development environment (ODE) SDK without waiting for a Microsoft update.

③ Where sensors sit — Purdue placement, SPAN vs TAP & deployment modes

Sensor placement follows the Purdue reference model. The sweet spot is at the Level 2 aggregation switch — the switch that connects Level 1 PLCs/RTUs upward to Level 2 HMIs and engineering workstations. Mirroring this switch's OT VLAN captures all control-plane traffic in that zone. For a site with multiple isolated OT segments (e.g. a utilities zone, a production zone and a safety instrumented system zone) you deploy one sensor per zone, each connected to its own aggregation switch SPAN port or TAP.

Sensors are organised in the Microsoft Defender portal under Sites and Zones. A Site maps to a physical location (a plant, a substation, a building). A Zone maps to a logical network segment within that site. This hierarchy drives RBAC (an OT engineer at the Vadodara plant should see only Vadodara alerts) and scoping of alerts and inventory.

Two deployment modes exist. Cloud-connected: the sensor sends telemetry, alerts and device inventory to the Azure / Microsoft Defender portal in near-real-time; updates and threat intelligence packages from Microsoft's Section 52 / MSTIC team flow back automatically. Locally managed (air-gapped): the sensor operates fully on-prem with no internet connectivity — required for classified environments, critical national infrastructure, or sites with a strict no-cloud policy; managed from the on-premises management console (note: Microsoft is retiring the on-prem console and moving management to the cloud for new deployments).

④ Physical vs virtual, sizing, the learning period & alert tuning

Sensors come in two forms. A physical appliance is a dedicated rack-unit server spec'd by Microsoft for OT deployments — chosen when you need certified hardware throughput for high-bandwidth OT backbones, when adding a new virtual host to the OT floor is unacceptable, or when the environment demands a purpose-built appliance. A virtual sensor (VM) runs on VMware ESXi, Hyper-V, or as an Azure VM — lower CAPEX, easier to pilot, and suitable for lower-bandwidth segments, provided the hypervisor host can forward the SPAN traffic at full line rate without dropping packets.

Sizing & the learning period

Sizing is governed by two factors: monitored bandwidth (choose the sensor tier whose throughput ceiling exceeds the peak bandwidth of the mirrored segment) and device count (the sensor builds an inventory; a very large OT floor with thousands of devices needs higher-tier hardware or multiple sensors). After first deployment, the sensor enters a learning period — it observes normal OT communications, builds a baseline of device relationships and protocol patterns, and keeps detection engines in informational mode. When learning is complete the engines switch to active alerting. Skipping or cutting short the learning period is the single most common cause of alert storms in new Defender for IoT deployments. Validate the learning period is complete before promoting alerts to your SOC workflow.