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.
Where should a Defender for IoT sensor connect on the network to cover a whole production-line zone?
② 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.
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.
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.
Passive hardware on the physical cable that always delivers a complete, bidirectional traffic copy with zero packet loss — no switch CPU involved.
The baseline-building phase (typically 2–6 weeks) during which the sensor passively learns normal OT communication patterns before the anomaly engine fires alerts.
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.
A safety PLC runs Modbus on a critical link. The aggregation switch is already at 85% CPU. Which traffic-capture method should you choose?
③ 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.
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.
A factory site has a strict requirement that OT data must never leave the premises. Which sensor mode must you choose?
④ 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.
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.
Sensors were switched to operational mode immediately after install, with no learning period, so the baseline is empty.
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 ModeSwitch 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.
Daily alert count drops from 400+ to under 20. OT team confirms remaining alerts are genuine anomalies — not scheduled polling traffic.
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.
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?
🤖 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 single step causes the most Defender for IoT deployment failures, and how do you prevent it? 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
- 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.