# OT Asset Discovery & Device Inventory — Microsoft Defender for IoT Source: https://ai.techclick.in/blog_microsoft_defender_iot_device_inventory Markdown: https://ai.techclick.in/blog_microsoft_defender_iot_device_inventory.md Publisher: Techclick Infosec Pvt Ltd Learn how Microsoft Defender for IoT passively discovers every OT, IoT and IT device — capturing vendor, model, firmware, IP, MAC, protocols and Purdue level — plus the network map and rogue-device detection. OT Asset Discovery & Device Inventory — Microsoft Defender for IoT student learning map A visual study map for OT Asset Discovery & Device Inventory — Microsoft Defender for IoT showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP OT Asset Discovery & Device Inventory —... Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Passive discovery — how the... 4. Practice ② Device attributes &... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. Legend Sensor & flow arrows Pipeline stage labels Diagram heading Stage detail text Canvas panel Figure 1 — How passive discovery builds a device record The sensor captures protocol traffic via SPAN/TAP, runs DPI, and continuously enriches each device record in the inventory. - How passive discovery builds a device record SPAN / TAP copy traffic passively DPI decode extract attributes Device record created on first seen Continuous enrich firmware, protocols Inventory cloud or local The sensor captures protocol traffic via SPAN/TAP, runs DPI, and continuously enriches each device record in the inventory. Quick check · Q1 of 10 · Understand Why does passive SPAN/TAP capture cause zero operational impact on OT devices? a) Because it encrypts all traffic before analysing it b) Because it only monitors at the application layer c) Because no packets are injected — it only reads a copy of traffic already flowing d) Because it installs a read-only agent on each device Correct: c. SPAN/TAP creates a copy of existing traffic. The sensor reads that copy passively and injects nothing onto the OT network, so PLCs, RTUs, and HMIs see no additional load or unexpected packets. 👉 So far: Passive SPAN/TAP + DPI = complete device discovery with zero agents and zero OT impact. Every communicating device is automatically added to the inventory. ## ② 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. Figure 2 — Device attribute layers captured by Defender for IoT DPI builds a device record from identity fields up through communication context. Device attribute layers captured by Defender for IoT Identity Vendor, model, IP, MAC address Software Firmware version, OS, open ports Protocol & Purdue Observed protocols, Purdue level (0–5), device type DPI builds a device record from identity fields up through communication context. Figure 3 — OT, IoT & IT classification — one sensor, three types The OT network sensor classifies every communicating device into one of three types based on protocol and MAC OUI signatures. OT, IoT & IT classification — one sensor, three types OT Sensor DPI classifier OT — PLC/RTU OT — SCADA/HMI IoT — Camera IoT — HVAC/Badge IT — Server/PC IT — Switch/Router The OT network sensor classifies every communicating device into one of three types based on protocol and MAC OUI signatures. 📡 SPAN / mirror port tap to flip 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. 🔬 Deep packet inspection tap to flip Parsing packet payloads beyond IP/TCP headers to extract application-layer data — vendor, model, firmware, protocol commands — used to build each device record. 🗺️ Network device map tap to flip 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. 🚨 New-asset alert tap to flip Triggered when the sensor sees a device it has never observed before — the primary mechanism for surfacing rogue and unmanaged devices in real time. Name the attribute set 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. Quick check · Q2 of 10 · Remember Which of the following is captured as a device attribute by the OT network sensor? a) Windows login event logs b) Firmware version and observed OT protocols c) Cloud storage bucket names d) DNS query history from the IT LAN Correct: b. Defender for IoT captures vendor, model, firmware, OS, IP/MAC, open protocols, Purdue level, and device type (OT/IoT/IT) — all derived from passive DPI of protocol traffic, not from host logs. 👉 So far: Each device record captures: vendor, model, firmware, OS, IP/MAC, observed protocols, Purdue level (0–5), and device type (OT / IoT / IT). The network device map shows all nodes and their communication links. ## ③ 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. Figure 4 — Known asset vs rogue device — how Defender for IoT sees them Authorised assets have a known baseline; rogue devices appear as new, unclassified nodes in the inventory and on the network map. Known asset vs rogue device — how Defender for IoT sees them Authorised asset Registered in CMDB Known vendor, model, firmware Expected communication peers Purdue level assigned at Rogue / unmanaged Flagged as 'New device' Unknown or unexpected vendor Communicates with OT controllers Triggers new-asset alert for SOC Authorised assets have a known baseline; rogue devices appear as new, unclassified nodes in the inventory and on the network map. 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. Likely cause 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. Diagnosis 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 map Fix Isolate 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. Verify 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. 'Rogue devices are rare' under-sell 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. ① Laptop connects An unregistered contractor laptop is plugged into the Level 1 OT switch and begins sending Modbus poll requests to a PLC. ▼ ② SPAN captures The OT network sensor's SPAN port receives a copy of all traffic — the laptop's packets are included automatically, no configuration change needed. ▼ ③ DPI identifies Deep packet inspection extracts the laptop's IP/MAC, sees Modbus traffic, assigns Purdue Level 1, and classifies it as an IT device on an OT segment. ▼ ④ Inventory flags it The device appears in the inventory as 'New device' and a new-asset alert is raised in the Defender portal for the SOC to review. Press Play to step through the rogue-device discovery path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply A maintenance engineer plugs an unregistered laptop into an OT switch at Level 1. How does Defender for IoT surface it? a) It blocks the laptop's traffic at the firewall b) It sends an agent install request to the laptop c) It flags the laptop as a new device and can raise a new-asset alert d) It ignores IT devices on OT segments Correct: c. Every device that communicates is discovered passively. An unregistered device is flagged 'New device' in the inventory and triggers a new-asset alert for SOC review — regardless of whether it is an IT, OT, or IoT type. 👉 So far: Every new device the sensor has not seen before is flagged as 'New device' and triggers a new-asset alert — the primary mechanism for surfacing rogue and unmanaged assets in real time. ## ④ 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. Figure 5 — Inventory sync — sensor to Defender portal to Sentinel Cloud-connected sensors push device inventory to the Defender portal; Sentinel ingests asset context for richer OT alerts. Inventory sync — sensor to Defender portal to Sentinel OT Sensor discovers devices Defender portal unified inventory Sites & zones scope by location Sentinel connector asset context in alerts Cloud-connected sensors push device inventory to the Defender portal; Sentinel ingests asset context for richer OT alerts. Check inventory before responding to alerts 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. Quick check · Q4 of 10 · Analyze An organisation has 12 OT sites that cannot connect to the cloud. How is device inventory managed in this scenario? a) Inventory is unavailable without cloud connectivity b) Inventory lives on each sensor and the on-premises management console, accessed locally c) Each sensor sends inventory by email to the SOC d) All sites must be merged into one cloud-connected sensor Correct: b. In locally-managed (air-gapped) mode the device inventory is stored on the sensor or the on-premises management console and accessed through the sensor's local web interface — no cloud sync is required. 👉 So far: Cloud-connected sensors sync inventory to the Defender portal, scoped by sites and zones. Air-gapped sites keep inventory local. Sentinel ingests device context to enrich OT alerts. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. How does Defender for IoT discover OT devices without installing agents? What device attributes does the sensor capture per device? How does Defender for IoT tell an OT device from an IoT or IT device? What is the network device map and what can it show? How does the inventory surface rogue or unmanaged devices? How does inventory management work across many sites? 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. Q5 · Remember Which capture method does the OT network sensor use to achieve passive, agentless discovery? a) Active ICMP ping sweep of all IP ranges b) SNMP polling of each switch at five-minute intervals c) SPAN/mirror port or TAP that copies all OT switch traffic to the sensor d) An endpoint agent installed on every PLC and RTU Correct: c. Defender for IoT uses a SPAN/mirror port or TAP to receive a copy of all OT network traffic passively. No packets are injected, no agents are installed, and OT devices see no additional load. Q6 · Understand A Siemens S7-300 PLC is discovered by the sensor. Which device type classification will it receive? a) IT device, because it has an Ethernet port b) IoT device, because it is network-connected c) OT device, because it uses industrial protocols and a known OT vendor MAC OUI d) Unknown, until an agent is installed Correct: c. OT devices are identified by industrial protocol use (e.g. Siemens S7) and OT vendor MAC OUIs. A Siemens S7-300 PLC will be classified OT and assigned to an appropriate Purdue level automatically. Q7 · Apply You want to see which Level 1 PLCs are communicating directly with Level 4 enterprise servers in your OT environment. Where do you look? a) The Windows Event Log on the enterprise servers b) The network device map filtered by Purdue level and communication links c) The Azure Monitor metrics for PLC CPU usage d) The Defender for Endpoint quarantine queue Correct: b. The network device map in the sensor or Defender portal shows all discovered nodes and their communication links. Filtering by Purdue level makes cross-level connections — Level 1 to Level 4 — visually obvious as topology anomalies. Q8 · Understand What happens in the Defender for IoT inventory when the sensor observes a device it has never seen before? a) It blocks the device at the nearest firewall automatically b) It flags the device as 'New device' and can raise a new-asset alert for SOC review c) It skips the device until a second observation confirms it d) It requests the device to register itself via SNMP Correct: b. New devices are flagged immediately in the inventory and can trigger a new-asset alert. This is the primary mechanism for surfacing rogue and unmanaged devices — no manual CMDB check required. Q9 · Analyze A large utility has 20 OT substations, some with no internet access. How should they manage device inventory across all sites? a) Deploy one central sensor at headquarters and cable all substations to it b) Accept that air-gapped sites cannot have a device inventory c) Install endpoint agents on every OT device at air-gapped sites d) Use cloud-connected sensors where connectivity permits and locally-managed sensors for air-gapped sites, with sites and zones to organise the view Correct: d. Defender for IoT supports both cloud-connected and locally-managed (air-gapped) deployment modes. Cloud-connected sensors sync to the Defender portal; air-gapped sensors maintain inventory locally. The sites and zones hierarchy organises the inventory across both modes. Q10 · Evaluate Which statement best explains why passive DPI-based discovery is preferred over active scanning in OT environments? a) Active scanning produces more complete results faster b) Passive DPI is cheaper to license c) Active scanning injects traffic that can crash or disrupt fragile PLCs, RTUs, and HMIs that were never designed for IT-style probing d) Active scanning cannot detect IP addresses Correct: a. OT devices are engineered for reliability in industrial processes, not for responding to IT-style network scans. Active scanning can cause PLCs and RTUs to fault, restart, or drop control loops. Passive DPI never injects traffic, eliminating this risk entirely. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 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. Compare with expert answer Expert version: OT devices — PLCs, RTUs, DCS — are engineered for reliability in industrial control loops, not for tolerating IT-style network probes; an active scan can cause a controller to fault, restart, or drop a control output, disrupting a live process. Passive DPI from a SPAN port or TAP reads a copy of traffic that is already flowing, extracts vendor, model, firmware, protocols, and Purdue level from natural protocol exchanges, and builds a complete engineering-grade inventory without ever injecting a single packet onto the OT network. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Defender for IoT at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt