Defender for Endpoint onboarding not working: where it stops

Defender for Endpoint onboarding not working usually shows up the same way every time: the Intune EDR policy reports Succeeded, and the device is missing from the Defender portal or sits there as Can be onboarded. Intune is only telling you that it delivered the onboarding settings. Whether the sensor on the device then started, reached the service and reported is a separate question with separate evidence. This post sorts the failure by layer, gives the error text and event IDs Microsoft documents for each, and marks where the documentation stops.

If you are not yet sure the fault is Defender rather than the device’s wider relationship with Intune, start with Intune troubleshooting by symptom, because a device that is not checking in will not onboard either. Every Microsoft fact below was checked against Microsoft Learn on 29 October 2026.

Defender for Endpoint onboarding not working: find the layer

There are four places the chain can break, and each leaves a different trace. Work out which one you are in before you touch a policy.

The service connection is not there

Intune can only hand out the onboarding package if the two services are connected. Microsoft’s guide to configuring Defender for Endpoint with Intune and onboarding devices puts the switch in the Defender portal under System, Settings, Endpoints, General, Advanced features, where Intune connection is turned on and saved. Back in the Intune admin center, under Endpoint security, Defender for Endpoint, the connection status should read Enabled. Microsoft says that can take up to 15 minutes to update. Unavailable means it is not connected.

The tell is in the EDR profile itself. With the connection in place, the setting Microsoft Defender for Endpoint client configuration package type offers Auto from connector, which Microsoft recommends. Without it, the same setting only offers fields to paste an onboard or offboard blob. If you see only the blob fields, fix the connection before anything else.

The policy never landed: 0x87D1FDE8 and 0x87D101A9

When the EDR policy shows Error, the code is usually 0x87D1FDE8, Remediation failed. I have covered what 0x87D1FDE8 means across Intune profiles generally; for onboarding specifically, Microsoft’s troubleshooting guide for Defender for Endpoint onboarding issues lists four distinct causes behind the same code:

1. A wrong blob. Onboarding or offboarding was attempted with a blob that has the wrong signature or is missing the PreviousOrgIds fields. This is the usual result of pasting a package from a different tenant, or an old one.
2. The policy registry key is missing or locked. The key HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection does not exist, or the OMA DM client cannot write to it. Microsoft’s fix is to create the key from an elevated prompt.
3. A read-only property. Something tried to remediate SenseIsRunning, OnboardingState or OrgId, which are read-only. Microsoft’s wording is that onboarding has failed, and the device-side checks below apply.
4. An unsupported edition. The CSP was sent to an edition it does not support. The guide names Enterprise, Education and Professional as supported for this route and states that Server is not.

The unsupported edition case can also return 0x87D101A9, which carries the text SyncML(425): The requested command failed because the sender doesn't have adequate access control permissions (ACL) on the recipient. Despite the wording, Microsoft’s guide attributes it to the platform, not to a permissions fault you can fix.

On the device, the same failures appear in the Admin channel of Microsoft\Windows\DeviceManagement-EnterpriseDiagnostics-Provider as event 1819, Microsoft Defender for Endpoint CSP: Failed to Set Node’s Value, with the node and result in the message.

The policy succeeded and the sensor never started

This is the common case, and the one Intune cannot see. Check the service first. Microsoft’s Intune onboarding guide uses the same command and expects Stopped before onboarding and Running after.

1# Is the Defender for Endpoint sensor running?
2Get-Service -Name Sense | Format-List Status,Name,DisplayName
3
4# Is the sensor capability installed at all? (Windows 11 24H2 upgrades)
5DISM /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~
6
7# Did the onboarding settings reach the policy key?
8Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection'

If the service does not exist, look at Windows 11 version 24H2 first. Microsoft’s known issue KB5043950 states that Defender for Endpoint was removed from the 24H2 base image and has to be installed when a device moves from Home to Pro, which Microsoft describes as by design, and that the same applies when an OEM ships Pro without the feature. Intune reports an error because it cannot apply the policy. The documented remedy is to add the capability with DISM /online /Add-Capability /CapabilityName:Microsoft.Windows.Sense.Client~~~~ from an elevated prompt. Microsoft’s minimum requirements for Defender for Endpoint carry the same command for 24H2 Home devices upgraded to a supported edition.

If the service exists but is not running, the SENSE Operational log under Applications and Services Logs, Microsoft, Windows, SENSE names the reason. The events that matter most:

Two device states look like failures and are not. Microsoft documents that a device which has not completed OOBE can show SenseIsRunning compliant but OrgId, Onboarding and OnboardingState non-compliant, and the fix is to let OOBE finish. A SENSE service on Delayed Start can show the reverse, and Microsoft says that resolves itself within 24 hours. The third documented non-compliance case is a real fault: onboarding and offboarding policies assigned to the same device at the same time.

Antivirus state matters too. The agent depends on Microsoft Defender Antivirus to scan files. If another product is the active antivirus, Defender Antivirus runs in passive mode, which is supported, but Microsoft requires the Defender ELAM driver to stay enabled and says onboarded devices must be excluded from any Group Policy that turns Defender Antivirus off. If two channels are pushing antivirus settings at once, deciding which channel owns your Defender antivirus settings is worth settling first.

Running, but Can be onboarded, Misconfigured or Inactive

Microsoft says a newly onboarded device typically appears in the Defender device inventory within 15 to 30 minutes, and that a device still missing after an hour points to an onboarding or connectivity problem. When it does appear, the onboarding status and the sensor health state tell you different things.

Can be onboarded is a status Microsoft gives to discovered devices, along with Unsupported and Insufficient info. Onboarded devices show Onboarded and typically an Active sensor health state. So a device you deployed the EDR policy to that shows Can be onboarded is being seen by the service through device discovery, not reporting through its own sensor. A Microsoft Q&A thread from March 2025 describes roughly 5,000 of more than 6,000 devices onboarding through an EDR policy while the rest stayed at Can be onboarded with Intune reporting success. No root cause was confirmed in that thread. That is the honest state of public knowledge on this symptom at scale: go to the device-side evidence above.

Misconfigured splits into Impaired communications and No sensor data. Both come back to connectivity first. The sensor reports through WinHTTP, which Microsoft notes is independent of the browser proxy settings, so a device that browses fine can still fail to report. No sensor data also lists the diagnostic data service not set to start automatically, Defender Antivirus disabled by policy, and the ELAM driver disabled.

Inactive means no signal to any Defender for Endpoint channel for more than seven days. A reinstalled or renamed device creates a new entity in the portal and the old one stays Inactive, which is often what an apparent duplicate is.

This last layer is where most reports of Defender for Endpoint onboarding not working end up, because every check in Intune is green by the time you get here. DNS is the cause people miss. In an accepted Microsoft Q&A answer from September 2024, the poster traced devices that onboarded in Intune but never appeared in Defender to outbound DNS filtering on their lab network blocking Microsoft endpoints. Changing the DNS servers fixed it. That is one report, not documentation, but it matches the WinHTTP point above: the sensor needs to resolve and reach the service URLs, and a filtering layer between them fails silently.

The failure modes

Onboarding also feeds compliance. A compliance policy that requires the device to be at or under a machine risk score depends on the Connect Windows devices to Defender for Endpoint setting and on the device reporting. A device that never onboarded cannot produce a risk score, and the compliance result follows the usual Intune compliance reporting delay on top of that. Conditional Access then blocks a user for a Defender fault that looks like an access problem.

What I would do differently

I would onboard through one method only. A 2022 Tech Community thread describes onboarding settings duplicated across a configuration profile and an EDR policy, and a 2025 third-party guide describes devices missing from Defender after a local onboarding script and an EDR policy were combined. Pick the EDR policy with Auto from connector and remove the rest.

I would not treat Succeeded in Intune as onboarded. The only proof is the device in the Defender inventory with Onboarded and Active. Check a sample there after every rollout wave, not the Intune report.

For any Windows 11 24H2 fleet built from upgraded Home licences or from OEM images, I would check the Sense capability as part of the build and add it before the EDR policy arrives. When I need the event logs from a device I cannot reach, collecting Intune diagnostic logs remotely gets most of them without a remote session. Once devices are onboarded, the next thing to verify is the policies that depend on the sensor, starting with attack surface reduction rules that report applied but do nothing.

I have not run this in production. My tenant is a lab with no enrolled devices, so everything above comes from the Microsoft sources named and the dated community threads. Where I would expect it to bite hardest is a filtered network where the browser works through one proxy and WinHTTP has never been told about it.

Last verified: 29 October 2026.