Most engineers think…
Most people assume OT vulnerability management works like IT: find a CVE, push a patch, close the ticket. That model breaks almost immediately in a substation or factory floor.
Microsoft Defender for IoT takes a different path. It builds a passive device inventory entirely from DPI of network traffic — no agents, no active scans, zero impact on fragile PLCs or RTUs — then matches that inventory to a Microsoft OT CVE database maintained by the Section 52 research team. The result is not just a list of CVEs but a risk score per device that factors in CVSS severity, network exposure, Purdue level criticality, and alert history. An attack-path simulation then shows which devices sit on the adversary's most likely route from IT exposure to a critical process. And because patching is rarely an option, the workflow ends not with 'apply patch' but with recording compensating controls — segmentation, protocol whitelisting, enhanced monitoring — that reduce effective risk without touching the device.
① Why OT vulnerability management is a different problem
A Siemens S7-300 PLC running firmware from 2017 may carry a known CVE with a CVSS score of 9.8. On a Windows server you would patch it tonight. On a PLC controlling a water treatment plant, the vendor's firmware certification process takes months, the maintenance window is a single Sunday morning per year, and an unexpected restart triggers a safety interlock. The patch may simply never happen.
This is the core tension in OT security: CVEs accumulate, patches do not arrive. Microsoft Defender for IoT is built for this reality. Because it is fully agentless — the OT network sensor watches a SPAN/mirror port or TAP and uses deep packet inspection (DPI) to read firmware versions and protocols from traffic headers — it can build an accurate device inventory and CVE match list without touching a single PLC, RTU, or HMI. No software install, no active scan, zero operational impact on fragile OT devices.
The goal of OT vulnerability management is therefore not a zero-CVE state. It is risk reduction through visibility, prioritisation, and compensating controls — knowing exactly which devices carry which CVEs, which of those sit on a dangerous attack path, and what network-based mitigations are already in place.
Why is OT vulnerability management fundamentally different from patching IT servers?
② CVE matching & risk assessment reports — know what you're sitting on
The OT network sensor's passive inventory captures, per device: vendor, model, firmware version, OS, IP/MAC address, open protocols, and Purdue level. That identity tuple is continuously matched against the Microsoft OT CVE database — a curated feed maintained and updated by Microsoft's Section 52 OT/ICS threat research team (part of MSTIC). Section 52 focuses specifically on industrial control system vulnerabilities that general IT scanners may never carry.
The risk assessment report
From that match, Defender for IoT generates a risk assessment report listing all discovered devices with their CVE count, individual CVSS severity scores, network exposure (how many other devices can reach them), Purdue level, and any open alerts. For cloud-connected sensors the report is available in the Azure / Defender portal; for air-gapped deployments it is accessible from the OT sensor's local interface. Reports export to PDF or CSV for OT team reviews, management briefings, and compliance evidence. The key insight: a Level 1 PLC with a moderate CVE but wide network exposure may be far more dangerous than a Level 3 server with a high CVSS but tightly segmented.
Microsoft's OT/ICS-focused threat research team that discovers industrial CVEs and pushes threat intelligence packages to Defender for IoT sensors — cloud auto-update or USB for air-gapped.
A per-site Defender for IoT report listing all devices with CVE counts, CVSS scores, network exposure, Purdue level, and alert history — available from the Azure portal or the sensor's local interface.
Maps the chain of lateral-movement hops from an IT-exposed entry point to critical Level 0/1 OT devices based on observed traffic — path position matters as much as CVSS score.
A recorded network-based mitigation — segmentation, protocol whitelisting, port disablement, enhanced monitoring — that reduces a device's unmitigated risk score when a firmware patch is not feasible.
For air-gapped OT sensors that cannot reach the Azure portal, the full risk assessment report — CVEs, risk scores, exposure — is available directly from the OT sensor's local management interface. You do not need cloud connectivity to run OT vulnerability management.
Which Microsoft team maintains the OT CVE database and pushes threat intelligence packages to Defender for IoT sensors?
③ Attack-vector & attack-path simulation — where does the adversary go next?
A raw CVE list tells you what is vulnerable. Attack-path simulation tells you whether it matters. Defender for IoT uses the observed protocol traffic map — every connection the sensor has seen — to simulate the lateral-movement chain an adversary could walk from a compromised entry point to a critical OT device.
Attack-vector simulation starts at a chosen entry point (e.g. an HMI exposed to the enterprise network) and enumerates which devices are directly reachable and over which protocols. Attack-path analysis chains those hops: enterprise network → Level 3 historian via RDP → Level 2 SCADA via OPC-DA → Level 1 RTU via IEC 60870-5-104. A Level 1 RTU at the end of that chain is a critical finding even if its individual CVE score is only moderate, because it is reachable from the internet-facing enterprise network in three hops.
This reframes prioritisation: path position matters as much as CVSS score. An isolated Level 0 device with a CVSS 9 CVE but no network neighbours is lower priority than a CVSS 6 device that sits as hop 2 on a path to ten Level 1 PLCs. Attack-path simulation is how OT teams make that call without guesswork.
Sorting purely by CVSS gives you a list that prioritises isolated, unreachable devices over exposed, reachable ones. Always layer attack-path simulation on top of CVSS: a CVSS 6 device at hop 2 on a path to ten Level 1 PLCs is far more urgent than a CVSS 9.8 device with no network neighbours.
▶ Watch a CVE finding drive a remediation ticket end-to-end
How Defender for IoT turns a passive CVE match into a closed finding. Press Play for the healthy path, then Break it to see the classic OT gap.
An attack-path simulation shows a Level 1 RTU is reachable from the enterprise network in three hops via a historian and SCADA server. The RTU's individual CVE CVSS score is 6.2. How should you prioritise it?
④ Risk-based scoring & compensating controls — act without patching
Each device in Defender for IoT carries a risk score that combines four inputs: CVE severity (CVSS) of open vulnerabilities; network exposure (reachability from other devices — especially from IT-side networks); Purdue level criticality (Level 0/1 field devices are weighted higher because they directly control physical processes); and alert history (devices that have generated behavioural or policy anomaly alerts). The portal sorts devices by this score, giving OT teams a ranked work list for the next maintenance window.
Compensating controls — close the finding without a patch
Because patching is often months or years away, Defender for IoT lets analysts record a compensating control against a CVE: network segmentation applied, protocol whitelisting configured on the Level 3.5 firewall, unused ports disabled on the adjacent switch, or enhanced monitoring active. Once recorded, the control is reflected in the risk score — the finding is not deleted, but its contribution to the unmitigated risk count drops. Integration with Microsoft Sentinel SOAR playbooks can auto-create ServiceNow or JIRA tickets for each high-risk CVE, routing the right finding to the right team (OT ops for network controls, IT for firewall rules) without manual triage.
Priya Nair, OT security analyst at Bharat Power Grid Ltd. in Nagpur, faces this
A risk assessment report flags 40+ CVEs across the substation network including a high-severity Siemens S7 firmware vulnerability, but the OT ops team says patching is impossible — substations run 24/7.
Three RTUs at Level 1 are reachable from the IT network in three hops via a Level 3 historian that has an open RDP port, putting them on a critical attack path despite not having the highest individual CVE scores.
Defender for IoT portal → Device inventory → sort by risk score → attack-path simulation shows: enterprise network → Level 3 historian (RDP) → Level 2 SCADA (OPC-DA) → Level 1 RTUs (IEC 60870-5-104). The historian's RDP exposure is the chain's weak link.
Defender portal ▸ Device inventory ▸ Risk score sort ▸ Attack-path simulation1. Close or restrict RDP on the historian to break the attack chain (compensating control recorded). 2. Apply protocol whitelisting on the Level 3.5 firewall — allow only IEC 60870-5-104 between historian and RTUs. 3. Create a Sentinel SOAR playbook to auto-ticket any new high-risk CVE finding to the OT ops team.
Re-run attack-path simulation — the historian-to-RTU hop is no longer in the critical path. Risk assessment report shows compensating controls recorded against the S7 CVE; effective risk scores for the three RTUs drop below critical threshold.
After recording a compensating control (e.g. a firewall segment), re-run attack-path simulation to confirm the hop is actually gone — not just assumed gone. The simulation uses observed traffic, so if the firewall rule was mis-configured and traffic still flows, the path will still appear. Simulation is your verification step.
After recording a network-segmentation compensating control against a CVE in Defender for IoT, what changes in the risk assessment?
🤖 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: why does Defender for IoT use a risk score instead of just listing CVEs by CVSS severity? 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
- CVE (Common Vulnerabilities and Exposures)
- A standardised identifier for a known security flaw in a specific product or firmware version, with a CVSS severity score.
- CVSS
- Common Vulnerability Scoring System — a 0–10 numeric severity score for a CVE, used as one input (not the only input) in Defender for IoT's risk scoring.
- Section 52 / MSTIC
- Microsoft's OT/ICS-focused threat research team that discovers industrial CVEs and publishes threat intelligence packages for Defender for IoT sensors.
- Risk assessment report
- A per-site Defender for IoT report listing all devices with CVE counts, CVSS scores, network exposure, Purdue level, and alert history for prioritised remediation.
- Attack-path simulation
- Analysis that chains the lateral-movement hops from an IT-exposed entry point to critical Level 0/1 OT devices based on observed protocol traffic.
- Compensating control
- A recorded network-based mitigation — segmentation, protocol whitelisting, enhanced monitoring — that reduces a device's unmitigated risk score when a firmware patch is not feasible.
- Purdue model
- A reference architecture for OT/ICS networks (Levels 0–5 + Level 3.5 IT/OT DMZ) used by Defender for IoT to classify devices and weight risk — Level 0/1 field devices rated most critical.
- DPI (Deep Packet Inspection)
- Parsing the full payload of network packets to extract application-layer data, including OT firmware versions and protocol details without active scanning.
📚 Sources
- Microsoft — Defender for IoT vulnerability management overview. learn.microsoft.com/en-us/azure/defender-for-iot/
- Microsoft — Create a risk assessment report for OT networks (Defender for IoT). learn.microsoft.com/en-us/azure/defender-for-iot/
- Microsoft — Visualize vulnerabilities — attack vector simulation in Defender for IoT. learn.microsoft.com/en-us/azure/defender-for-iot/
- Microsoft — Update OT threat intelligence packages on the sensor. learn.microsoft.com/en-us/azure/defender-for-iot/
- Microsoft Security Blog — Section 52: researching OT/ICS threats and vulnerabilities. microsoft.com/security/blog
- Microsoft — Manage your OT device inventory from the Azure portal (Defender for IoT). learn.microsoft.com/en-us/azure/defender-for-iot/
What's next?
Got vulnerability management? Next, see how Defender for IoT feeds CVEs and alerts into Microsoft Sentinel — OT analytics rules, SOAR playbooks, and unified IT+OT incident correlation in one SOC.