Enrolled Is Not Protected: Defender for Endpoint Onboarding During Autopilot

A new laptop finishes Windows Autopilot. The user reaches the desktop, signs in, and starts working. In the Microsoft Intune admin center the device appears as enrolled and compliant. Every box on the deployment checklist is ticked.

Three weeks later a security analyst runs a hunting query across the estate. That laptop is not in the results. It was never in the results. The device has been enrolled, managed and compliant the whole time, and it has never sent a single byte of sensor data to Microsoft Defender for Endpoint.

The problem: enrolled in Intune, invisible to Defender

Autopilot gives you a satisfying green tick at the end of provisioning. That tick means the device joined Microsoft Entra ID, enrolled with Intune, and completed the Enrollment Status Page. It does not mean the device is protected.

Microsoft Defender for Endpoint is not switched on by enrollment. It is switched on by onboarding, which is a distinct step. Microsoft describes it plainly: "Device onboarding configures your managed devices to communicate with Defender for Endpoint" and "Device onboarding is a one-time action per device". Until that action completes, the sensor has no tenant to talk to.

The gap is easy to miss because the two states are reported in different places. Enrollment shows up in Intune. Onboarding shows up in the Microsoft Defender portal device inventory.

The timings that make the gap invisible

The published expectations are wide enough that a genuinely broken device looks like a slow one for days. These are Microsoft's own figures, drawn from five different articles.

Read that table again. Somewhere between fifteen minutes and several days, silence is normal. That is exactly the window in which a device that will never onboard looks identical to one that is about to.

Why it happens: onboarding is a second handshake, and OOBE gates it

To understand why the failure mode exists, follow the chain. There are six links, and each one can break on its own.

1. The connector. A service-to-service connection is created between Intune and Defender for Endpoint. Microsoft calls this a one-time setup per tenant.
2. The onboarding package. Microsoft states that "when you establish the service connection, Intune automatically receives an onboarding configuration package from Microsoft Defender for Endpoint". Without the connector, Intune has no package to hand out.
3. The policy. An Endpoint detection and response (EDR) policy carries that package to the device. It has to be assigned to something.
4. The policy landing. The management channel writes the onboarding blob into a registry key on the device.
5. The sensor first start. The Sense service reads the blob, starts, and writes its own status key. Microsoft documents this exactly: "When the SENSE service starts for the first time, it writes onboarding status to the registry location HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status".
6. The registration. The sensor registers with the authentication service and starts uploading sensor data. Only now does the device appear in the Defender portal.

Link five is where Autopilot specifically bites.

The sensor waits for OOBE, on purpose

Microsoft has a section titled "Confirming onboarding of newly built devices" that describes this scenario almost word for word. The onboarding package is deployed to newly built devices. The sensor does not start because the out-of-box experience or first user logon has not completed. The device is turned off or restarted before the end user performs a first logon. And then the payoff line: "in this scenario, the SENSE service won't start automatically even though onboarding package was deployed".

The sensor logs its own opinion about this. Three of its event IDs exist purely to report whether Windows Welcome has finished.

The two halves can disagree with each other

Because onboarding is a multi-step handshake, the sensor can be running while onboarding has not completed, or onboarded while the service is not running. Microsoft documents both as known non-compliance cases.

The registry surface

Two separate parent keys are involved. Confusing them is the single most common reason a verification script reports the wrong answer. One is written by the management channel. The other is written by the sensor.

The management side first. This is where the onboarding blob arrives, and where the documented configuration values live.

Now the sensor side. This key does not exist until the sensor has started at least once, which makes its absence a diagnostic in itself.

Antivirus mode is a different question entirely

People conflate "Defender is running" with "Defender for Endpoint is onboarded". They are unrelated measurements. Microsoft Defender Antivirus runs in one of three states, and the state depends partly on whether the device is onboarded.

Note the top two rows. Defender Antivirus in active mode tells you nothing about onboarding. Microsoft also states that "in general, Microsoft Defender Antivirus can be set to passive mode only on endpoints that are onboarded to Defender for Endpoint". That makes passive mode a weak positive signal and active mode no signal at all.

One more Autopilot-adjacent trap

The sensor is a Windows capability, not a downloaded agent. If it is missing, onboarding cannot succeed no matter how well the policy is written. Microsoft documents onboarding-script error 15 as covering exactly this: "The SENSE Feature on Demand (FoD) may not be installed", checked with a read-only DISM query against capability name Microsoft.Windows.Sense.Client~~~~. The CSP article carries the same warning from the other direction: "Windows 11 Home devices that have been upgraded to one of the below mentioned applicable editions might require you to run" the DISM add-capability command before onboarding. Any Autopilot fleet that includes edition-upgraded hardware should expect to meet this.

How to verify: five checks on the device, two in the portals

Verification has to be positive. "Nothing in the log" is not a pass, because a device whose sensor never started has an empty log by definition.

Checks 1 and 2: the registry state and the service

These two together answer most cases. Run them elevated, because both surfaces need administrator rights and read as empty otherwise.

Check 3: the antivirus side

Microsoft's documented method for reading the antivirus mode is a single property. The values you should see when antivirus protection is enabled are Normal, Passive, or EDR Block Mode. Tamper protection is read from the same object, where a value of true means it is enabled.

Check 4: the sensor event channel

The sensor writes to its own dedicated channel. In Event Viewer, open Applications and Services Logs › Microsoft › Windows › SENSE and select Operational. Microsoft notes that SENSE is the internal name for the behavioural sensor that powers Defender for Endpoint. The full channel name for Get-WinEvent is below.

That sequence is the story of a device that finished provisioning, waited for Windows Welcome, then onboarded. Event 11 is the one you are hunting for. Event 4 following it is the proof it is actually talking.

Here is the catalog for the same channel, restricted to the events that bear on onboarding. Microsoft publishes many more, covering quotas, cloud configuration and response commands.

There is a second, separate event surface if you onboarded with a script rather than a policy. It is not in the SENSE channel at all. Microsoft directs you to Event Viewer, then Windows Logs › Application, filtered to the source below.

The antivirus side has its own channel again, distinct from both of the above. It sits under Applications and Services Logs › Microsoft › Windows › Windows Defender › Operational.

Check 5, and the two portal checks

Microsoft's documented end-to-end confirmation is a detection test, which produces a real alert rather than a status field. After onboarding, "you can choose to run a detection test to verify that a device is properly onboarded to the service". That is the only check that exercises the whole chain.

On the tenant side there are exactly two places to look. First, the Intune view of onboarding status.

Microsoft describes the success indicators there as devices appearing in the Defender portal device inventory, an EDR Onboarding Status of "Successfully onboarded", and risk levels appearing in device compliance reports. Reading that tab needs Read permission for Microsoft Defender Advanced Threat Protection in Intune role-based access control, which is why some admins have never seen it populated.

The fix: connector first, then policy, then assignment

Order matters here. Creating the policy before the connector produces a policy that cannot use the automatic package, and nothing in the interface explains why.

Step 1: confirm or create the connector

1. Sign in to the Microsoft Intune admin center and select Endpoint security then Defender for Endpoint.
2. Read Connection status. If it shows Enabled, the services are already connected and you can skip to step 2. If it shows Unavailable, continue.
3. Scroll to the bottom of the Defender for Endpoint page and select Open the Defender Security Center. If you are already connected, that link instead reads Open the Defender for Endpoint admin console.
4. In the Microsoft Defender portal, go to System then Settings then Endpoints then General then Advanced features.
5. Find Intune connection, toggle it to On, then select Save preferences.
6. Return to Intune. Connection status should now show Enabled. Microsoft notes it can take up to 15 minutes to update.

While you are on the Intune Defender for Endpoint page, also set Connect Windows devices to Defender for Endpoint to On under Compliance policy evaluation. Microsoft warns that enabling it connects all applicable devices you currently manage, plus future enrollments, for compliance evaluation. Do that deliberately, not by accident.

Step 2: create the Endpoint detection and response policy

1. Go to Endpoint security then Endpoint detection and response then the Summary tab, and select Create Policy.
2. Set Platform to Windows and Profile to Endpoint detection and response. Select Create.
3. Enter a descriptive name and select Next.
4. For Microsoft Defender for Endpoint client configuration package type, choose Auto from connector. Microsoft marks this as recommended because it uses the automatic onboarding package. The Onboard option, where you paste the blob content yourself, is documented as being for disconnected environments.
5. Set Sample Sharing to All or None. Microsoft notes that None can reduce detection capabilities.
6. Leave Telemetry Reporting Frequency alone. Microsoft states it is deprecated and does not affect new devices, and remains visible only for older policy compatibility.
7. Add scope tags if you use them, then select Next.
8. On Assignments, choose device groups. Microsoft is explicit about the difference: device groups are recommended for immediate deployment, while user groups require user sign-in before the policy applies.
9. Review + create.

Step 8 is the one that quietly creates enrolled-but-unprotected devices in an Autopilot fleet. A user-group assignment cannot apply until somebody signs in, and a device that is provisioned, shelved, and later handed to a different person may never receive it.

The Group Policy and local script routes

Autopilot-provisioned, Entra-joined clients have no Group Policy to receive, so this is not the route for them. It matters anyway, because most estates are mixed, and because the mechanism shows what the Intune policy is doing under the covers. Microsoft's Group Policy onboarding article is scoped to Windows Servers, and it works by running the onboarding script as an immediate scheduled task.

1. Download the Group Policy configuration package from the Microsoft Defender portal at System then Settings then Endpoints then Device management then Onboarding, with Deployment method set to Group policy.
2. Extract it to a shared, read-only location. You should have a folder called OptionalParamsPolicy and the file WindowsDefenderATPOnboardingScript.cmd.
3. In the Group Policy Management Editor, go to Computer configuration then Preferences then Control panel settings.
4. Right-click Scheduled tasks, point to New, then select Immediate Task (At least Windows 7).
5. On the General tab, under Security options, select Change User or Group, type SYSTEM, then Check Names and OK.
6. Select Run whether user is logged on or not and tick Run with highest privileges.
7. On the Actions tab, add a Start a program action pointing at the UNC path of the shared WindowsDefenderATPOnboardingScript.cmd, using the file server's fully qualified domain name.
8. Link the Group Policy Object to the target organisational unit.

Sample collection on that route is an administrative template rather than a registry edit. Copy AtpConfiguration.admx into C:\Windows\PolicyDefinitions and AtpConfiguration.adml into C:\Windows\PolicyDefinitions\en-US, or the equivalent central store paths, then find the setting at Computer Configuration then Policies then Administrative templates then Windows components then Windows Defender ATP. Microsoft notes that if you do not set a value, the default is to enable sample collection.

For one-off testing there is the local script. Microsoft is firm about its scope: "You should use it on a limited number of devices only (10 devices or less)." Download GatewayWindowsDefenderATPOnboardingPackage.zip, extract WindowsDefenderATPLocalOnboardingScript.cmd, and run it from an elevated command prompt. Microsoft also lists this as the last-resort diagnostic when Intune onboarding will not work: "If none of the event logs and troubleshooting steps work, download the Local script from the Device management section of the portal, and run it in an elevated command prompt."

Proof it worked: what a genuinely onboarded device looks like

The companion script collects every surface above in one pass and refuses to give a verdict when a check could not be completed. Below is a real run on a healthy device, trimmed for length, with the device name redacted.

The verdicts the script distinguishes are the point of the whole exercise.

To audit a whole Autopilot fleet rather than one device, run the script as an Intune remediation detection script. It exits 0 only for a genuinely onboarded device. It exits 1 for not-onboarded, onboarded-but-not-reporting and inconclusive, and exits 2 when the sensor surface is absent entirely. Cross-reference the non-zero results against the EDR Onboarding Status tab, and the difference between the two lists is your real exposure.

One closing note on scope, because onboarding is not a small switch. Microsoft states that "onboarding to Defender for Endpoint will onboard the device to Data Loss Prevention (DLP), which is also a part of Microsoft 365 compliance". Offboarding is not small either: it "causes the device to stop sending sensor data to Defender for Endpoint, but data from the device, including references to any alerts it has, is retained for up to 6 months".

References

Microsoft official documentation:

• Configure Microsoft Defender for Endpoint with Intune and onboard devices - the connector, the EDR policy, Auto from connector, and the EDR Onboarding Status tab
• Troubleshoot Microsoft Defender for Endpoint onboarding issues - the Status registry key, the WDATPOnboarding script events, the non-compliance cases, and "Confirming onboarding of newly built devices"
• Review events and errors using Event Viewer - the full Microsoft-Windows-SENSE/Operational event catalog
• WindowsAdvancedThreatProtection CSP - OnboardingState 0 and 1, OrgId, SenseIsRunning, and the Onboarding node
• Microsoft Defender Antivirus compatibility with other security products - active, passive and disabled mode, AMRunningMode, and ForceDefenderPassiveMode
• Onboard Windows Servers to Microsoft Defender for Endpoint via Group Policy - the immediate scheduled task route and the ADMX files
• Onboard Windows Servers using a local script - the 10-device limit and AllowSampleCollection
• Onboard Windows devices to Defender for Endpoint using Intune - the read-only health status properties, the offboarding EDR policy path, and the DLP note
• Protect security settings with tamper protection - IsTamperProtected and RealTimeProtectionEnabled
• Microsoft Defender Antivirus event IDs and error codes - the Windows Defender Operational channel and events 1150, 1151, 2000 and 2001
• Get-MpComputerStatus - the property set including AMRunningMode
• Windows Autopilot Enrollment Status Page - what the ESP actually tracks

Community deep dives, each fetched and confirmed on topic before citing:

The companion script for this post is Get-DefenderOnboardingState.ps1. It is read-only, runs on Windows PowerShell 5.1 and PowerShell 7, prompts before installing anything, and never prints your org ID.