Microsoft Defender for Endpoint Onboarding via Intune: Complete Guide · CloudEngineerHub
Defender12 min read4 views
Microsoft Defender for Endpoint Onboarding via Intune: Complete Guide
Onboard Windows, macOS, and mobile devices to Microsoft Defender for Endpoint with Intune: the EDR policy, the MDE connector, risk-based compliance, and validation steps.
C
CloudEngineerHub Team
Published: August 25, 2026· Last Updated: September 24, 2026·12 min read
Microsoft Defender for Endpoint Onboarding via Intune: Complete Guide
Onboarding is the first and most important Defender for Endpoint milestone: until a device carries a valid onboarding state, it sends no telemetry, appears nowhere in security.microsoft.com, and contributes nothing to your risk posture. For Intune-managed fleets, onboarding is largely automatic once you know which two switches to flip — the Defender connector in Intune and an endpoint detection and response (EDR) policy — and how to verify the result instead of assuming it.
Visual Walkthrough
What must be true before Defender policies can do their job.
Interactive FlowMDE Onboarding — Sensor to Attack Surface Control6/6
1
Licensing verified
MDE P1/P2 entitlements mapped to users (not devices).
deploy
2
Onboarding package via Intune
Configuration profile ships the onboarding blob.
telemetry
3
Sensor reports in
Endpoint sensor connects to MDE service; device visible in portal.
ASR, device control, firewall, web protection via Intune.
6
Attack surface shrinks
Alerts, TVM score and ASR blocks show measurable lift.
MDE Onboarding — Sensor to Attack Surface Control. 1. Licensing verified: MDE P1/P2 entitlements mapped to users (not devices). — 2. Onboarding package via Intune: Configuration profile ships the onboarding blob. — 3. Sensor reports in: Endpoint sensor connects to MDE service; device visible in portal. — 4. OS/platform updated: Defender platform + intelligence updated automatically. — 5. Policies flow: ASR, device control, firewall, web protection via Intune. — 6. Attack surface shrinks: Alerts, TVM score and ASR blocks show measurable lift.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Licensing that includes Microsoft Defender for Endpoint Plan 1 or Plan 2 (for example Microsoft 365 E5, or E3 plus a Defender for Endpoint plan, or Microsoft 365 Business Premium).
Devices enrolled in Intune and syncing (Windows 10/11, macOS, iOS/iPadOS, Android; Windows Server via the modern unified agent for the EDR policy path).
An account with Intune Administrator and Global Administrator or Security Administrator rights for the one-time connector consent.
Access to the Microsoft Defender portal at security.microsoft.com to create onboarding packages for non-Windows platforms and to validate devices later.
A pilot device group before fleet-wide assignment.
How It Works
MDE onboarding binds a device to your Defender workspace: the endpoint runs the Microsoft Defender for Endpoint Service (Sense), which streams signals to the cloud and, in return, receives detections and policy. Two Intune components make this happen:
The MDE connector. In intune.microsoft.com under Tenant administration > Connectors and tokens > Microsoft Defender for Endpoint, you connect the two services. This toggle does two jobs: it enables MDM-based onboarding signals for Windows, and it makes device risk scores available to Intune compliance policies (and optionally to MAM-managed mobile devices without enrollment).
The EDR policy. Under Endpoint security > Endpoint detection and response you create a policy (Windows profile "Endpoint detection and response (EDR)") with settings such as sample sharing and telemetry reporting frequency. For Windows, assigning this policy automatically onboards the device — Intune ships the onboarding configuration inside the policy, so there is no manual blob to install. macOS, Linux, iOS/iPadOS, and Android use onboarding packages downloaded from security.microsoft.com (Settings > Endpoints > Device management > Onboarding) and delivered through Intune apps or configuration profiles.
Once both are in place, device risk flows back: a Windows compliance policy gains the setting to require the device to be at or under a given machine risk score (Cleared, Low, Medium, High), which is the bridge to Conditional Access.
Step-by-Step Implementation
1. Enable the Defender connector
Open Tenant administration > Connectors and tokens > Microsoft Defender for Endpoint. Enable the connection for Windows (MDM), and for MAM on Android/iOS if you manage unenrolled mobile devices. Save and consent when prompted. This is tenant-wide and takes effect within minutes.
2. Create and assign the Windows EDR policy
Endpoint security > Endpoint detection and response > Create policy. Choose Windows as the platform and the EDR profile. Leave telemetry at Normal and sample sharing at All unless your privacy requirements say otherwise, then assign to a pilot ring. Assigned devices onboard automatically at next check-in.
3. Onboard macOS and mobile platforms
Download the onboarding package for macOS from the Defender portal and deploy the agent plus onboarding configuration as an Intune application; iOS/iPadOS and Android onboard through app configuration profiles or MAM when the connector is enabled. Validate each platform with one pilot device before scaling.
4. Validate onboarding
In security.microsoft.com, go to Assets > Devices and confirm pilot devices appear with healthy sensor state — allow roughly 30 minutes after policy sync. Locally, verify the Sense service is running and the onboarding registry status flag is set (script below).
5. Wire risk into compliance and Conditional Access
Create or update a Windows compliance policy using the machine risk score setting, then gate access with a Conditional Access policy requiring compliant devices. Deploy compliance policies before you enforce the Conditional Access grant, and pilot in report-only mode first.
Configuration Deep Dive
Telemetry frequency. Normal balances signal freshness with client overhead; Expedited is for high-value or high-risk endpoints during active campaigns. Changing this fleet-wide without cause burns bandwidth for no detection gain.
Sample sharing. All lets Microsoft collect suspicious files to improve detections; None is common in regulated environments. This is a risk conversation, not a technical one — document the decision.
Baselines and overlap. Intune security baselines for Defender for Endpoint can coexist with EDR policies, but two sources setting the same value cause drift reports and change conflicts. Keep MDE policy (onboarding, telemetry) and baseline policy (hardening) in separate, clearly named policies and assign them to the same rings deliberately. Our related guide covers baseline conflict triage in depth.
Offboarding hygiene. Devices removed from Intune lose the EDR policy and fall off over time. Run a recurring report of onboarded devices (security.microsoft.com) against the Intune inventory so forgotten laptops do not linger as unmanaged sensors.
Real-World Enterprise Scenario
A logistics company onboarded 6,200 Windows endpoints through the EDR policy path in two weeks using four rings (pilot, IT, regional, broad). The failure mode they avoided: an old Group Policy onboarding package from a ConfigMgr pilot two years earlier was still applying to servers, leaving some machines with a stale onboarding state. A registry check identical to the detection script below ran as a remediation across the fleet, produced a clean list of devices where OnboardingState was not 1, and operations reconciled each against the EDR policy assignment. Final result: 99.2 percent sensor coverage, with the remainder decommissioned and retired in Intune.
PowerShell for Defender Onboarding
Script 1 — local onboarding validation (works as a remediation detection script too):
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
# Verify MDE onboarding state locally: registry flag + Sense service$status = Get-ItemProperty -Path'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' -ErrorAction SilentlyContinue
$service = Get-Service -Name Sense -ErrorAction SilentlyContinue
if ($status -and$status.OnboardingState -eq1 -and$service -and$service.Status -eq'Running') {
Write-Output 'Onboarded: OnboardingState=1, Sense service running'
exit 0
}
Write-Output ('Issue: OnboardingState=' + $status.OnboardingState + ', Sense=' + $service.Status)
exit 1# Expected output (healthy device):# Onboarded: OnboardingState=1, Sense service running
Script 2 — fleet-wide protection state report via Graph:
Firewall rules, tunnel, private endpoints segment the path.
layer 4
5
Data
DLP, sensitivity labels, immutable storage protect the crown.
layer 5
6
Assume breach
Each layer assumes the previous one failed — detection everywhere.
posture
Each layer assumes the previous one failed — depth is the strategy.
Defense in Depth — Five Aligned Layers. 1. Identity: Phishing-resistant MFA, PIM, conditional access gate everything. — 2. Endpoint: Compliance, EDR sensors, ASR, WDAC, encryption at the device. — 3. Application: Safe Links, app control, least-privilege app consents. — 4. Network: Firewall rules, tunnel, private endpoints segment the path. — 5. Data: DLP, sensitivity labels, immutable storage protect the crown. — 6. Assume breach: Each layer assumes the previous one failed — detection everywhere.
Common Errors
"Connector toggle is grayed out." Your role or licensing does not allow the change; use Global Administrator for the consent step.
HTTP 403 on windowsProtectionState reads. The session scope lacks DeviceManagementManagedDevices.Read.All; reconnect with that scope.
Policy assigned but devices report noncompliant with risk unknown. Risk requires the connector plus a synced EDR policy; wait one full check-in cycle before judging.
Filter errors on managedDevices. Not every property is filterable; if a $filter clause fails, fetch with $select and filter client-side.
Best Practices
Onboard in rings: pilot, IT, region, fleet — never one assignment to All Devices on day one.
Keep onboarding (EDR policy) and hardening (security baselines) in separate policies to make drift legible.
Document the connector, baseline, and EDR policy owners; MDE spans Intune and Security teams, and unowned gaps become incidents.
Reconcile the Defender device inventory against Intune weekly; both over- and under-counting hide risk.
Test the risk-based compliance policy with a controlled detection (a benign test alert) before tying it to Conditional Access.
Security Considerations
The MDE connector grants Intune visibility into device risk — restrict who can edit compliance policies and connector settings with scoped roles.
Onboarding packages identify your workspace; treat them as configuration data and store them in a controlled location, not on public shares.
Risk-based Conditional Access locks users out when risk is high; design break-glass exclusions (two cloud-only emergency accounts) before enforcement.
Sample sharing decisions should be recorded with your privacy/legal teams and revisited annually.
Monitor for sensor health tampering: Sense service stopped, onboarding state cleared, or protection disabled are all signals worth alerting on.
FAQ
Q: Do I still need to download an onboarding package for Windows?
A: No. When devices are enrolled in Intune and the Windows EDR policy is assigned, onboarding is handled by the policy itself. Manual packages are for non-Intune-managed platforms or edge cases.
Q: What is the difference between the connector and the EDR policy?
A: The connector links the two services and enables risk-based compliance; the EDR policy actually onboards devices and sets sensor behavior. You need both for the full integration.
Q: How long until a device appears in the Defender portal?
A: Typically within 30 minutes of onboarding policy application and check-in. Investigate the registry status and service on the device first if it does not appear after a few hours.
Q: Can I onboard Android devices without enrollment?
A: Yes. With the MAM connection enabled, unenrolled Android and iOS devices that use app protection policies can send signals and be gated in app-protection-based Conditional Access scenarios.
Q: Should I use the Defender for Endpoint security baseline or the Microsoft Defender Antivirus baseline?
A: They serve different scopes. Start with the MDE baseline only if you manage MDE settings through Intune, and avoid assigning multiple baselines that set the same values to the same devices.
Conclusion
Defender for Endpoint onboarding through Intune is a two-switch deployment with a long tail of hygiene: connector, EDR policy, validation, then risk-based compliance. Automate the validation with the scripts above, ring your assignments, and the security portal becomes the single place where your fleet's sensor health — and the risk signals that drive Conditional Access — finally live.
Comments
0No comments yet — be the first to share your thoughts.