7.1 Onboarding Devices

75 minutes · Module 7

Onboarding Devices to Defender for Endpoint

By the end of this subsection, you will know the four onboarding methods, when to use each, how to verify onboarding with KQL, and how to detect coverage gaps across your device fleet.

An unonboarded device is invisible to Defender for Endpoint. No telemetry, no alerts, no investigation capability, no response actions. Onboarding is the foundation — every other subsection in this module depends on it.

Onboarding methods

Method	Best for	Scale	Prerequisites	Maintenance
Microsoft Intune	Cloud-managed devices	Thousands	Device enrolled in Intune	Automatic — new enrollments onboard automatically
Group Policy (GPO)	On-premises AD environments	Thousands	Domain-joined, GPO infrastructure	Manual — new OUs may need GPO linked
Local script	Individual devices, testing, POC	1 at a time	Local admin access	Manual per device
Configuration Manager (SCCM/MECM)	Existing ConfigMgr infrastructure	Thousands	ConfigMgr deployed	Integrated with ConfigMgr compliance

Intune is the recommended method for most organizations

A single Intune configuration profile pushed to all enrolled devices. No scripts to maintain, no GPO to troubleshoot, no manual intervention. When a new device enrolls in Intune, it automatically onboards to Defender. This is the method used in subsection 7.8 for the compliance integration that blocks AiTM attacks.

Intune onboarding walkthrough

Navigate to the Defender portal → Settings → Endpoints → Onboarding
Select “Microsoft Intune” as the deployment method
Download the onboarding configuration package
In the Intune admin center, navigate to Endpoint Security → Endpoint Detection and Response
Create a new EDR policy targeting all Windows devices
Upload the configuration package from step 3
Assign the policy to your device groups (or “All devices”)
Devices receive the policy at next Intune sync (typically within 1 hour)

Platform coverage and limitations

Platform	Sensor type	EDR capability	ASR support	TVM support	Key limitation
Windows 10/11	Built-in (enable via policy)	Full	Full	Full	None — complete capability
Windows Server 2016+	Built-in (enable via policy)	Full	Full	Full	Server Core uses different onboarding package
Windows Server 2012 R2	MDE unified agent (separate install)	Full	Limited	Full	Requires manual agent install, no built-in sensor
macOS 13+	Separate package (Intune/Jamf)	Full EDR	Limited (network protection only)	Partial	System Extensions must be approved; some ASR rules unsupported
Linux (RHEL/Ubuntu/etc.)	Separate package (apt/yum)	EDR only	Not supported	Limited	Manual install, no ASR, command-line management
iOS	Defender app + Intune	Web protection + jailbreak detection	Not supported	Not supported	No EDR — app-level protection only
Android	Defender app + Intune	Web protection + malware scan	Not supported	Not supported	No EDR — app-level protection only

macOS System Extensions are the #1 onboarding failure on Mac

macOS requires explicit approval for kernel and system extensions. If the Defender system extension is not approved, the sensor installs but cannot capture process or network telemetry. On Intune-managed Macs, deploy a system extension profile that pre-approves the Microsoft Defender extensions. On Jamf, use PPPC (Privacy Preferences Policy Control) profiles. Without this step, your Macs appear onboarded but are blind.

Verification — is the device reporting?

1
2
3
4
5
6
7
8
DeviceInfo
| where TimeGenerated > ago(24h)
| summarize arg_max(TimeGenerated, *) by DeviceId
| project DeviceName, OSPlatform, OSVersion,
    OnboardingStatus, SensorHealthState,
    MachineGroup, LastSeen = TimeGenerated
| sort by LastSeen desc
| take 20

Expected Output

DeviceName	OSPlatform	OnboardingStatus	SensorHealthState	LastSeen
DESKTOP-NGE042	Windows10	Onboarded	Active	14:32
LAPTOP-NGE015	Windows11	Onboarded	Active	14:31
MAC-NGE008	macOS	Onboarded	Active	14:28
SRV-FILE01	WindowsServer2019	CanBeOnboarded	—	—

What to look for: OnboardingStatus = Onboarded + SensorHealthState = Active confirms telemetry is flowing. SRV-FILE01 at "CanBeOnboarded" is a coverage gap — the device is known to the environment but not protected. arg_max(TimeGenerated, *) deduplicates to the most recent record per device.

Coverage gap detection

Run this query weekly to find every device that should be onboarded but is not:

1
2
3
4
5
6
DeviceInfo
| where TimeGenerated > ago(7d)
| summarize arg_max(TimeGenerated, *) by DeviceId
| where OnboardingStatus != "Onboarded"
| summarize DeviceCount = count() by OSPlatform, OnboardingStatus
| sort by DeviceCount desc

Expected Output

OSPlatform	OnboardingStatus	DeviceCount
WindowsServer2019	CanBeOnboarded	3
Windows10	CanBeOnboarded	1

What to look for: 3 Windows servers and 1 Windows 10 device not onboarded. Servers are priority — they host sensitive data and are common lateral movement targets. The Windows 10 device may be a personal device or a recently deployed machine that missed the Intune policy. Investigate each and onboard.

Fleet coverage metrics

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
DeviceInfo
| where TimeGenerated > ago(7d)
| summarize arg_max(TimeGenerated, *) by DeviceId
| summarize
    TotalDevices = count(),
    Onboarded = countif(OnboardingStatus == "Onboarded"),
    NotOnboarded = countif(OnboardingStatus != "Onboarded"),
    HealthyActive = countif(SensorHealthState == "Active"),
    Unhealthy = countif(OnboardingStatus == "Onboarded" and SensorHealthState != "Active")
| extend CoveragePercent = round(Onboarded * 100.0 / TotalDevices, 1),
    EffectiveCoverage = round(HealthyActive * 100.0 / TotalDevices, 1)

Expected Output

TotalDevices	Onboarded	NotOnboarded	HealthyActive	Unhealthy	CoveragePercent	EffectiveCoverage
493	489	4	484	5	99.2%	98.2%

What to look for: Two metrics matter: CoveragePercent (onboarded/total) and EffectiveCoverage (healthy+active/total). The gap between them (99.2% vs 98.2%) represents 5 devices that are onboarded but unhealthy — the sensor is installed but not reporting. These 9 devices (4 not onboarded + 5 unhealthy) are your blind spots.

Try it yourself

Run the fleet coverage metrics query in your environment or the demo workspace. Calculate both CoveragePercent and EffectiveCoverage. What is the gap between them? What could cause devices to be onboarded but not healthy?

Common causes of onboarded but unhealthy:

1. Device powered off or offline — common for laptops not used recently. Not a configuration problem.

2. Network connectivity issue — the device cannot reach *.securitycenter.windows.com on port 443. Firewall or proxy blocking.

3. Sensor service stopped — the "Microsoft Defender for Endpoint Service" (SENSE) is not running. Check with sc query sense on the device.

4. Tamper protection disabled and sensor was tampered with — an attacker or admin disabled components. Investigate immediately.

5. Disk full — the sensor cannot buffer telemetry. Clear disk space and restart the sensor.

Check your understanding

1. CoveragePercent shows 99.2% but EffectiveCoverage shows 98.2%. What do the missing 1% represent?

Devices that are onboarded (sensor installed) but not healthy (sensor not actively reporting). These are blind spots — the device appears covered in the inventory but generates no telemetry. An attacker on one of these devices operates undetected.

Rounding error

Devices that do not support Defender

The gap between onboarded and effectively covered is the most dangerous metric because it represents false confidence. You believe you have coverage when you do not. Track EffectiveCoverage, not just CoveragePercent.

2. A macOS device shows "Onboarded" and "Active" but generates zero process telemetry. What is the most likely cause?

The macOS System Extension for Microsoft Defender was not approved. The sensor installs and reports health (appears active) but cannot capture process or network events without the system extension. Deploy a system extension approval profile via Intune or Jamf.

macOS does not support process telemetry

The device needs to reboot

This is the most common Mac onboarding gotcha. The sensor health check passes but telemetry is empty. Always verify both health status AND actual telemetry presence for non-Windows platforms.

3. Which onboarding method provides automatic onboarding for new devices without any manual steps?

Microsoft Intune — when a new device enrolls, it automatically receives the EDR policy and onboards. No scripts, no GPO refresh, no manual intervention. This is why Intune is the recommended method for cloud-managed environments.

Group Policy — processes on next gpupdate

Local script — fastest for individual devices

Intune is the only method where new devices automatically onboard at enrollment time. GPO requires the device to be in the correct OU and process group policy. Local script is manual per device. ConfigMgr requires the device to be in a targeted collection.

7.2 Sensor and Client Configuration →