Most engineers think…
Most people assume Microsoft Defender for IoT works like a classic cloud security service — traffic goes to Azure, Azure analyses it, Azure tells you what happened. That picture is wrong for OT, and it will cost you in an interview.
The OT network sensor is the intelligence. It sits at the edge, captures a SPAN or TAP copy of your plant traffic, and does all the deep-packet inspection locally — on-site, in real time, with zero raw data leaving your network. The Azure portal is the management and visibility layer, not the analysis engine. Understanding that split — edge intelligence, cloud management — is what lets you explain the architecture correctly, answer air-gap questions, and design the right deployment for a plant that cannot talk to the internet.
① The three building blocks — edge sensor, legacy console, cloud portal
Microsoft Defender for IoT is built from three components. The OT network sensor is an appliance or virtual machine deployed at the edge of your OT network. It connects to a SPAN port or TAP, captures all OT traffic passively, and runs deep-packet inspection (DPI) plus the five detection engines entirely on the sensor. Raw packets never leave the site. The sensor also has its own local web UI for direct management.
The second building block is the on-premises management console — a legacy aggregation server that collected alerts and device inventory from multiple air-gapped sensors into one on-site view. Microsoft is retiring this component; new deployments should use the cloud portal instead.
The third building block is the Azure / Microsoft Defender portal. This is the cloud control plane: it onboards sensors, manages RBAC, aggregates alerts and device inventory from all cloud-connected sensors, and connects natively to Microsoft Sentinel and Defender XDR for unified IT+OT SOC visibility. The architecture principle: edge intelligence, cloud management.
In every interview answer about Defender for IoT architecture, lead with this principle: the OT sensor is the intelligence (DPI, detection, inventory — all local), and the Azure portal is the management plane. Never say traffic goes to Azure for analysis — that is the wrong mental model for OT.
Where does Microsoft Defender for IoT actually analyse OT traffic?
② Cloud-connected vs locally-managed — two sensor modes
Every OT sensor deploys in one of two modes. A cloud-connected sensor has an outbound internet path to Azure. After passive DPI on the sensor, alert metadata and device-inventory records are pushed to the Azure portal. The sensor is onboarded, updated, and managed from the portal. Raw OT packets stay on-site — only structured data (alert type, device attributes, timestamps) travels to the cloud.
A locally-managed (air-gapped) sensor has no internet path. All data — alerts, inventory, forensics — stays on the sensor. Administrators reach it directly through the sensor's local web UI. Previously, multiple air-gapped sensors could be aggregated by the on-premises management console; now that the console is retiring, air-gapped sensors must each be accessed individually. Microsoft recommends moving to cloud-connected mode wherever connectivity is feasible.
How to choose
Choose cloud-connected when the site can safely route sensor metadata to Azure — it gives you the full portal experience, centralised updates, and Sentinel integration. Choose locally-managed only when regulatory or physical constraints make any internet path impossible (e.g. a classified facility or a substation with no WAN).
The edge appliance or VM — captures SPAN/TAP traffic, runs DPI and five detection engines on-site. No raw data ever leaves the plant.
The Azure/Defender portal — the control plane. Onboards sensors, manages RBAC, aggregates alerts + device inventory, connects to Sentinel and Defender XDR.
Site = physical location (plant, substation). Zone = network segment inside it. Together they scope alerts and RBAC across large multi-site OT estates.
Legacy multi-sensor aggregator for air-gapped estates. Microsoft is retiring it — new deployments should use cloud-connected mode and the Azure portal instead.
What is the main reason to choose locally-managed (air-gapped) sensor mode?
③ Sites, zones & RBAC — organising your OT estate
Defender for IoT organises sensors using a two-level hierarchy. A site maps to a physical location — a factory, a substation, a building. A zone is a network segment within that site — for example, the engineering workstation VLAN, the field-device network, or the safety PLC segment. Each sensor is assigned to one site and one zone when it is onboarded.
This hierarchy does two things. First, it scopes alerting — you can filter the alert queue by site or zone to see only what is relevant to your team. Second, it drives RBAC. In the Azure portal (Defender for IoT > Sites and Sensors) you assign Azure roles — Security Admin, Security Reader, or Contributor — at the subscription level or at the site level. A substation engineer can be a Security Reader for their site only, while a central SOC analyst sees everything.
The interview answer: sites and zones let one Defender for IoT subscription serve a large distributed OT estate — many plants, many teams — without every user seeing every alert. It is the organisational backbone of a multi-site OT security programme.
Sites and zones are not cosmetic. They are the mechanism that scopes RBAC — a user with a Security Reader role on Site A cannot see Site B's alerts. In a multi-plant OT programme this is critical for compliance and least-privilege. Always explain the RBAC implication, not just the naming hierarchy.
▶ Watch an OT alert travel from sensor to Sentinel
Step through the cloud-connected alert path. Press Play for the healthy flow, then Break it to see the most common failure.
A substation engineer should only see alerts from their own site. How do you enforce this?
④ End-to-end data flow — from SPAN port to Sentinel
Here is the complete alert path in the cloud-connected mode. The sensor connects to a SPAN/TAP on the OT switch and captures a passive copy of all traffic. The on-sensor DPI engine parses OT protocols (Modbus, S7, DNP3, EtherNet/IP, BACnet, and dozens more), builds a device inventory, runs the five detection engines, and raises an alert — all locally, in real time. The alert record (type, severity, device, timestamp, protocol detail) is pushed over an encrypted outbound connection to the Azure portal.
In the portal, the alert appears in the Defender for IoT alert queue, scoped to the correct site/zone, and the device is added to or updated in the asset inventory. From there, the Microsoft Sentinel data connector pulls the alert into Sentinel as a security incident, where OT-specific analytics rules, workbooks, and SOAR playbooks can act on it. The SOC sees an IT+OT incident in the same Sentinel workspace — no separate console needed.
For sensor software updates, the flow reverses: Microsoft publishes an update package to the portal, which the cloud-connected sensor downloads and applies on approval. Air-gapped sensors require the administrator to download the package and upload it manually to the sensor's local web UI.
Priya at IndusGrid Power in Nagpur faces this
Priya has deployed three sensors — two at air-gapped substations and one cloud-connected at the control room. She can only see the control-room sensor alerts in the Azure portal; the substation sensors are invisible there.
Air-gapped (locally-managed) sensors do not push data to Azure — they store everything on-sensor and require direct access via the sensor web UI.
In the Azure portal, Defender for IoT > Sites and Sensors, only the cloud-connected control-room sensor appears. The substation sensors are locally-managed and have no portal presence.
Azure Portal > Defender for IoT > Sites and Sensors + Sensor local web UI (per substation)Option A: if connectivity is now acceptable, re-onboard the substation sensors as cloud-connected — alerts and inventory will flow to the portal. Option B: keep them air-gapped and access each sensor's local web UI directly for alert triage and inventory.
After switching one substation sensor to cloud-connected mode, its device inventory and alerts appear in the Azure portal within minutes, scoped to the correct site and zone.
After onboarding, check Azure Portal > Defender for IoT > Sites and Sensors — the sensor should show a green Connected status. If it shows Disconnected, the outbound HTTPS path to the Defender for IoT Azure endpoints is blocked. A disconnected cloud-connected sensor still detects locally but its alerts will not reach the portal or Sentinel.
An analyst wants OT alerts from Defender for IoT to appear automatically in Microsoft Sentinel. What must be configured?
🤖 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 line: what is the difference between a cloud-connected and a locally-managed Defender for IoT sensor? 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
- OT Network Sensor
- The edge appliance or VM that captures SPAN/TAP traffic and runs DPI and detection entirely locally — no raw data ever leaves the site.
- Cloud-connected sensor
- A Defender for IoT sensor with internet access that pushes alert metadata and device inventory to the Azure portal and is managed from there.
- Locally-managed sensor
- A Defender for IoT sensor with no cloud path (air-gapped) — all data stays on-site and the admin uses the sensor's local web UI.
- On-premises management console
- Legacy multi-sensor aggregation server for air-gapped estates — Microsoft is retiring it in favour of cloud-connected management.
- Sites and zones
- Defender for IoT's organisational model: site = physical location, zone = network segment within it. Used to scope alerts and RBAC.
- RBAC (Role-Based Access Control)
- Granting users only the permissions their role needs, scoped in the Azure portal to the Defender for IoT subscription or to specific sites.
- SPAN/TAP
- Passive methods to copy OT network traffic to the sensor — SPAN mirrors a switch port; TAP splices the cable. Both give the sensor read-only access with zero device impact.
- Sentinel data connector
- The built-in integration that pulls Defender for IoT alerts from the Azure portal into Microsoft Sentinel as security incidents for the unified IT+OT SOC.
📚 Sources
- Microsoft Learn — Microsoft Defender for IoT documentation overview. learn.microsoft.com/en-us/azure/defender-for-iot/
- Microsoft Learn — Defender for IoT system architecture — sensor, on-premises management console, and Azure portal. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/architecture
- Microsoft Learn — Deploy OT monitoring — cloud-connected vs locally-managed sensors. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/ot-deploy/
- Microsoft Learn — Sites and zones in Microsoft Defender for IoT. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/manage-sites-and-zones-on-an-ot-network
- Microsoft Learn — On-premises management console retirement announcement. learn.microsoft.com/en-us/azure/defender-for-iot/organizations/legacy-central-management/
- Microsoft Security Blog — Microsoft acquires CyberX to accelerate IoT security (2020). microsoft.com/en-us/security/blog
What's next?
Got the architecture? Next, go deep on the OT network sensor itself — passive SPAN/TAP monitoring, deep-packet inspection of Modbus/S7/DNP3/EtherNet/IP, physical vs virtual sensor, and how to size it for your plant.