A device shows Not compliant, and the only failing setting is Require the device to be at or under the machine risk score. The user swears nothing is wrong, the Defender portal shows no alerts, yet Intune disagrees. In this post I'll explain what that setting actually evaluates, then walk the chain between Intune, Microsoft Entra ID and Microsoft Defender for Endpoint so you can find the broken link instead of guessing.
Symptoms#
- In Devices › Compliance (or on the device's Device compliance page) the Windows policy is Not compliant, and the failing setting sits under the Microsoft Defender for Endpoint section of the policy.
- Conditional Access blocks the user with a "device not compliant" message while every other compliance setting is green.
- It often appears on freshly enrolled, re-imaged or renamed devices, or on devices nobody has looked at in the Defender portal for a long time.
Why it happens#
What the setting evaluates#
Defender for Endpoint assigns each onboarded device a risk level, driven mainly by the active alerts on it. Intune receives that level and compares it with the threshold you picked. "At or under" means the device's current level must be equal to or lower than the threshold:
| Threshold | Device stays compliant when | Marked noncompliant when |
|---|---|---|
| Clear | Defender sees no threat at all | Any detected threat, including low severity |
| Low | Only low-level threats exist | Medium or high threats |
| Medium | Low or medium threats exist | High threats only |
| High | Always (reporting only) | Never |
Microsoft recommends Low as the balance for most organisations. If you chose Clear, a single low-severity informational alert is enough to fail the device, and that is working as designed.
The chain that must be intact#
Intune can only evaluate this setting if it receives a risk level for that specific device. In practice, a device with no usable risk signal doesn't pass; Intune won't assume a device is safe when it can't see it. Every link below has to hold:
- Tenant connection: Endpoint security › Defender for Endpoint shows Connection status Enabled, which requires the Microsoft Intune connection toggle in the Defender portal under System › Settings › Endpoints › General › Advanced features.
- Platform toggle: on the same Intune page, Connect Windows devices to Defender for Endpoint is On under Compliance policy evaluation. Android and iOS/iPadOS have their own toggles.
- Onboarded and reporting: the EDR policy applied, the
Senseservice runs, and the device appears in Assets › Devices with a healthy sensor. - Matching identity: Microsoft lists Windows support for this integration as Microsoft Entra joined or hybrid joined devices. The Defender record must map to the same Entra device that Intune manages. Entra registered-only devices, duplicate device objects after a re-image, or a stale Defender record from an old installation all break the mapping.
- Time: newly onboarded devices take 15–30 minutes to show up in Defender, and Intune re-evaluates compliance at check-in (roughly every eight hours for Windows once enrolment settles), so a device onboarded this morning can legitimately look noncompliant for a while.
Typical root causes#
| Cause | How it looks |
|---|---|
| Device never onboarded (EDR policy not assigned, blocked by a conflicting offboarding policy, or still in error) | Missing from the Defender inventory; EDR Onboarding Status isn't "Successfully onboarded" |
| Sense service stopped or sensor unhealthy | Device present but Sensor health state Inactive or Misconfigured |
| Duplicate or stale record | Two entries with the same name; the Active one has no Entra device ID or a different one |
| Onboarded to a different tenant | Sense runs and OnboardingState is 1, but the device isn't in your inventory |
| Connector or platform toggle switched off | Every Windows device fails the setting at once |
| Policy assigned to user groups on userless devices (kiosks, shared, self-deploying Autopilot) | The policy never evaluates as expected; assign compliance to device groups instead |
| Entra registered instead of joined, or identity mismatch | dsregcmd /status shows AzureAdJoined : NO with WorkplaceJoined : YES; Defender's AadDeviceId is empty or differs from Intune's |
| A genuine active alert | Device page shows Risk level Medium or High with open alerts; the device is correctly noncompliant |
How to fix it#
1. Rule out the tenant-level switches#
Open Endpoint security › Defender for Endpoint. Confirm Connection status is Enabled and the Windows compliance toggle is On. If the connector was recently re-enabled, allow up to 15 minutes for the status to update.
2. Confirm the device is onboarded to your tenant#
In Intune, check Endpoint security › Endpoint detection and response › EDR Onboarding Status. On the device, from an elevated PowerShell session:
Get-Service -Name Sense | Select-Object Status, StartType
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' |
Select-Object OnboardingState, OrgId
dsregcmd /status | Select-String 'AzureAdJoined|DomainJoined|WorkplaceJoined|DeviceId'Sense should be Running and OnboardingState should be 1. Then search Assets › Devices in the Defender portal. If the device isn't there although Sense runs, it was onboarded with another tenant's package: offboard it, remove stale onboarding policies, and let your EDR policy onboard it again.
3. Match the identities#
Compare the Microsoft Entra Device ID on the Intune device overview with what Defender holds. With advanced hunting:
DeviceInfo
| where DeviceName startswith "LAPTOP-0421"
| summarize arg_max(Timestamp, *) by DeviceId
| project DeviceName, DeviceId, AadDeviceId, JoinType, OnboardingStatus, SensorHealthStateMore than one DeviceId for the name means a duplicate; the one with the current AadDeviceId is the live record. An empty AadDeviceId or a registered-only join state points at the enrolment: re-join the device properly (Entra joined or hybrid joined) rather than chasing the compliance report. The inventory's Managed by column should read Intune.
4. Look at the actual risk#
Open the device page in the Defender portal and read Risk level and the Alerts tab. If the level exceeds your threshold, the device is correctly noncompliant: investigate, remediate and resolve the alerts. Resolving active alerts is what removes the risk. Exposure level is separate and doesn't drive this setting.
5. Check assignment and conflicting policies#
Make sure the policy reaches the device the way you intend (device groups for userless devices) and that no second compliance policy sets a stricter threshold.
6. Force a re-evaluation#
Trigger Sync on the device in Intune (or Settings › Accounts › Access work or school › Info › Sync on the device), wait, then refresh the compliance report.
Verify the fix#
- The device's compliance page shows the Defender for Endpoint setting as Compliant and the overall state as Compliant.
- The Defender device page shows a risk level at or under your threshold and no active alerts.
- The user can sign in; the Entra sign-in log shows the Conditional Access grant satisfied.
Prevent it next time#
- Onboard devices to Defender before you assign the risk-score setting and the Conditional Access policy, and give new devices a grace period in the actions for noncompliance.
- Assign Windows compliance policies to device groups, especially for shared and kiosk devices.
- Prefer Low over Clear unless a SOC clears informational alerts quickly.
- Review EDR Onboarding Status and the sensor health filter weekly, and use cleanup rules so stale device objects don't confuse the mapping.