Defender for Endpoint is not just an antivirus product. It’s a threat detection and response platform that, when properly connected to Intune, changes how device trust signals flow through your entire environment.
Most environments have Defender running on their devices. Fewer have Defender for Endpoint properly onboarded and connected to the Defender portal. Fewer still have that connection wired into compliance policies so that threat signals actually affect access decisions. Each of those gaps represents a layer of security that’s present but not functioning – which is worse than knowing it’s absent, because it creates false confidence.
Understanding Defender’s role in the architecture starts with the distinction between Defender Antivirus and Defender for Endpoint. Defender Antivirus is the on-device component – real-time protection, malware scanning, definition updates. Every modern Windows device has it. Defender for Endpoint is the cloud-connected platform that aggregates device signals, identifies threats, enables investigation and response, and feeds risk information back into the identity and access layer. The two work together but they’re not the same thing, and onboarding to Defender for Endpoint is a separate step from simply having Defender Antivirus active.
A device with Defender Antivirus running but without Defender for Endpoint onboarding is protected from malware but invisible to your threat detection platform. You won’t know what you don’t see.
Onboarding Defender for Endpoint through Intune is done via the Endpoint Detection and Response policy in the Endpoint Security blade. This is the configuration that connects the device to the Defender for Endpoint service, enables the full telemetry stream, and makes the device visible in the Defender portal. Without this, the device won’t appear in your device inventory in Defender for Endpoint, threat signals won’t be generated, and the device-based risk signals that feed into compliance and Conditional Access won’t exist.
The connection to compliance is where Defender for Endpoint becomes architecturally significant. Intune compliance policies can require that the Microsoft Defender for Endpoint machine risk score is at or below a defined threshold – Low, Medium, High, or Clear. A device that Defender identifies as having active threats, suspicious behavior, or elevated risk can be automatically marked non-compliant in Intune, which then flows to Conditional Access. The concept is sound. The operational reality is more complicated – devices that go inactive for seven or more days stop reporting to Defender’s monitoring window and can be marked non-compliant even when nothing is actually wrong. At scale this creates noise that undermines the signal. Whether to use the risk score in compliance policies is a decision worth making deliberately, with an understanding of how inactivity affects reporting in your specific environment.
This is the loop that makes the trust model described in Phase 1 concrete and operational. A device isn’t just trusted because it enrolled once and passed an initial compliance check. It’s continuously evaluated. A threat surfaces at 2pm on a Tuesday and by 2:01pm the device can be restricted from accessing corporate resources. That response happens automatically, without anyone opening a ticket or making a manual decision.
The Defender for Endpoint risk signal is one of the most powerful inputs to your Conditional Access model – and one of the most commonly left disconnected.
Licensing is relevant here. Defender for Endpoint Plan 1 provides core endpoint protection capabilities. Plan 2 adds endpoint detection and response, threat hunting, vulnerability management, and the automated investigation and response capabilities. Microsoft 365 Business Premium includes Defender for Business, which is a simplified version of Defender for Endpoint designed for smaller organizations. The risk score integration with Intune compliance works across these licensing tiers, but the depth of threat visibility and response capability varies. Know what you have licensed before designing around capabilities you may not have access to.
The Defender for Endpoint portal is also where you monitor ASR rule impact during the audit phase described in the previous article. The Attack Surface Reduction report shows exactly what each rule would have blocked, which applications triggered it, and how frequently. This is the data that informs when it’s safe to move from Audit to Block for specific rules – not a calendar schedule, but actual signal from your environment.
Getting Defender for Endpoint properly connected is not a complex deployment. Onboard through Intune, verify devices appear in the Defender portal, connect the risk score to compliance policies, and validate the signal flow through to Conditional Access. The work is modest. The architectural value – having threat signals that automatically affect access decisions without manual intervention – is significant.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.3.2] ASR Rules: Staged Enforcement From Audit to Block
Next: [5.5] Updates: Autopatch as Default, Rings as the Alternative. ›
