L2. Defender for Endpoint: Onboarding and Alert Triage
Visual workflow edition
Worked example, diagrams and a question with time to think. Synthetic American-English narration; examples are fictional. Reviewed October 2026.
Read the video transcript
You deployed an onboarding policy, but the laptop is missing from the security portal. Is it protected? A successful deployment message alone cannot answer that. Let's separate installing the configuration from verifying that the endpoint is reporting, then use the device timeline to investigate a suspicious event.
Start with the operating system, its support requirements, and how your organization manages the device. Use the onboarding method documented for that platform, such as your device management service. Confirm the intended tenant and deployment scope. Applying a package is one step; network connectivity and sensor health also affect whether telemetry reaches the service.
In a fictional lab, a laptop appears in inventory but has no recent events. Check its last seen time, sensor health, and connectivity before declaring success. A stale device record can remain visible. Compare the device identifier and timestamps with your test machine. Use a supported benign validation procedure rather than introducing live malware.
When an alert arrives, anchor your review to the alert time. Inspect nearby processes, files, sign-ins, and network events that are available. Ask what launched the process and whether the surrounding activity fits the user's work. A filename alone is weak evidence. Preserve relevant details and connect the device findings to the wider incident.
Isolation can disrupt business activity, and its behavior depends on the platform and capability. Follow the incident process and confirm authorization before taking action. Record the device, reason, and expected impact. Then verify the action's result in the portal. A request that was submitted is not automatically a response that completed.
Your deployment tool reports success, but the device was last seen several days ago. Which evidence would most directly support that onboarding is working now? Pause before the answer.
You need fresh evidence from the correct device, together with sensor and connectivity checks. The deployment result is useful, but it is not enough on its own. Your practice task is to describe three independent checks you would record. Next, we follow a suspicious message through email protection and investigation.
Course outlineLesson 2 of 18
Defender for Endpoint protects devices through behavioral sensors, cloud analytics, and threat intelligence. This lesson covers onboarding methods, the alert queue, automated investigation, and the response actions SC-200 candidates must know.
Defender for Endpoint Architecture
Microsoft Defender for Endpoint (MDE) uses behavioral sensors embedded in Windows, macOS, Linux, Android, and iOS to collect telemetry. This data flows to the Microsoft cloud backend for analysis against threat intelligence and behavioral models.
Key components:
- Endpoint behavioral sensors: Collect process, network, registry, and file signals
- Cloud security analytics: Machine learning models that detect anomalies
- Threat intelligence: Microsoft and third-party IOCs and attack pattern matching
Onboarding Methods
The SC-200 exam tests your knowledge of onboarding approaches:
| Method | Best For |
|---|---|
| Microsoft Intune | Cloud-managed devices at scale |
| Group Policy | Domain-joined Windows endpoints |
| Local script | Testing and small deployments |
| Microsoft Endpoint Configuration Manager (MECM) | On-premises managed environments |
| VDI onboarding script | Non-persistent virtual desktops |
The Alert Queue and Triage
When MDE detects suspicious activity, it generates alerts with severity levels: Informational, Low, Medium, and High. Analysts triage alerts using these classifications:
- True positive: Confirmed malicious activity requiring response
- Informational, expected activity (benign positive): Correctly detected authorized activity (e.g., a pen test)
- False positive: Incorrectly flagged legitimate activity
The alert page shows a process tree, file details, device timeline, and related alerts. Use the device timeline to reconstruct the full sequence of events on an endpoint.
EDR in Block Mode and ASR
EDR in block mode lets Defender for Endpoint remediate post-breach detections when Microsoft Defender Antivirus is passive alongside another antivirus product; it requires Defender for Endpoint Plan 2 and Defender Antivirus installed. Attack surface reduction (ASR) rules prevent risky behaviors; deploy in audit mode to measure impact before blocking. EDR in block mode does not replace ASR or full real-time antivirus protection.Automated Investigation and Response (AIR)
Current behavior: Microsoft documents that, as of September 1, 2026, AIR no longer runs as a separate Defender investigation experience or supports manual triggering. Its detection and response capabilities run in the default antivirus protection stack. For an on-demand endpoint investigation, run a full antivirus scan. The automation levels below remain useful for interpreting the documented approval model.MDE can automatically investigate alerts and take remediation actions. AIR examines:
- Running processes and services
- Scheduled tasks
- Registry modifications
- Files and persistence mechanisms
Automation levels control how AIR behaves:
| Level | Behavior |
|---|---|
| Full automation | Remediate threats automatically |
| Semi (any folder) | Require approval for all remediations |
| Semi (non-temp) | Auto-remediate in temp folders, require approval elsewhere |
| Semi (core folders) | Require approval for core OS folder remediations |
| No automation | No automated response |
Response Actions
Key response actions available on devices:
- Isolate device: Cuts network access while maintaining Defender cloud connectivity
- Restrict app execution: Limits execution to Microsoft-signed binaries only
- Run antivirus scan: Triggers a quick or full scan remotely
- Collect investigation package: Gathers forensic data from the endpoint
- Initiate live response: Opens a remote shell session for manual investigation; enable live response in advanced features and grant the required RBAC permissions. Live response is a separate capability from AIR.
File-level actions include: stop and quarantine, add indicators (block/allow), and download file for analysis.
Device Groups
Device groups let you segment your fleet and apply different automation levels, RBAC permissions, and remediation policies. Group membership is determined by device tags, names, domains, or OS types.
References
- ✓Onboarding methods include Intune, Group Policy, local script, MECM, and VDI-specific scripts.
- ✓Non-persistent VDI environments require the dedicated VDI onboarding script.
- ✓Automated Investigation and Response (AIR) documentation lists full automation, three semi-automation levels, and no automation.
- ✓Device isolation cuts network access but maintains the Defender cloud connection for management.
- ✓Alert classifications are: true positive; informational, expected activity (benign positive); and false positive.
- ✓Device groups enable segmented automation levels and RBAC scoping.
1. An organization uses non-persistent VDI sessions. Which onboarding method should they use for Defender for Endpoint?
2. A SOC analyst isolates a compromised device using Defender for Endpoint. What network connectivity does the device retain?
3. Which automation level requires analyst approval for all remediation actions?
Keep learning
Use the knowledge check above to test your understanding. You can browse every lesson without signing in; opening another lesson does not mark this one complete.
Next lesson: Defender for Office 365: Email Threat Protection →