Most Intune compliance policies check that a device is encrypted, patched and has a PIN. None of that tells you whether the device is compromised right now. Feeding Defender device risk into Intune compliance closes that gap. When Microsoft Defender for Endpoint detects an active threat and raises a device’s risk level, Intune marks it noncompliant, and Conditional Access cuts its access to Microsoft 365 until the threat is cleaned up.
This is one of the highest-value integrations in the Microsoft security stack, and in the tenants I review it is often half built: Defender is deployed, compliance exists, but the two are not talking. This guide shows how to connect them properly.
How the risk signal flows
The chain has four links, and all four must be in place:
Defender detects a threat on the device and calculates a machine risk level: Clear, Low, Medium or High.
The Defender connector sends that risk level to Intune.
The compliance policy compares it to the maximum risk you allow. Above the threshold, the device becomes noncompliant.
Conditional Access requires a compliant device, so the noncompliant device loses access to email, Teams, SharePoint and other protected apps.
When Defender remediates the threat and the risk drops, the device returns to compliant and access comes back automatically. No help desk ticket, no manual block. That is the point: the response happens in minutes, not when someone gets around to reading an alert.
What you need before you start
Devices onboarded to Defender for Endpoint. For Windows, an Intune EDR policy is the cleanest way. For iOS and Android, the Microsoft Defender app deployed from Intune.
Intune licensing for the users and devices in scope.
Microsoft Entra ID P1 for Conditional Access. Business Premium, E3 and E5 include it.
A Defender plan that supports the integration. Check your plan’s feature list against Microsoft’s current documentation before you rely on the signal for access decisions.
Step 1: Connect Defender and Intune
In the Microsoft Defender portal, go to Settings > Endpoints > Advanced features and turn on Microsoft Intune connection.
In the Intune admin center, go to Tenant administration > Connectors and tokens > Microsoft Defender for Endpoint.
Under the compliance policy evaluation section, turn on the toggles to connect each platform you manage (Windows, Android, iOS/iPadOS, macOS) to Defender for Endpoint for compliance evaluation.
Save, then confirm the connection status shows as connected.
Missing one platform toggle is the most common reason the setup half works. Windows reports risk, phones do not, and nobody notices.
Step 2: Add the risk setting to compliance
Edit your existing compliance policy for each platform, or create one, and set:
Microsoft Defender for Endpoint > Require the device to be at or under the machine risk score
The choice of threshold matters:
Threshold
What it means
When to use
Clear
Any detected threat makes the device noncompliant.
High-risk roles and regulated data, if you accept more interruptions.
Low
Low-level threats allowed. Medium or High blocks.
My default for most businesses.
Medium
Only High risk blocks.
A first step if you are cautious about false positives.
High
All levels allowed.
Reporting only. Does not protect anything.
I usually start at Medium for two weeks to see how often it triggers, then tighten to Low. Under Actions for noncompliance, keep Mark device noncompliant immediately for risk, rather than giving a long grace period. A compromised device should not keep access for three days.
If you use a separate compliance policy just for the risk setting, that is fine. Policies combine, and a device must pass all of them to be compliant.
Step 3: Require compliant devices in Conditional Access
Compliance on its own does nothing until Conditional Access uses it. Create or confirm a policy in the Entra admin center:
Users: all users, excluding your break-glass emergency accounts.
Target resources: all cloud apps, or at minimum Office 365.
Grant: require device to be marked as compliant.
State: Report-only first. Review sign-in logs for a few days, then turn it on.
Watch for devices that are not enrolled at all, such as personal phones. A require-compliant policy blocks them too. For BYOD, use app protection policies instead, which I cover below.
Step 4: Cover unenrolled phones with app protection
Personal phones often are not enrolled in Intune, so they have no compliance state. You can still use Defender risk on them through app protection policies. In the policy’s Conditional launch section, add the device condition Max allowed device threat level, choose a level, and set the action to Block access or Wipe data.
Users then need the Microsoft Defender app on the phone, signed in, for Outlook and Teams to open. If Defender reports a threat above your level, the protected apps block or wipe corporate data only, leaving personal data alone. Our BYOD for Microsoft 365 page covers this pattern in more detail.
Test it before you trust it
Pick a test device in the pilot group.
Run one of the safe detection tests Microsoft documents for Defender for Endpoint to raise an alert.
Confirm the device risk level rises in the Defender portal.
Confirm Intune shows the device as noncompliant with the Defender setting as the reason.
Confirm the user is blocked from Outlook and Teams on that device.
Resolve the alert, and confirm access returns after the next check-in.
Write down how long each step took. That is your real response time, and it is useful evidence for cyber insurance questionnaires.
Common gaps I find
Defender connector on, but compliance toggles off for mobile platforms.
Risk setting configured, but Conditional Access never enforces compliance.
Threshold left at High, so it reports and never blocks.
A long grace period on noncompliance, giving compromised devices days of access.
Break-glass accounts not excluded from Conditional Access.
If you have Defender and Intune but are not sure the link is working, our Defender for Endpoint service includes this integration, and an Intune health check will confirm each link in the chain. For round-the-clock response to the alerts that trigger it, see our managed security service.
What machine risk score should I require in Intune compliance?
Low is a good default for most businesses. Start at Medium for a couple of weeks to measure how often it triggers, then tighten. High only reports and never blocks.
Does Defender device risk compliance work on iPhones and Android phones?
Yes. Enrolled devices use the machine risk score in compliance policy. Unenrolled personal devices can use the max allowed device threat level in app protection policy, with the Defender app installed.
Will users get access back automatically after a threat is removed?
Yes. Once Defender remediates the threat and the risk level drops below your threshold, the device becomes compliant again at its next check-in and Conditional Access allows it.
Want to see whether a compromised device in your tenant would actually lose access today? Book a free Microsoft 365 security assessment and we will test the chain from detection to block.
Most Intune compliance policies check that a device is encrypted, patched and has a PIN. None of that tells you whether the device is compromised right now. Feeding Defender device risk into Intune compliance closes that gap. When Microsoft Defender for Endpoint detects an active threat and raises a device’s risk level, Intune marks it noncompliant, and Conditional Access cuts its access to Microsoft 365 until the threat is cleaned up.
This is one of the highest-value integrations in the Microsoft security stack, and in the tenants I review it is often half built: Defender is deployed, compliance exists, but the two are not talking. This guide shows how to connect them properly.
How the risk signal flows
The chain has four links, and all four must be in place:
When Defender remediates the threat and the risk drops, the device returns to compliant and access comes back automatically. No help desk ticket, no manual block. That is the point: the response happens in minutes, not when someone gets around to reading an alert.
What you need before you start
Step 1: Connect Defender and Intune
Settings > Endpoints > Advanced featuresand turn on Microsoft Intune connection.Tenant administration > Connectors and tokens > Microsoft Defender for Endpoint.Missing one platform toggle is the most common reason the setup half works. Windows reports risk, phones do not, and nobody notices.
Step 2: Add the risk setting to compliance
Edit your existing compliance policy for each platform, or create one, and set:
Microsoft Defender for Endpoint > Require the device to be at or under the machine risk scoreThe choice of threshold matters:
I usually start at Medium for two weeks to see how often it triggers, then tighten to Low. Under Actions for noncompliance, keep Mark device noncompliant immediately for risk, rather than giving a long grace period. A compromised device should not keep access for three days.
If you use a separate compliance policy just for the risk setting, that is fine. Policies combine, and a device must pass all of them to be compliant.
Step 3: Require compliant devices in Conditional Access
Compliance on its own does nothing until Conditional Access uses it. Create or confirm a policy in the Entra admin center:
Watch for devices that are not enrolled at all, such as personal phones. A require-compliant policy blocks them too. For BYOD, use app protection policies instead, which I cover below.
Step 4: Cover unenrolled phones with app protection
Personal phones often are not enrolled in Intune, so they have no compliance state. You can still use Defender risk on them through app protection policies. In the policy’s Conditional launch section, add the device condition Max allowed device threat level, choose a level, and set the action to Block access or Wipe data.
Users then need the Microsoft Defender app on the phone, signed in, for Outlook and Teams to open. If Defender reports a threat above your level, the protected apps block or wipe corporate data only, leaving personal data alone. Our BYOD for Microsoft 365 page covers this pattern in more detail.
Test it before you trust it
Write down how long each step took. That is your real response time, and it is useful evidence for cyber insurance questionnaires.
Common gaps I find
If you have Defender and Intune but are not sure the link is working, our Defender for Endpoint service includes this integration, and an Intune health check will confirm each link in the chain. For round-the-clock response to the alerts that trigger it, see our managed security service.
Microsoft’s walkthrough: Configure Conditional Access with Microsoft Defender for Endpoint.
Frequently asked questions
What machine risk score should I require in Intune compliance?
Low is a good default for most businesses. Start at Medium for a couple of weeks to measure how often it triggers, then tighten. High only reports and never blocks.
Does Defender device risk compliance work on iPhones and Android phones?
Yes. Enrolled devices use the machine risk score in compliance policy. Unenrolled personal devices can use the max allowed device threat level in app protection policy, with the Defender app installed.
Will users get access back automatically after a threat is removed?
Yes. Once Defender remediates the threat and the risk level drops below your threshold, the device becomes compliant again at its next check-in and Conditional Access allows it.
Want to see whether a compromised device in your tenant would actually lose access today? Book a free Microsoft 365 security assessment and we will test the chain from detection to block.