Most engineers think…
Many people assume OT asset discovery means running an IP scanner or deploying agents on industrial controllers — which is exactly what you cannot do on live PLCs and RTUs.
Microsoft Defender for IoT takes the opposite approach: the OT network sensor sits passively on a SPAN mirror port or TAP and uses deep packet inspection (DPI) to extract device attributes directly from protocol traffic. The result is a continuously updated inventory with vendor, model, firmware, OS, IP/MAC, protocols, and Purdue level — with zero active scanning and zero agents on the OT devices themselves. Every device that communicates is automatically discovered, including rogue and unmanaged devices that the CMDB never registered.
① Passive discovery — how the sensor builds the inventory
The OT network sensor connects to a SPAN/mirror port or TAP on the OT network switch and captures a copy of all traffic — without ever injecting packets. This is the foundation of Defender for IoT's agentless approach: DPI extracts device attributes from the natural protocol exchanges that PLCs, RTUs, HMIs, and other OT devices already make.
Every device that sends or receives a packet is added to the inventory automatically. The sensor watches for protocol banners, device-specific handshakes (e.g. Siemens S7 identity requests, BACnet device descriptions), and MAC vendor OUIs to build the richest possible device record. Because no traffic is injected, there is zero operational impact on fragile OT devices — a core requirement for industrial environments where even a brief network hiccup can halt a production line.
A device record is created on first observation and enriched continuously as more protocol exchanges are seen. The sensor runs detection locally at the edge, so inventory is available even in air-gapped / locally-managed deployments where no cloud connection exists.
Why does passive SPAN/TAP capture cause zero operational impact on OT devices?
② Device attributes & classification — what is captured
For each discovered device, Defender for IoT captures a rich attribute set: vendor and model (from MAC OUI and protocol headers), firmware version and OS (from DPI of management protocol exchanges), IP address and MAC address, open protocols observed (Modbus, DNP3, Siemens S7, EtherNet/IP/CIP, BACnet, OPC-DA/UA, IEC 60870-5-104, IEC 61850, Profinet, and more), and the auto-assigned Purdue level (0–5).
IT vs OT vs IoT classification
The sensor automatically classifies every device into one of three types. OT devices — PLCs, RTUs, DCS, SCADA HMIs, engineering workstations — are identified by industrial protocol use and OT vendor MAC OUIs. IoT devices — IP cameras, HVAC controllers, badge readers, printers — have a lighter protocol stack. IT devices — Windows/Linux servers, workstations, switches, Active Directory — use standard enterprise protocols. This three-way classification drives risk scoring, Purdue level placement, and alert prioritisation. The network device map visualises all nodes and their communication links, filterable by device type, Purdue level, subnet, or protocol — giving OT teams an interactive topology view of the entire OT network.
A switch feature that copies all traffic on monitored ports to the sensor — the passive capture mechanism that gives Defender for IoT full network visibility with zero OT impact.
Parsing packet payloads beyond IP/TCP headers to extract application-layer data — vendor, model, firmware, protocol commands — used to build each device record.
The interactive topology visualisation in the sensor or Defender portal showing every discovered device as a node, with communication links, filterable by Purdue level, protocol, or device type.
Triggered when the sensor sees a device it has never observed before — the primary mechanism for surfacing rogue and unmanaged devices in real time.
In an interview, listing all captured attributes — vendor, model, firmware, OS, IP, MAC, protocols, Purdue level, device type — shows you understand what makes passive DPI powerful. An active scanner can find IPs; DPI builds a full engineering profile of every device without touching it.
Which of the following is captured as a device attribute by the OT network sensor?
③ Rogue & unmanaged devices — what the CMDB missed
Because discovery is purely passive and covers every device that communicates on the monitored segment, Defender for IoT detects every asset — including those that were never registered in the organisation's CMDB or asset management system. Any device seen for the first time is flagged as a New device in the inventory and can trigger a new-asset alert for SOC review.
Common rogue device scenarios uncovered by the inventory: an unauthorised contractor's laptop plugged into the OT switch at Level 1, a personal Wi-Fi access point connected behind an HMI, an unsanctioned IP camera sharing the OT VLAN, or a duplicate IP from a stale device that was replaced but never decommissioned. The network device map makes these visually obvious — a new node with no authorised communication baseline stands out as an anomaly.
Cross-Purdue-level communication anomalies — for example a Level 1 PLC talking directly to a Level 4 enterprise server, bypassing the IT/OT DMZ at Level 3.5 — are also surfaced through the topology view and alert engine, making segmentation violations visible as soon as they happen.
Priya Nair, OT security engineer at Vidyut Power Pvt. Ltd. in Chennai, faces this
During a weekly Defender for IoT review, Priya sees a Windows laptop flagged as 'New device' at Purdue Level 1, communicating with two RTUs over Modbus. The CMDB has no record of this device.
A maintenance contractor plugged their personal laptop directly into the Level 1 OT switch without authorisation. The laptop is running Modbus polling software from a previous job.
In the Microsoft Defender portal, Device inventory, filter by 'New' status and Purdue Level 1. The laptop has no asset tag, no authorised owner, and its communication peers are production RTUs. The network device map shows a new node with direct links to Level 1 controllers.
Defender portal ▸ Device inventory ▸ Filter: New + Level 1 ▸ Network mapIsolate the laptop from the OT switch immediately. Investigate with the maintenance team — confirm the contractor and uninstall the Modbus software. Register all authorised maintenance devices in the CMDB before they connect, and set a policy alert for any new device appearing at Purdue Levels 0–2.
Re-check the network map: the laptop node shows no active communication links. The new-asset alert is closed after the investigation is documented and the CMDB is updated with the new control.
In practice, OT environments almost always have undocumented devices — contractor laptops, old PLCs never removed, shadow IoT. The inventory's new-asset flagging is one of the most operationally valuable features. Never dismiss it as a corner case: in OT, unmanaged devices are the norm, not the exception.
▶ Watch a rogue laptop get flagged in the OT inventory
How Defender for IoT passively detects and surfaces an unregistered device. Press Play for the healthy discovery path, then Break it to see the detection gap.
A maintenance engineer plugs an unregistered laptop into an OT switch at Level 1. How does Defender for IoT surface it?
④ Managing inventory at scale — cloud, sites & zones
In cloud-connected mode, device inventory from all sensors is synchronised to the Microsoft Defender portal, giving a single-pane view across every OT site in the organisation. Analysts can filter, search, and export the full inventory from one place, and Microsoft Sentinel receives device-context data through the native data connector — so alerts automatically include asset owner, device type, firmware, and Purdue level without manual lookup.
Defender for IoT organises sensors under a hierarchy of sites and zones. A site maps to a physical location (e.g. a substation, a factory floor, a hospital wing); zones subdivide a site by network segment or process area. The inventory view can be scoped by site/zone, enabling large organisations — a utility with many substations or a manufacturer with multiple plants — to delegate inventory management to local OT teams while giving the central SOC a unified view.
Air-gapped deployments
In locally-managed (air-gapped) mode the device inventory lives entirely on the sensor or the on-premises management console — no cloud sync. OT teams access it through the sensor's local web interface. This suits highly regulated environments where no outbound cloud traffic is permitted, though it means each site's inventory is managed separately.
When a Defender for IoT alert fires, pull up the device record first — firmware, Purdue level, communication peers, last-seen time. An alert on a known, fully-patched switch means something different from the same alert on an unmanaged rogue device at Level 1. The inventory is your context layer, not just an asset list.
An organisation has 12 OT sites that cannot connect to the cloud. How is device inventory managed in this scenario?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one sentence: what is the single most important reason Microsoft Defender for IoT uses passive DPI instead of active scanning for OT device discovery? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- SPAN / mirror port
- A switch feature that copies all traffic on monitored ports to a dedicated monitoring port — how the OT sensor receives a passive copy of all OT network traffic.
- Deep packet inspection (DPI)
- Parsing packet payloads beyond IP/TCP headers to extract application-layer data such as device vendor, model, firmware, and industrial protocol commands.
- OT device
- Operational technology device — PLC, RTU, DCS, SCADA HMI, engineering workstation — that directly controls or monitors industrial processes.
- IoT device
- Internet of Things device — IP camera, HVAC controller, badge reader — with a lighter protocol stack than OT controllers, classified separately by Defender for IoT.
- Purdue model
- A reference architecture for OT/ICS networks with Levels 0–5 defining device roles from field sensors (L0) to enterprise IT (L4/5), plus a Level 3.5 IT/OT DMZ.
- Network device map
- The interactive topology visualisation in the sensor or Defender portal showing all discovered devices as nodes with their communication links, filterable by Purdue level and device type.
- New-asset alert
- An alert triggered when the sensor observes a device it has never seen before — the primary mechanism for surfacing rogue and unmanaged devices.
- Sites and zones
- Defender for IoT's organisational hierarchy for grouping sensors and device inventory by physical site (location) and zone (network segment or process area).
📚 Sources
- Microsoft Learn — Microsoft Defender for IoT device inventory. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/device-inventory
- Microsoft Learn — OT network sensor overview and passive discovery architecture. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/architecture
- Microsoft Learn — Manage your OT device inventory from the Azure portal. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/how-to-manage-device-inventory-for-organizations
- Microsoft Learn — Purdue reference model and OT network segmentation in Defender for IoT. learn.microsoft.com/en-us/azure/defender-for-iot
- Microsoft Learn — OT threat monitoring in enterprise SOCs — alert types and device context. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/concept-supported-protocols
- Microsoft — Microsoft Defender for IoT product page. microsoft.com/en-us/security/business/iot/microsoft-defender-for-iot
What's next?
Got the inventory covered? Next, explore how Defender for IoT maps every device to the Purdue reference model (Levels 0–5), auto-detects cross-level segmentation violations, and enforces OT network segmentation policy.