# Microsoft Defender for IoT Deployment — Sensor Placement & Sizing Best Practices Source: https://ai.techclick.in/blog_microsoft_defender_iot_deployment Markdown: https://ai.techclick.in/blog_microsoft_defender_iot_deployment.md Publisher: Techclick Infosec Pvt Ltd Step-by-step guide to Microsoft Defender for IoT deployment in 2026: sensor placement by site and zone, SPAN vs TAP, sizing by traffic and device count, cloud-connected vs air-gapped, phased rollout and the learning period. Microsoft Defender for IoT Deployment — Sensor Placement & Sizing Best Practices student learning map A visual study map for Microsoft Defender for IoT Deployment — Sensor Placement & Sizing Best Practices showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Microsoft Defender for IoT Deployment — 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 ① Where to place OT sensors —... 4. Practice ② SPAN vs TAP — and how to size... 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 you deploy a Defender for IoT sensor like a network switch — plug it in, turn it on, and it works. In an OT environment that assumption causes hundreds of false alerts within 48 hours. The reality: sensor placement, traffic-mirror method, sizing, and — above all — the learning period are what separate a useful deployment from a noise machine. Place the sensor at the aggregation switch for the zone, feed it via a SPAN or TAP , choose cloud-connected vs air-gapped based on a clear checklist, then let the sensor build its behavioural baseline for 2–6 weeks before you declare it operational. Skip any of those steps and the SOC drowns; follow them and you get clean OT visibility from day one. ## ① Where to place OT sensors — site, zone and the aggregation switch Microsoft Defender for IoT organises every sensor into a site (a physical location, e.g. the Pune factory) and a zone (a logical segment within it, e.g. Line 1 or the SCADA enclave). This is not just a labelling exercise — RBAC, alert routing and device inventory all inherit the site/zone, so correct placement pays dividends across the whole platform. The golden rule: connect the sensor to the aggregation or distribution switch that sees all OT traffic for the zone . That switch is where all PLC, RTU and HMI traffic converges before it crosses to another segment or climbs toward the IT/OT DMZ (Purdue Level 3.5). Attaching at individual device ports means you need many more sensors and miss lateral traffic between field devices. If a factory has multiple isolated production lines — each behind its own L2 VLAN — deploy one sensor per line or configure an aggregated SPAN that mirrors all relevant VLANs to one port. Sensors auto-map discovered devices to Purdue levels (0–5) in the portal, flagging any device that communicates across levels it should not. Legend Royal & arrows — flow direction Electric — step titles Deep navy — diagram heading Slate — detail text Mist — canvas panel Figure 1 — Sensor deployment flow — from site to operational alert Every Defender for IoT deployment follows the same five-step sequence from planning to live alerting. - Sensor deployment flow — from site to operational alert Plan zones map site/zone + Purdue Place sensor aggregation switch Mirror traffic SPAN port or TAP Learning mode build OT baseline Operational alert + integrate Every Defender for IoT deployment follows the same five-step sequence from planning to live alerting. Quick check · Q1 of 10 · Understand Where should a Defender for IoT sensor connect on the network to cover a whole production-line zone? a) One sensor port per PLC or RTU b) The aggregation or distribution switch that consolidates all zone traffic c) The IT firewall at Purdue Level 4 d) A Wi-Fi access point near the HMI Correct: b. The aggregation switch sees all OT device traffic for the zone in one place. Connecting per device multiplies sensor count and misses east-west traffic between field devices. 👉 So far: One sensor per zone at the aggregation switch, assigned to the right site/zone in the portal — that is the placement rule. Sensors auto-map devices to Purdue levels and flag cross-level violations. ## ② SPAN vs TAP — and how to size the sensor The sensor needs a copy of all zone traffic. Two methods exist. A SPAN port (mirror port) is a software feature on a managed switch: you instruct the switch to duplicate selected ports or VLANs to one output port connected to the sensor. It is free, flexible and easy to reconfigure, but under high switch CPU load the mirror can drop packets — unacceptable on critical links. A network TAP is a small passive hardware device spliced onto the physical cable. It always delivers a complete, bidirectional copy of every frame with zero packet loss and no switch CPU dependency. TAPs cannot be reconfigured from software, but for safety-critical links (Modbus to a safety PLC, for example) that is a feature, not a bug: the TAP cannot be accidentally misconfigured. ### Sizing by bandwidth and device count Microsoft publishes sensor appliance tiers. Match the tier to: (1) peak bandwidth on the mirrored link in Mbps, and (2) device count expected in the zone. Use a physical appliance for high-throughput production lines. Use a virtual sensor (VM) for cloud-connected pilots, lower-bandwidth segments, or brownfield retrofits where rack space is limited. Never assign one sensor to too many unrelated zones — clean zone boundaries make alert attribution accurate. Figure 2 — SPAN port vs network TAP Both deliver a copy of OT traffic to the sensor; the right choice depends on link criticality and switch headroom. SPAN port vs network TAP SPAN Port Software-configured on the switch Free — no extra hardware Can drop packets under high CPU Easy to reconfigure remotely Fine for lower-criticality links Network TAP Passive hardware on the cable Small cost; no switch dependency Zero packet loss, always Cannot be misconfigured remotely Preferred for safety-critical OT Both deliver a copy of OT traffic to the sensor; the right choice depends on link criticality and switch headroom. Figure 3 — Sensor sizing inputs — bandwidth and device count Pick the sensor tier that covers both the peak mirrored bandwidth and the zone device count. Sensor sizing inputs — bandwidth and device count Peak bandwidth (Mbps) mirrored link at busiest OT cycle Device count (zone) PLCs, RTUs, HMIs, switches Form factor physical appliance vs virtual sensor Pick the sensor tier that covers both the peak mirrored bandwidth and the zone device count. 📡 OT Network Sensor tap to flip The Defender for IoT edge appliance (physical or VM) that captures OT traffic via SPAN or TAP, runs DPI and detection locally, and sends findings to the cloud or on-prem management console. 🔌 SPAN Port tap to flip A switch mirror port that copies selected ports or VLANs to the sensor. Free and flexible, but can drop packets when switch CPU is under load. 🪢 Network TAP tap to flip Passive hardware on the physical cable that always delivers a complete, bidirectional traffic copy with zero packet loss — no switch CPU involved. 📚 Learning Period tap to flip The baseline-building phase (typically 2–6 weeks) during which the sensor passively learns normal OT communication patterns before the anomaly engine fires alerts. TAP for critical links In an interview or design review, always mention TAPs for safety-critical OT links. SPAN is fine for monitoring but can silently drop frames under switch CPU load. A TAP is passive hardware — it never misses a packet and cannot be accidentally reconfigured. Quick check · Q2 of 10 · Apply A safety PLC runs Modbus on a critical link. The aggregation switch is already at 85% CPU. Which traffic-capture method should you choose? a) SPAN port — it is free b) Both SPAN and TAP simultaneously c) No capture — passive sensors are not needed for PLCs d) Network TAP — zero packet loss regardless of switch CPU Correct: d. A SPAN port under high switch CPU can silently drop mirrored packets. A TAP is passive hardware on the cable and always delivers a complete copy — essential for a safety-critical link. 👉 So far: SPAN = free, software-defined, can drop under CPU load. TAP = passive hardware, zero packet loss. Use a TAP for critical OT links. Size by peak bandwidth + device count; use physical appliances for high-throughput production. ## ③ Cloud-connected vs locally-managed (air-gapped) — the deployment mode decision Every Defender for IoT sensor runs in one of two modes. Cloud-connected sensors stream alerts, device inventory and security findings to the Azure/Defender portal. This unlocks the full platform: Microsoft Sentinel integration (OT analytics rules, workbooks, SOAR playbooks), automatic threat intelligence updates from Microsoft's OT research team (Section 52 / MSTIC), Defender XDR unified SOC, and centralised RBAC. For most organisations this is the right choice. Locally-managed sensors operate standalone — all data stays on-site and is accessible only via the sensor's built-in web UI or the legacy on-premises management console. This mode is required for: classified or government OT networks, sites with strict data-sovereignty rules, or industrial plants with no path to Azure. Note that Microsoft is retiring the on-premises management console , moving management to the cloud; locally-managed sites should plan their migration path. ### Quick decision checklist Can the sensor reach Azure? → cloud-connected . Strict air-gap, sovereignty, or classified requirement? → locally-managed . Need Sentinel/XDR? → must be cloud-connected. Need automatic threat intel without manual USB updates? → cloud-connected. Threat intel can still be delivered to air-gapped sensors via manual package uploads, but this adds operational overhead. Figure 4 — Cloud-connected sensor — what it unlocks A cloud-connected sensor feeds a single Azure/Defender portal, enabling the full Microsoft security stack. Cloud-connected sensor — what it unlocks Azure Portal Defender for IoT Device inventory Alert management Sentinel SIEM Defender XDR Threat intel (MSTIC) RBAC & reporting A cloud-connected sensor feeds a single Azure/Defender portal, enabling the full Microsoft security stack. Forgetting the console is retiring The on-premises management console for air-gapped multi-sensor sites is being retired by Microsoft. If a design you review still centres on it as the long-term aggregation layer, flag this: air-gapped sites need a migration path to the cloud or to individual locally-managed sensors. ### ▶ Watch a rogue device get detected — from SPAN capture to cloud alert A new unauthorised device appears on the OT network. Press Play for the healthy detection path, then Break it to see what happens without the learning period. ① Traffic mirror The aggregation switch SPAN port copies all zone traffic to the Defender for IoT sensor continuously. ▼ ② DPI + baseline The sensor runs deep packet inspection and compares traffic against its learnt baseline of normal OT communications. ▼ ③ Anomaly detected A new device sends a Modbus command from an unrecognised IP — it was not in the baseline. The sensor raises a high-confidence alert. ▼ ④ Cloud alert The alert (device, IP, protocol, timestamp) streams to the Defender portal and fires a Sentinel incident for the SOC to investigate. Press Play to step through the rogue-device detection path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Analyze A factory site has a strict requirement that OT data must never leave the premises. Which sensor mode must you choose? a) Cloud-connected — it is always more secure b) Either mode — both keep data on-site c) Locally-managed (air-gapped) d) The on-premises management console only Correct: c. Cloud-connected sensors stream data to Azure, which violates the data-residency requirement. Locally-managed (air-gapped) mode keeps all data on-site and never calls home to Azure. 👉 So far: Cloud-connected: data goes to Azure, unlocks Sentinel/XDR/MSTIC threat intel, right for most orgs. Locally-managed: data stays on-site, required for strict air-gap/sovereignty. On-prem management console is being retired — plan accordingly. ## ④ Phased rollout, the learning period & keeping alert noise low A phased rollout avoids the classic OT deployment trap: going live across every zone at once, skipping the baseline, and flooding the SOC with hundreds of false policy-violation alerts on day one. Phase 1 — Pilot : deploy one sensor on a well-understood zone. Validate SPAN/TAP cabling, sensor connectivity and asset discovery, but do not act on alerts yet. Phase 2 — Learning period : set the sensor to learning mode for 2–6 weeks (longer for sites with seasonal or scheduled production cycles). The learning period builds the behavioural baseline that the Anomaly detection engine needs. Phase 3 — Operational mode : transition the sensor and review the first wave of alerts with the OT engineering team. Create alert exclusion rules for known-good patterns (scheduled PLC diagnostic polls, maintenance-window traffic). Phase 4 — Expand : repeat per zone. Phase 5 — Integrate : connect to Sentinel, configure Defender XDR, set SOC and OT-team RBAC. Tuning tip: enable the Protocol Violation and Policy Violation engines first — they have high precision. Hold the Anomaly engine until the baseline is rock-solid. Route High/Critical alerts to the SOC; send Medium alerts to the OT engineer review queue to avoid analyst fatigue. Figure 5 — Phased rollout — 5 steps from pilot to full OT coverage Roll out zone by zone, completing the learning period per zone, to avoid big-bang alert storms. Phased rollout — 5 steps from pilot to full OT coverage Pilot zone 1 sensor, validate cabling Learning mode 2–6 wk baseline Operational tune + exclusion rules Expand zones repeat per zone Integrate SOC Sentinel + XDR + RBAC Roll out zone by zone, completing the learning period per zone, to avoid big-bang alert storms. Priya Iyer at a Pune turbine manufacturer faces this Two weeks after go-live, Defender for IoT sensors generate 400+ daily alerts — mostly 'Policy Violation: unexpected Modbus command' — but OT engineers confirm these are normal PLC diagnostic polls. Likely cause Sensors were switched to operational mode immediately after install, with no learning period, so the baseline is empty. Diagnosis In the Defender portal, sensor is in operational mode and the baseline is blank. Policy Violation engine fires on every cross-device poll not in a pre-seeded allow-list. Defender Portal ▸ Site Management ▸ Select Sensor ▸ Sensor Mode Fix Switch sensors back to learning mode for at least 3 weeks. After the baseline builds, create alert exclusion rules for known diagnostic addresses and scheduled polling, then transition to operational mode. Verify Daily alert count drops from 400+ to under 20. OT team confirms remaining alerts are genuine anomalies — not scheduled polling traffic. Confirm learning period completion Before signing off a zone as operational, check in the Defender portal that the sensor has completed its learning period and shows a populated device baseline. An empty or near-empty baseline means anomaly alerts are unreliable — go back to learning mode. Quick check · Q4 of 10 · Evaluate A Defender for IoT sensor goes live and within 24 hours generates 500 Policy Violation alerts. The OT team says most are normal polling traffic. What most likely went wrong? a) The SPAN port was misconfigured b) The sensor ran in cloud-connected mode c) The learning period was skipped — no behavioural baseline was built before operational mode d) The sensor appliance is undersized Correct: c. Skipping the learning period means the Anomaly and Policy Violation engines have no baseline. Every OT communication pattern looks unexpected, causing an alert storm. The fix is to switch back to learning mode and let the baseline build. 👉 So far: Five phases: pilot → learning (2–6 weeks) → operational (tune + exclusions) → expand zones → integrate SOC. Skipping the learning period is the #1 cause of alert storms. Enable Protocol Violation first; hold Anomaly until baseline is solid. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Where should I place a Defender for IoT sensor in an OT environment? When should I use a TAP instead of a SPAN port? What is the difference between cloud-connected and locally-managed sensors? What is the learning period and how long should it run? How do I avoid alert storms after deploying a Defender for IoT sensor? How do I size a Defender for IoT sensor? 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 In Microsoft Defender for IoT, what is a 'zone'? a) A network TAP hardware device b) A type of SPAN port configuration c) A logical segment within a site, used to group OT devices for alerting and RBAC d) A Purdue Level 5 component Correct: c. A zone is a logical segment within a site (e.g. a production line or SCADA enclave). Sensors are assigned to a site + zone, which drives RBAC, alert routing and device inventory grouping. Q6 · Understand Why does a SPAN port sometimes miss packets that a TAP would capture? a) SPAN only works on fibre links b) SPAN requires an internet connection c) SPAN is software-based and the switch may drop mirrored packets under high CPU load d) TAPs amplify signals that SPAN cannot Correct: c. SPAN is implemented in switch software. When the switch is under CPU pressure, it deprioritises mirrored packets. A TAP is passive hardware on the cable and delivers a complete copy regardless of switch load. Q7 · Apply Your site cannot connect to Azure due to a government air-gap requirement. Which sensor deployment mode must you use? a) Cloud-connected b) Locally-managed (air-gapped) c) Either — both support air-gapped operation d) Hybrid — split data between Azure and on-site Correct: b. Cloud-connected mode streams data to Azure. For a strict air-gap requirement, locally-managed mode must be used — all data stays on-site, accessible only via the sensor UI or the on-premises management console. Q8 · Analyze A Defender for IoT sensor completed its 4-week learning period. An OT engineer then schedules a new monthly maintenance scan that generates Modbus commands from a laptop. What should you do before those scans begin? a) Restart the full learning period from scratch b) Add an alert exclusion rule covering the maintenance laptop IP and schedule c) Switch the sensor to cloud-connected mode d) Disable the Protocol Violation engine permanently Correct: b. Alert exclusion rules suppress known-good patterns without restarting the learning period or losing the existing baseline. Restarting learning is disproportionate; disabling an engine permanently reduces detection capability. Q9 · Evaluate Which detection engine should be enabled FIRST after the learning period completes, to minimise false positives? a) Anomaly engine — it catches the most threats b) Operational engine only c) All five engines simultaneously for maximum coverage d) Protocol Violation and Policy Violation engines — they have the highest precision Correct: d. Protocol Violation and Policy Violation engines fire on clear, rule-based deviations (malformed protocol frames, traffic crossing a policy boundary) and have high precision. The Anomaly engine needs a solid baseline before it is reliable, so it should be held until the baseline is confirmed complete. Q10 · Evaluate An interviewer asks how you would deploy Defender for IoT across a 10-zone factory. What is the safest approach? a) Deploy all 10 sensors simultaneously and enable all engines on day one b) Deploy one pilot zone, complete the learning period, tune exclusions, then expand zone by zone c) Skip the learning period to save time and tune alerts reactively d) Deploy only one sensor for the whole factory to keep costs low Correct: b. A phased rollout — pilot, learning period, tune, expand — prevents a big-bang alert storm and lets each zone baseline independently. Deploying all zones simultaneously with no baseline is the most common cause of SOC overload in OT deployments. 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 single step causes the most Defender for IoT deployment failures, and how do you prevent it? Then compare with the expert version. Compare with expert answer Expert version: Skipping the learning period is the single most common deployment failure. Without the 2–6 week baseline phase, the sensor's anomaly and policy violation engines have no model of normal OT communications and fire on every device interaction — flooding the SOC with false positives on day one. Prevent it by keeping the sensor in learning mode for the full recommended period, completing the baseline, then creating alert exclusion rules for known-good maintenance and polling traffic before transitioning to operational mode. ### 🗣 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 Site / Zone Defender for IoT organisational units: a site is a physical location; a zone is a logical OT segment within it. RBAC and alert routing inherit the site/zone assignment. SPAN Port A switch software feature that mirrors traffic from selected ports or VLANs to one output port connected to the sensor. Can drop packets under high switch CPU load. Network TAP Passive hardware spliced onto a network cable that delivers a complete, bidirectional copy of all traffic to the sensor with zero packet loss, independent of switch CPU. Learning Period The sensor baseline phase (typically 2–6 weeks) during which the sensor passively learns normal OT communication patterns before alerting on anomalies. Cloud-Connected Sensor Sensor mode that streams alerts and device data to Azure/Defender portal, enabling Sentinel, Defender XDR, MSTIC threat intel and centralised RBAC. Locally-Managed Sensor Air-gapped sensor mode where all data stays on-site; required for classified networks and strict data-sovereignty environments. Alert Exclusion Rule A Defender for IoT policy that suppresses alerts matching a specific pattern (device IP, protocol, schedule) for known-good OT behaviour. Phased Rollout Deploying sensors zone by zone — pilot, learning period, operational mode, expand — to avoid big-bang alert storms and allow per-zone baseline tuning. #### 📚 Sources Microsoft Learn — Deploy Microsoft Defender for IoT OT monitoring . learn.microsoft.com/azure/defender-for-iot - Microsoft Learn — OT network sensor appliance sizing and system requirements . learn.microsoft.com/azure/defender-for-iot - Microsoft Learn — Configure OT sensor settings from the Azure portal — cloud-connected vs locally managed . learn.microsoft.com/azure/defender-for-iot - Microsoft Learn — Manage the OT sensor learning period . learn.microsoft.com/azure/defender-for-iot - Microsoft Learn — Create and manage alert suppression rules — Microsoft Defender for IoT . learn.microsoft.com/azure/defender-for-iot - Microsoft Learn — Microsoft Defender for IoT: sites and zones for OT monitoring . learn.microsoft.com/azure/defender-for-iot ### What's next? With sensors deployed and tuned, the next step is understanding the OT protocols Defender for IoT parses — Modbus, DNP3, S7, EtherNet/IP, BACnet and more — and how to fine-tune alert thresholds for each. 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