6.2 Defender for Endpoint Integration and Onboarding
Key Takeaways
- Defender for Endpoint integration starts with a service-to-service connector between Intune and Microsoft Defender for Endpoint; device onboarding is a separate step.
- Onboarding configures devices to communicate with Defender for Endpoint and send security telemetry that supports detection, investigation, response, and risk reporting.
- Risk-based access control requires three links: Defender for Endpoint reports machine risk, an Intune compliance policy evaluates that risk, and Conditional Access requires compliant devices.
- Endpoint detection and response policies are the Intune endpoint security policy type used for Defender for Endpoint onboarding and EDR configuration.
- Security tasks and Defender response actions support operational follow-through after onboarding, but they do not replace compliance and Conditional Access design.
The integration chain
Microsoft Defender for Endpoint is not just another app assignment. In MD-102 scenarios, Defender for Endpoint usually matters because its risk signal can flow into Intune compliance and then into Microsoft Entra Conditional Access. The exam tests whether you can identify which link in that chain is missing when access is not being blocked as expected.
The complete chain is: connect Intune to Defender for Endpoint, onboard devices, evaluate risk in a compliance policy, and enforce the compliant-device result with Conditional Access. Missing any link leaves a gap. A device can be enrolled in Intune but not onboarded to Defender. A device can be onboarded to Defender but still not affect access if no compliance policy evaluates the Defender risk level, or if no Conditional Access policy requires compliance.
Integration workflow
| Step | Configuration | Result | Exam trap |
|---|---|---|---|
| 1 | Enable the Microsoft Defender for Endpoint connector in Intune | Intune and Defender establish service-to-service communication | Assuming device enrollment alone creates Defender telemetry |
| 2 | Deploy an endpoint detection and response onboarding policy | Devices receive onboarding configuration and report to Defender for Endpoint | Confusing onboarding with installing Company Portal |
| 3 | Configure device compliance to use Defender machine risk | Intune can mark devices noncompliant when risk exceeds the allowed level | Onboarding devices but not using risk in compliance |
| 4 | Configure Conditional Access to require compliant devices | Microsoft 365 access is blocked when risk makes the device noncompliant | Creating compliance without access enforcement |
| 5 | Monitor onboarding, device risk, and remediation | Admins can verify coverage and act on findings | Treating assignment status as proof of protection |
Onboarding facts to remember
Onboarding is the action that makes a device communicate with the Defender for Endpoint service. For Windows devices managed by Intune, this commonly uses an endpoint security Endpoint detection and response (EDR) profile, which carries the tenant-specific onboarding configuration so the device knows which Defender for Endpoint tenant to report to. When the Intune-to-Defender connector is enabled, the onboarding blob is supplied automatically to the EDR policy in many tenants, which is why the connector is step one.
Onboarding is separate from these related controls:
- Microsoft Defender Antivirus policy configures AV behavior. It is not the same as EDR onboarding, and a device can have AV configured but still not be onboarded to Defender for Endpoint.
- Security baseline deploys recommended settings. It can improve posture but does not by itself complete the full risk-to-access chain.
- Compliance policy evaluates state and risk. It does not install the EDR sensor by itself.
- Conditional Access enforces access decisions. It consumes compliance status, not raw Intune assignment status.
Risk, compliance, and response
The exam likes cause-and-effect scenarios. If Defender for Endpoint reports a device as high risk, Intune can mark the device noncompliant when the compliance policy includes the machine risk score rule (you set the maximum allowed risk level, such as Clear, Low, Medium, or High). Microsoft Entra Conditional Access can then block access to resources that require a compliant device until the device is remediated and its risk lowered.
For incident response, Defender for Endpoint actions such as device isolation help contain a compromised device while investigation continues, cutting most network communication while preserving the Defender connection for investigation. For remediation coordination, security tasks turn Defender vulnerability findings into work that Intune admins can act on. These features are operational follow-through; the access-control design still depends on compliance and Conditional Access.
What to monitor
Monitor more than whether the policy is assigned. Check onboarding status, devices missing Defender telemetry, compliance state, Defender risk level, security tasks, and Conditional Access sign-in outcomes. A classic failure pattern is "Defender is onboarded, but access is not blocked," which almost always means the compliance policy never references Defender machine risk, or Conditional Access does not require a compliant device. Treat the chain as four explicit configurations and verify each one rather than assuming the next link inherits the previous step.
Onboarding methods and platform notes
For Intune-managed Windows 10 and 11 devices, the EDR onboarding policy is the standard method, and it relies on the Intune-to-Defender connector supplying the onboarding configuration. Devices that are co-managed with Configuration Manager can be onboarded through Configuration Manager instead, and unmanaged or server devices may use a local onboarding script, group policy, or Microsoft Defender for Cloud. On the exam, when the device is Intune-managed, the expected answer is the EDR onboarding policy, not a manual script.
Defender for Endpoint also extends beyond Windows. Onboarding is supported for macOS, and mobile threat defense for iOS/iPadOS and Android is delivered through Microsoft Defender for Endpoint on mobile, which feeds a device threat level into Intune compliance. That mobile threat level is consumed the same way as Windows machine risk: a compliance policy reads the threat level, marks the device noncompliant above the allowed bar, and Conditional Access enforces the result. The key point is that the risk-to-access pattern is consistent across platforms even though the onboarding mechanism differs.
Separating telemetry from enforcement
A final exam habit worth building is separating visibility from enforcement. Onboarding and the Defender portal give you visibility: alerts, incidents, vulnerability data, and machine risk. Enforcement only happens when that visibility is wired into compliance and Conditional Access. Security tasks bridge the two by handing Defender vulnerability findings to Intune admins as actionable remediation work, but a security task is a recommendation to act, not an automatic access block.
If a stem asks why a known-vulnerable or high-risk device still reaches Microsoft 365, the answer is almost always the missing compliance rule or the missing Conditional Access requirement, not a problem with onboarding itself.
A Windows device is enrolled in Intune and onboarded to Defender for Endpoint, but high device risk does not block Exchange Online access. What is the most likely missing configuration?
Which items are part of a complete Defender for Endpoint risk-based access design? Select all that apply.
Select all that apply
A security analyst suspects ransomware activity on a Defender for Endpoint onboarded Windows device and wants to cut off most network communication while preserving investigation capability. Which action best fits?