M09 · Additional Defender Workloads

Course: Microsoft Defender — Security Operations Fundamentals Module duration: 2.5 hours (including light lab) Format: Instructor-led, hands-on

Currency note (as of June 2026): These workloads evolve quickly and some surfaces have been renamed or reorganized (e.g., “Defender for DevOps” capabilities under DevOps security posture management). Verify product names, plan availability, and portal paths against current Microsoft Learn before relying on specifics; mark anything in preview [PREVIEW].

Learning objectives

By the end of this module you will be able to:

  1. Describe the purpose and primary use cases for Defender for IoT, Defender for DevOps, Defender for Containers (standalone), and the remaining Defender for Cloud sub-plans.
  2. Identify the signals each workload surfaces and where they appear in the unified portal.
  3. Explain when to recommend enabling each workload based on the environment.

1. Why a survey module

The headline Defenders (Endpoint, Office 365, Cloud Apps, Cloud) cover most SOC work, but Microsoft’s platform extends to specialized environments — operational technology, developer pipelines, and a long tail of Azure resource types. This module is a breadth survey: enough to recognize each workload, know what signal it produces, and advise when to turn it on.

2. Defender for IoT / OT

Microsoft Defender for IoT protects Internet of Things (IoT) and operational technology (OT) environments — the industrial control systems, sensors, and devices that traditional endpoint agents cannot run on.

  • Agentless monitoring — passively analyzes network traffic (often via a SPAN/mirror port) to inventory devices and detect threats without installing software on fragile OT devices.
  • Site sensors and device inventory — sensors at each site build a map of every device, its protocol, and its communication patterns.
  • OT-specific threat detection — understands industrial protocols (e.g., Modbus, DNP3) and flags anomalies and known attacks relevant to OT (mapped to MITRE ATT&CK for ICS, the industrial matrix introduced in M01).
  • Portal integration — alerts and device inventory surface in the unified Defender portal / a dedicated IoT view.

When to recommend: any environment with manufacturing, utilities, healthcare devices, or building automation — places where OT and IT networks converge and conventional agents are not an option.

In the lab you will review a pre-populated IoT device inventory and investigate a sample OT alert.

3. Defender for DevOps / DevOps security

Defender for DevOps (DevOps security in Defender for Cloud) extends security “code-to-cloud” — catching problems in the developer pipeline before they reach production.

  • Connectors — integrate GitHub, Azure DevOps, and GitLab to bring pipeline and repo findings into Defender for Cloud.
  • What it scans — infrastructure-as-code (IaC) misconfigurations, exposed secrets in code, and code-scanning findings (vulnerabilities/quality issues).
  • DevOps security posture — a unified view in the Defender for Cloud portal of findings across connected DevOps environments, so a misconfiguration is fixed at the source rather than in the running cloud.

When to recommend: organizations practicing CI/CD and infrastructure-as-code who want to “shift left” — find secrets and misconfigurations before deployment.

In the lab you will explore Defender for DevOps findings for a sample repository.

4. Defender for Containers (standalone view)

Introduced in M08 as a CWPP plan, Defender for Containers is worth a second look as a workload in its own right:

  • Kubernetes posture — hardening recommendations for clusters and configurations.
  • Runtime threat detection — alerts on suspicious container/cluster behavior at runtime.
  • Registry image scanning — vulnerability scanning of container images.

When to recommend: any environment running Kubernetes/containers (AKS, EKS, GKE, on-prem).

5. Remaining Defender for Cloud sub-plans (survey)

Defender for Cloud has a long tail of resource-specific plans. Recognize each (coverage verified against Microsoft Learn, as of June 2026):

PlanProtectsExample threats addressed
Defender for App ServiceAzure App Service web appsWeb-app exploitation, dangling DNS, malicious uploads
Defender for Resource ManagerAzure Resource Manager control planeSuspicious resource-management operations, risky role use
Defender for DNSAzure DNS resolutionData exfiltration via DNS, communication with malicious domains, DNS tunneling
Defender for APIsAzure API Management–published APIsAPI abuse, anomalous/suspicious API traffic, exposure of sensitive APIs

These typically surface their alerts in the Defender for Cloud security alerts queue (and roll up into the unified portal). Each is billed per protected resource, so enablement is a cost/coverage decision.

6. Deciding which plans to enable

There is no “turn on everything” answer — each plan has a cost. Guide enablement by:

  • What exists in the environment — only protect resource types you actually run.
  • Sensitivity / blast radius — protect what holds or controls sensitive data first (databases, Key Vault, identity-adjacent control planes).
  • Exposure — prioritize internet-facing and externally reachable resources.
  • Cost/coverage trade-off — weigh per-resource cost against the risk reduction; start with the highest-value plans and expand.

In the lab you will identify which additional plans are enabled in the lab environment and review one sample alert from each active plan.

7. Module summary

  • Defender for IoT/OT — agentless, protocol-aware monitoring for industrial/IoT networks; maps to ATT&CK for ICS; for OT-converged environments.
  • Defender for DevOps — code-to-cloud scanning (IaC, secrets, code) via GitHub/Azure DevOps/GitLab connectors; for CI/CD shops shifting left.
  • Defender for Containers — Kubernetes posture, runtime detection, image scanning.
  • Remaining sub-plans — App Service, Resource Manager, DNS, APIs each add targeted detection; all billed per resource.
  • Enablement is a cost/coverage decision driven by what you run, its sensitivity, and its exposure.

Glossary (first-use acronyms in this module)

  • AKS / EKS / GKE — Azure / Amazon / Google managed Kubernetes services.
  • CI/CD — Continuous Integration / Continuous Delivery.
  • CWPP — Cloud Workload Protection Platform.
  • DNS — Domain Name System.
  • IaC — Infrastructure as Code.
  • ICS — Industrial Control Systems (ATT&CK matrix domain).
  • IoT — Internet of Things.
  • OT — Operational Technology.

Sources

Citations recorded per CLAUDE.md. Living documents; “as of June 2026” stamps indicate currency.

  1. Microsoft Learn — “What is Microsoft Defender for IoT?” https://learn.microsoft.com/azure/defender-for-iot/organizations/overview
  2. Microsoft Learn — “Overview of Microsoft Defender for DevOps / DevOps security.” https://learn.microsoft.com/azure/defender-for-cloud/defender-for-devops-introduction
  3. Microsoft Learn — “Overview of Microsoft Defender for Containers.” https://learn.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction
  4. Microsoft Learn — “Defender for App Service / Resource Manager / DNS / APIs” plan pages. https://learn.microsoft.com/azure/defender-for-cloud/defender-for-app-service-introduction · https://learn.microsoft.com/azure/defender-for-cloud/defender-for-resource-manager-introduction · https://learn.microsoft.com/azure/defender-for-cloud/defender-for-dns-introduction · https://learn.microsoft.com/azure/defender-for-cloud/defender-for-apis-introduction
  5. MITRE ATT&CK for ICS. https://attack.mitre.org/matrices/ics/

M09 of 10 · Microsoft Defender — Security Operations Fundamentals · maps to curriculum.md → M09 learning objectives 1–3. Student handout — distribute freely to learners. No answer keys contained.