# Microsoft Defender for IoT Architecture — OT Sensor, Cloud Portal & the Alert Path Source: https://ai.techclick.in/blog_microsoft_defender_iot_architecture Markdown: https://ai.techclick.in/blog_microsoft_defender_iot_architecture.md Publisher: Techclick Infosec Pvt Ltd A clear interactive guide to Microsoft Defender for IoT architecture (2026): the OT network sensor at the edge, the retiring on-prem management console, and the Azure cloud portal — cloud-connected vs air-gapped sensors, sites and zones, RBAC, and the end-to-end alert data flow. Microsoft Defender for IoT Architecture — OT Sensor, Cloud Portal & the Alert Path student learning map A visual study map for Microsoft Defender for IoT Architecture — OT Sensor, Cloud Portal & the Alert Path showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Microsoft Defender for IoT Architecture — OT Sensor,... 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 ① The three building blocks — edge... 4. Practice ② Cloud-connected vs... 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… 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 . Legend Royal & arrows — sensor / passive tap Electric — stage & node labels Deep navy — diagram heading Indigo — air-gapped mode Mist — canvas panel Figure 1 — Three building blocks Microsoft Defender for IoT: the OT sensor does the work at the edge; the cloud portal manages everything; the on-prem console is the retiring middle layer. - Three building blocks Azure Portal Cloud control plane — alerts, RBAC, updates On-Prem Console Legacy air-gap aggregator (retiring) OT Network Sensor Edge — DPI, detection, local inventory Microsoft Defender for IoT: the OT sensor does the work at the edge; the cloud portal manages everything; the on-prem console is the retiring middle layer. Edge does the work, cloud manages 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. Quick check · Q1 of 10 · Understand Where does Microsoft Defender for IoT actually analyse OT traffic? a) In Azure, after packets are uploaded to the cloud b) On the OT network sensor at the edge — raw data never leaves the site c) In the on-premises management console d) In Microsoft Sentinel after ingestion Correct: b. The OT sensor is the intelligence — it captures SPAN/TAP traffic and runs DPI and detection entirely locally. Only structured alert metadata is sent to Azure; raw packets stay on-site. 👉 So far: Three building blocks: OT sensor (edge, DPI + detection, local), on-prem management console (legacy, retiring), Azure portal (cloud control plane). Principle: edge intelligence, cloud management. ## ② 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). Figure 2 — Cloud-connected vs air-gapped Both modes run the same DPI and detection locally; they differ only in how the data gets to the administrator. Cloud-connected vs air-gapped Cloud-Connected Managed from Azure portal Alerts + inventory to Azure Auto-updates from portal Integrates with Sentinel Air-Gapped (Locally-Managed) Admin uses sensor web UI All data stays on-site Manual update package upload No cloud path — max isolation Both modes run the same DPI and detection locally; they differ only in how the data gets to the administrator. Figure 3 — How sensor updates flow Cloud-connected sensors get updates from the portal; air-gapped sensors need a manual package upload. How sensor updates flow Microsoft publishes update Azure Portal package available Cloud Sensor downloads + applies Air-gap Sensor manual upload needed Cloud-connected sensors get updates from the portal; air-gapped sensors need a manual package upload. 📡 OT Network Sensor tap to flip The edge appliance or VM — captures SPAN/TAP traffic, runs DPI and five detection engines on-site. No raw data ever leaves the plant. ☁️ Cloud Portal tap to flip The Azure/Defender portal — the control plane. Onboards sensors, manages RBAC, aggregates alerts + device inventory, connects to Sentinel and Defender XDR. 🏭 Sites and Zones tap to flip Site = physical location (plant, substation). Zone = network segment inside it. Together they scope alerts and RBAC across large multi-site OT estates. 🖥️ On-Prem Console tap to flip Legacy multi-sensor aggregator for air-gapped estates. Microsoft is retiring it — new deployments should use cloud-connected mode and the Azure portal instead. Quick check · Q2 of 10 · Remember What is the main reason to choose locally-managed (air-gapped) sensor mode? a) It is cheaper than cloud-connected mode b) It integrates better with Microsoft Sentinel c) The site has no internet path and data must not leave d) Updates are faster in air-gapped mode Correct: c. Locally-managed mode exists for sites where regulatory or physical constraints prohibit any internet path. Cloud-connected is preferred wherever connectivity is feasible. 👉 So far: Cloud-connected = metadata pushed to Azure, managed from portal, auto-updates, Sentinel-ready. Locally-managed = all data on-site, sensor web UI only, manual updates. Choose air-gapped only when no internet path is possible. ## ③ 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. Figure 4 — Sites & zones hub Every sensor is assigned to a site and zone; RBAC is scoped there, so each team sees only their part of the estate. Sites & zones hub Azure Portal RBAC + Alerts Site: Plant A Zone: Field PLCs Zone: Eng WS VLAN Site: Substation B Zone: Safety PLCs Zone: HMI Segment Every sensor is assigned to a site and zone; RBAC is scoped there, so each team sees only their part of the estate. 'Sites and zones are just labels' 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. ① SPAN/TAP The sensor passively copies all traffic from the OT switch — PLCs, HMIs, engineering workstations — with zero operational impact. ▼ ② On-sensor DPI The sensor parses OT protocols, builds device inventory, runs the five detection engines, and raises an alert entirely on-device. ▼ ③ Azure Portal Alert metadata (type, severity, device, timestamp) is pushed encrypted to the Azure portal — raw packets stay on-site. ▼ ④ Sentinel The Defender for IoT data connector ingests the alert into Sentinel as a security incident — OT analytics rules and SOAR playbooks fire. Press Play to step through the cloud-connected alert path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply A substation engineer should only see alerts from their own site. How do you enforce this? a) Assign them a Security Reader role scoped to their site in the Azure portal b) Give them admin on all sensors and trust them to self-filter c) Use the on-premises management console for their site only d) Disable the alert queue for all other sites globally Correct: a. RBAC in the Azure portal lets you scope roles — Security Reader, Security Admin — to a specific site, so the substation engineer only sees alerts and inventory for their site. 👉 So far: Site = physical location. Zone = network segment inside it. RBAC is scoped to sites in the Azure portal — this is how you enforce least-privilege visibility across a distributed OT estate. ## ④ 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. Figure 5 — Alert path — SPAN port to Sentinel The sensor does all the work locally; only alert metadata travels to Azure; Sentinel pulls it in for the unified SOC. Alert path — SPAN port to Sentinel SPAN/TAP passive traffic copy On-sensor DPI OT protocol parse Alert raised local detection engine Azure Portal metadata pushed Sentinel IT+OT incident The sensor does all the work locally; only alert metadata travels to Azure; Sentinel pulls it in for the unified SOC. 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. Likely cause 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. Diagnosis 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) Fix 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. Verify 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. Check sensor Connected status first 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. Quick check · Q4 of 10 · Analyze An analyst wants OT alerts from Defender for IoT to appear automatically in Microsoft Sentinel. What must be configured? a) A manual CSV export scheduled from the sensor web UI b) An on-premises management console as a Sentinel gateway c) Air-gapped sensor mode for maximum data fidelity d) The Microsoft Sentinel data connector for Defender for IoT Correct: d. The Microsoft Sentinel data connector pulls alerts from cloud-connected Defender for IoT sensors into Sentinel as security incidents, enabling OT analytics rules and SOAR playbooks in the same workspace as IT alerts. 👉 So far: Alert path: SPAN/TAP → on-sensor DPI → alert raised locally → metadata pushed to Azure portal → Sentinel data connector pulls it in → IT+OT incident in the unified SOC. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What are the three building blocks of Microsoft Defender for IoT? What is the difference between cloud-connected and locally-managed sensors? Why is Microsoft retiring the on-premises management console? How do sites and zones work, and why do they matter for RBAC? Does raw OT traffic ever leave the site? How does the Sentinel integration work? 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 component in Defender for IoT is being retired by Microsoft? a) The OT network sensor appliance b) The on-premises management console c) The Azure/Defender portal d) The Microsoft Sentinel data connector Correct: b. Microsoft is retiring the on-premises management console (legacy aggregation layer) and urging customers to use cloud-connected sensors managed from the Azure portal instead. Q6 · Understand What data travels from a cloud-connected OT sensor to the Azure portal? a) Raw SPAN/TAP packets for cloud analysis b) Nothing — all data stays on the sensor c) Alert metadata and device-inventory records (not raw packets) d) Encrypted PLC ladder-logic backups Correct: c. Cloud-connected sensors push structured alert metadata and device-inventory records to Azure. Raw OT packets are never sent — all DPI and detection run locally on the sensor. Q7 · Apply A Defender for IoT sensor at a remote plant cannot connect to the internet. Which mode should it run in? a) Cloud-connected mode via a proxy server b) Locally-managed (air-gapped) mode, accessed via the sensor local web UI c) It cannot be deployed without internet access d) On-premises management console mode only Correct: b. Locally-managed (air-gapped) mode is designed for sites with no internet path — all data stays on-sensor and the admin uses the sensor web UI directly. Q8 · Analyze Why is it accurate to say Defender for IoT uses 'edge intelligence, cloud management'? a) Because Azure does the DPI and the sensor just forwards packets b) Because the sensor and cloud portal are the same software product c) Because DPI and detection run on the sensor locally, while the Azure portal handles onboarding, RBAC, aggregation, and integrations d) Because the on-prem console is hosted in the Azure cloud Correct: c. The edge sensor is the intelligence — it runs all DPI and detection locally. The Azure portal is the management and visibility layer. This split protects operational data and allows air-gapped deployments. Q9 · Evaluate An OT team wants the substation security engineer to see only substation alerts, not factory alerts. Best approach? a) Assign the engineer a Security Reader role scoped to the substation site in the Azure portal b) Give the engineer a global Security Admin role and trust them to filter manually c) Use the on-premises management console per site for isolation d) Deploy a separate Azure subscription for each site Correct: a. RBAC scoped to a specific site in the Azure portal is the correct, least-privilege approach — the engineer gets Security Reader for their substation site only, with no workarounds needed. Q10 · Evaluate An analyst notices a cloud-connected sensor shows Disconnected in the Azure portal and no new alerts appear in Sentinel. Most likely cause? a) The Sentinel workspace was accidentally deleted b) The sensor hardware has completely failed c) Sensor is in air-gapped mode — this is expected behaviour d) The outbound HTTPS path from the sensor to the Defender for IoT Azure endpoints is blocked by a firewall Correct: d. A Disconnected status on a cloud-connected sensor almost always means a firewall rule is blocking the outbound HTTPS connection to the Azure endpoints. The sensor continues detecting locally but cannot push alerts to the portal or Sentinel. 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 line: what is the difference between a cloud-connected and a locally-managed Defender for IoT sensor? Then compare with the expert version. Compare with expert answer Expert version: A cloud-connected sensor has an internet path and pushes structured alert metadata and device-inventory records to the Azure portal, where you manage it, approve updates, and feed alerts into Sentinel and Defender XDR — all centralised. A locally-managed (air-gapped) sensor has no cloud path; all data stays on the sensor and the admin accesses it through the local web UI. You choose air-gapped only when regulations or physical constraints absolutely forbid any cloud path, because cloud-connected gives you far richer management, RBAC, automatic updates, and SOC integration. ### 🗣 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 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. 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