Security settings management lets the Defender for Endpoint sensor pull Intune endpoint security policies onto devices that are not enrolled in Intune. When it works, the device simply appears in both portals as Managed by MDE; when it doesn't, you get silence: no error in either portal and policies that never arrive. The sensor does leave a clue in the registry. This post explains the enrollment flow, decodes every EnrollmentStatus value Microsoft documents, and gives you a triage order for each class of failure.
Symptoms#
- The device is healthy in Assets › Devices in the Microsoft Defender portal, but Managed by does not say MDE and the device page shows an MDE Enrollment status other than Success, or none at all.
- In the Microsoft Intune admin center, Devices › All devices has no record for the device, or the record exists but Managed by never changes to MDE.
- Antivirus, EDR, firewall or ASR policies assigned to the device group stay at Pending in the policy report and
Get-MpPreferenceon the device shows the old values. - Microsoft Entra ID shows a hybrid joined object stuck on Pending, or no object for the device at all.
Why it happens#
The enrollment path has several hand-offs, and the registry value records where it stopped. When a supported device onboards to Defender for Endpoint, the sensor checks for an existing Intune (MDM) enrollment; devices that have one get policy through MDM and are left alone. Devices without one, and inside the enforcement scope you configured, enrol with Intune through the Defender channel. Intune needs a Microsoft Entra device object to target, so the device either reuses its full registration (for example hybrid join) or receives a synthetic device identity that is replaced automatically once a full registration appears. Enrollment, the 90-minute check-in and reporting all run over *.dm.microsoft.com.
Any of those steps can fail: scope, the Intune-side switch, connectivity to Entra ID or Intune, a hybrid join broken by the SCP, DNS or clock, or Configuration Manager still owning the settings. After an attempt the sensor writes a number to HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus. Microsoft publishes the following mapping and notes that it covers the common codes rather than every possible value:
| Error code | Enrollment status | Administrator actions |
|---|---|---|
| 5-7, 9, 11-12, 26-33 | General error | Onboarding to Defender for Endpoint succeeded, but the security configuration management flow failed, possibly because the device does not meet the prerequisites for the Defender management channel. Run the MDE Client Analyzer to find the root cause; if that does not help, contact support. |
| 8, 44 | Microsoft Intune Configuration issue | Onboarding succeeded, but Intune has not been configured in the admin center to allow Defender for Endpoint security configuration. Confirm the Intune tenant is configured and the feature is turned on. |
| 13-14, 20, 24, 25 | Connectivity issue | Onboarding succeeded, but the flow failed on what looks like a connectivity problem. Verify that the Microsoft Entra ID and Microsoft Intune endpoints are open in your firewall. |
| 10, 42 | General Hybrid join failure | Onboarding succeeded, but the operating system failed to perform hybrid join. Use the Microsoft Entra hybrid join troubleshooting guidance for OS-level failures. |
| 15 | Tenant mismatch | Onboarding succeeded, but the Defender for Endpoint tenant ID does not match the Microsoft Entra tenant ID. Make sure the Entra tenant ID of your Defender tenant matches the tenant ID in the SCP entry of your domain. |
| 16, 17 | Hybrid error - Service Connection Point | Onboarding succeeded, but the SCP record is not configured correctly and the device could not be joined to Entra ID, possibly because the SCP points to Enterprise DRS. Point the SCP at Microsoft Entra ID and follow the SCP best practices. |
| 18 | Certificate error | Onboarding succeeded, but a device certificate error stopped the flow: the device certificate belongs to a different tenant. Check that trusted certificate profiles follow best practices. |
| 36, 37 | Microsoft Entra Connect misconfiguration | Onboarding succeeded, but a Microsoft Entra Connect misconfiguration blocked the flow. Run the Device Registration Troubleshooter Tool to see what prevents registration; Windows Server 2012 R2 has dedicated instructions. |
| 38, 41 | DNS error | Onboarding succeeded, but a DNS error blocked the flow. Check the internet connection and DNS settings on the device; Active Directory needs the domain DNS servers, not the router's address. |
| 40 | Clock sync issue | Onboarding succeeded, but the flow failed. Verify that the clock is set correctly and synchronised on the device. |
| 43 | MDE and ConfigMgr | The device is managed by both Configuration Manager and Defender for Endpoint. Controlling policy through both channels can cause conflicts; isolate endpoint security policies to a single control plane. |
| 2 | Device is not enrolled and has never been enrolled | Onboarding succeeded, but the device is not enrolled to be managed by Defender for Endpoint. Review the configuration guidance for Defender for Endpoint. |
| 4 | Device is managed by SCCM Agent | Onboarding succeeded, but the device is configured to be managed by Configuration Manager. To let Defender manage it, go to Settings › Endpoints › Configuration Management › Enforcement Scope and turn off Manage Security settings using Configuration Manager. |
How to fix it#
1. Check scope and switches first#
In the Defender portal, Settings › Endpoints › Configuration management › Enforcement scope must have the device's platform turned on, and if you chose On tagged devices the device needs the MDE-Management tag. In Intune, Endpoint security › Microsoft Defender for Endpoint › Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations must be On. Codes 8 and 44 are almost always this toggle.
2. Read the code#
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\SenseCM' -Name EnrollmentStatus |
Select-Object -ExpandProperty EnrollmentStatusMatch the number against the table and treat it as a class of problem rather than a precise fault.
3. Fix the connectivity class (13-14, 20, 24, 25, 38, 41, 40)#
Confirm the device can reach *.dm.microsoft.com and the device registration endpoints (enterpriseregistration.windows.net, login.microsoftonline.com, device.login.microsoftonline.com) in the system context, not just for a signed-in user, and that those registration URLs are excluded from TLS inspection. Fix DNS so the device resolves through domain DNS, and fix time skew before anything else: certificates and Kerberos both depend on it.
4. Fix the identity class (10, 42, 15, 16, 17, 36, 37, 18)#
Domain-joined devices use normal hybrid join for their identity, so run dsregcmd /status from an elevated prompt and read the Diagnostic Data block: a failed AD Configuration Test means the SCP is wrong or missing, and a Pending object in Entra ID › Devices confirms the device never completed registration. For code 15, compare the tenant ID shown in the Defender portal with the one in your SCP; they must be the same tenant. For 36 and 37, review the Entra Connect sync scope for the computer's OU. Code 18 usually traces back to a trusted certificate profile pushed from another tenant.
5. Resolve ownership conflicts (4, 43)#
Decide which product owns security settings. If Intune policy through Defender should win, turn off Manage Security settings using Configuration Manager in the enforcement scope page and stop deploying the same settings from Configuration Manager.
6. Run the Client Analyzer for everything else (2, 5-7, 9, 11-12, 26-33)#
Run the MDE Client Analyzer on the device and open MDE Client Analyzer Results.htm. Confirm the OS is in scope under General Device Details, check that the device appears in Entra ID under Device Configuration Management Details, and clear every Error and read every Warning in Detailed Results. Two prerequisites that trip people here: Server Core 2016 and earlier, non-persistent VDI and 32-bit Windows are unsupported, and PowerShell locked to Constrained Language Mode stops the feature from working.
Note: most devices enrol within minutes, but Microsoft allows up to 24 hours. Give a device one full cycle after a fix before you start again, and remember the Policy sync button only appears once a device is already managed by Defender.
Verify the fix#
- Defender portal device page: Managed by shows MDE and MDE Enrollment status shows Success.
- Intune Devices › All devices: the device is listed with Managed by MDE. Synthetic registrations show MDM as Intune with a blank Join type in Entra ID; that is expected.
- Open the assigned policy under Endpoint security, select View report and confirm the device reports Succeeded; then compare with
Get-MpPreferenceon the device. - The registry value is no longer one of the error codes above.
Prevent it next time#
- Pilot with On tagged devices and the
MDE-Managementtag; switching a platform to all devices enrols everything in scope at once. - Fix SCP, DNS and time synchronisation as part of server builds; the Defender channel inherits every hybrid join weakness your domain already has.
- Keep one control plane per setting. Decide Configuration Manager or Intune-through-Defender before you turn the feature on, and target policies with dynamic groups on
deviceOSTypeso policy survives a later Intune enrollment. - Bake the registry check into your server monitoring so a value from the error table is noticed before someone asks why a policy is missing.