Microsoft Defender for IoT — Agentless OT/ICS NDR & Azure-Managed Visibility

① What Microsoft Defender for IoT actually is — agentless OT/ICS NDR

Microsoft Defender for IoT is an agentless OT/ICS/IoT network detection and response (NDR) platform managed from the Azure and Microsoft Defender portal. The word agentless is the whole point: there is nothing installed on PLCs, RTUs, HMIs, or SCADA servers. A passive OT network sensor mirrors traffic from a SPAN port or TAP and does all the work, with zero operational impact on fragile production equipment.

The technology came from Microsoft's 2020 acquisition of CyberX, an Israeli OT security pioneer. CyberX had already built five detection engines, deep OT protocol parsing, and a behavioural self-learning baseline — Microsoft rebranded it, integrated it into the Azure security stack, and extended it with Sentinel and Defender XDR connectivity.

The two buyer personas are the OT team (engineers who run the plant and want a live asset register and anomaly alerts without disrupting production) and the IT/SOC team (who want OT visibility inside the same Microsoft security tools they already use for IT). Defender for IoT bridges both.

② The three building blocks — sensor, management console & cloud portal

Microsoft Defender for IoT has three architectural pieces. The OT network sensor is the edge appliance — physical hardware or a virtual machine — deployed at each industrial site. It captures traffic from the SPAN/TAP, runs deep packet inspection and all five detection engines locally, builds the device inventory, and queues alerts. It does its job even when cut off from the cloud.

Management and cloud layers

The on-premises management console was the legacy aggregation tier for multi-sensor, air-gapped estates — it consolidated data from many sensors without cloud connectivity. Microsoft is retiring it and moving that function to the cloud. The Azure / Microsoft Defender portal is the cloud hub going forward: central device inventory, alert management, site and zone configuration, RBAC, sensor updates, and the integration point for Sentinel and Defender XDR.

Sensors operate in two modes: cloud-connected (data streams to the portal in near real-time) and locally-managed / air-gapped (the sensor runs standalone with no cloud path — for sites where regulations or safety rules prohibit internet connectivity). In both cases the sensor itself does the heavy lifting at the edge.

③ How passive detection works — DPI, five engines & self-learning

The OT network sensor does deep packet inspection (DPI) of all mirrored traffic. It parses dozens of OT/ICS protocols natively: Modbus, DNP3, Siemens S7/S7Plus, EtherNet/IP (CIP), BACnet, OPC DA/UA, IEC 60870-5-104, IEC 61850 (MMS/GOOSE), Profinet, Honeywell, Emerson, and many more. Custom or proprietary protocols can be parsed with the Horizon open development environment (ODE) SDK.

Five detection engines

Detection runs through five engines inherited from CyberX. Protocol Violation catches malformed or out-of-spec protocol use. Policy Violation flags communications that break defined rules (e.g. an HMI talking to a device in a zone it shouldn't reach). Malware (industrial) matches known industrial malware signatures. Anomaly relies on behavioural self-learning — the sensor spends a learning period baselining normal OT communications, then in operational mode any deviation generates an alert. Operational catches process-level anomalies such as unexpected command sequences or out-of-range values.

The device inventory is a passive by-product of DPI: every device seen on the wire is catalogued with vendor, model, firmware version, OS, IP and MAC addresses, open protocols, and Purdue level — all without sending a single active query to the device.

④ Purdue model, Microsoft Sentinel & the unified SOC

Defender for IoT auto-maps every discovered device to its Purdue reference model level: Level 0 (physical process — sensors, actuators), Level 1 (control — PLCs, RTUs), Level 2 (supervisory — HMIs, SCADA), Level 3 (site operations), Level 3.5 (IT/OT DMZ), Level 4/5 (enterprise/cloud). Cross-level violations — a PLC at Level 1 suddenly communicating with an enterprise server at Level 4, for example — are flagged as segmentation violations, a critical ICS attack signal.

The Microsoft Sentinel data connector streams Defender for IoT device inventory and alerts into Sentinel automatically. Out-of-the-box OT analytics rules, workbooks, and SOAR playbooks let a SOC correlate IT and OT incidents in the same console. Microsoft Defender XDR adds unified incident management across endpoints, identity, email, cloud, and OT. OT-specific threat intelligence packages from Microsoft's Section 52 / MSTIC team are pushed automatically to sensors.

Third-party integrations cover SIEM, SOAR, ticketing, and firewalls — so Defender for IoT also works in non-Microsoft SOC stacks. Vulnerability management matches discovered devices to known CVEs, produces risk-assessment reports, and simulates attack paths to prioritise compensating controls where patching a PLC is simply not an option.