Deploying Microsoft Defender for Endpoint via Intune (Step-by-Step) · CloudEngineerHub
Security10 min read8 views
Deploying Microsoft Defender for Endpoint via Intune (Step-by-Step)
A production deployment walkthrough for MDE through Intune: EDR onboarding policy, antivirus hardening, ASR rules in audit-then-enforce mode, and validation with Advanced Hunting.
C
CloudEngineerHub Team
Published: September 11, 2026· Last Updated: September 24, 2026·10 min read
Deploying Microsoft Defender for Endpoint via Intune
Deploying Microsoft Defender for Endpoint (MDE) through Intune replaces the old bolt-on world — GPO scripts, manual onboarding, disconnected consoles — with a single policy channel: devices enroll, receive an EDR onboarding profile, harden their antivirus posture, and start streaming sensor telemetry to the Defender portal. This walkthrough is the production sequence, including the ASR audit-then-enforce discipline that separates quiet rollouts from helpdesk storms.
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: Microsoft Defender for Endpoint Plan 1 or P2 (or Microsoft 365 E5/E3 with the relevant add-ons), plus Intune for the policy channel.
Access to both portals: intune.microsoft.com for policy, security.microsoft.com for onboarding, sensor health, and hunting.
Devices on supported Windows 10/11 builds with current servicing; macOS and Linux onboard via their own packages when in scope.
Defender portal RBAC sorted early: who can manage onboarding packages, who can read sensor health, who can act on incidents.
A decision on the management path: Intune-managed devices use the Intune EDR policy; servers or non-Intune endpoints use the Defender portal packages or scripts.
How MDE Onboarding Works
Interactive FlowMDE onboarding pipeline6/6
1Devices enrolled in Intune
2MDE onboarding configuration profile
3Sensor reports to Defender portal
4Security baselines applied
5ASR rules enforced
6Alerts, investigations & response✦
MDE onboarding pipeline. Full text: Devices enrolled in Intune
MDE onboarding configuration profile
Sensor reports to Defender portal
Security baselines applied
ASR rules enforced
Alerts, investigations & response
The onboarding configuration is a small blob of tenant-specific settings that tells the local Sense service how to connect to your Defender for Endpoint workspace. When you deliver it through Intune, the endpoint detection and response (EDR) CSP writes that configuration during policy application — no scripts, no user action. The sensor then registers the device, begins behavioral telemetry, and appears in the Defender portal's device inventory within minutes to an hour, depending on connectivity to the service endpoints.
Everything downstream builds on that sensor: antivirus reporting, attack surface reduction events, vulnerability management assessments, and incidents. Which is why the deployment order matters — onboarding first, antivirus policy second, ASR rules in audit third, enforcement last. Devices that appear "partially onboarded" or never appear at all are almost always a connectivity, servicing, or third-party-AV conflict, and the rest of this guide spends its troubleshooting time exactly there.
Step-by-Step: The Deployment Sequence
Generate the onboarding configuration. In the Defender portal: Settings → Endpoints → Onboarding, choose the OS, and select the Intune management path. For Intune-managed devices you do not distribute a package by hand — the EDR policy carries the tenant configuration.
Create the EDR onboarding policy in Intune.Endpoint security → Endpoint detection and response → Create policy, platform Windows 10/11, profile EDR, and set Microsoft Defender for Endpoint to onboard. Scope it to your pilot group first.
Baseline the antivirus posture.Endpoint security → Antivirus profile: real-time protection on, cloud-delivered protection on, automatic sample submission per your privacy review, and tamper protection enabled (it is on by default when MDE and Intune manage the device).
Deploy ASR rules in audit mode. Start with the high-value trio — LSASS credential stealing, Office child processes, executable content from email — and let audit data speak for a couple of weeks.
Validate, then enforce. Confirm sensor health and audit events (commands and queries below), tune exclusions, then flip ASR rules from audit to block in waves.
Prepare offboarding from day one. Create the corresponding offboarding EDR policy now, so decommissioned devices leave the sensor fleet cleanly instead of polluting the inventory.
Configuration Deep Dive: Policies, Baselines, and ASR Discipline
Three Intune surfaces shape MDE behavior, and mixing them carelessly is the classic conflict generator: the EDR policy (onboarding/offboarding), the Antivirus policy (engine and protection settings), and security baselines (bundles that may also touch Defender settings). The clean pattern is one owner per setting: EDR policy for onboarding state, antivirus policy for engine behavior, baselines only if you are prepared to diff their Defender blocks against your other policies.
ASR rules deserve their own lifecycle. Audit mode produces events without blocking; review them in the Defender portal's ASR report and with Advanced Hunting, tune the small number of legitimate business processes that trip rules via per-rule exclusions, and only then move to block. Flipping rules to block before reading audit data is how legitimate invoicing macros get blocked on day one. Also resist per-device exclusions asked for in helpdesk tickets — exclusion sprawl is a security debt that compounds silently.
Real-World Enterprise Scenario
A 5,000-seat professional services firm onboarded everything through the Intune EDR policy, and the portal device inventory stabilized at 92 percent healthy. The missing 8 percent shared a profile: devices where a legacy third-party antivirus suite was still installed, leaving the Defender engine in passive mode and behavioral monitoring disabled. The fix was subtraction, not addition — retire the legacy agent through a Win32 app supersedence, enforce the antivirus policy to re-activate real-time protection, and verify with Get-MpComputerStatus that the running mode flipped back. Sensor health reached 99 percent in a week, and the ASR block rollout that had been frozen pending "false positive panic" proceeded with only two per-rule exclusions.
PowerShell: On-Device Validation
On any managed device, confirm the sensor and engine state in thirty seconds:
PowerShell
1
2
3
4
5
6
7
8
9
10
11
12
13
# MDE sensor service
Get-Service Sense
# Expected: Status Running, DisplayName Microsoft Defender Advanced Threat Protection Service# Engine and protection state
Get-MpComputerStatus |
Select-Object AMRunningMode, RealTimeProtectionEnabled, BehaviorMonitorEnabled, AntivirusSignatureLastUpdated
# Expected: AMRunningMode Normal; RealTimeProtectionEnabled True; signature within 1-2 days# Current ASR rules and their modes
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions
# Expected: paired GUID/action lists — Actions: 1 = Block, 2 = Audit, 0/6 = disabled variants
Set a rule to audit locally (for lab testing only — production pushes policy):
PowerShell
1
2
3
# Block credential stealing from LSASS — audit first (2), enforce later (1)
Add-MpPreference -AttackSurfaceReductionRules_Ids9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions AuditMode
# Expected: no output; rule visible in Get-MpPreference as audit
Then hunt across the fleet in the Defender portal:
KUSTO
1
2
3
4
5
DeviceEvents
| where ActionType startswith "Asr"
| summarize Events = count() by ActionType, InitiatingProcessFileName
| order by Events desc
// Expected: ASR audit hits grouped by rule and offending process
Troubleshooting Matrix
Symptom
Cause
Fix
Device never appears in Defender inventory
EDR policy not applied, or no line of sight to service endpoints
Verify policy status in Intune; test connectivity; check Sense service
"Partially onboarded" sensor health
Stale onboarding state or interrupted application
Re-apply the onboarding policy; reboot; confirm no third-party agent interference
Real-time protection off
Third-party AV present, Defender in passive mode
Remove the legacy agent; enforce antivirus policy; verify AMRunningMode Normal
ASR rule blocked a legitimate app
Rule too aggressive for that workflow
Per-rule exclusion, not global disable; document the exception
Tamper protection "unexpected" states
Device not fully managed by Intune/MDE pairing
Confirm tenant attachment and management channels; re-check after sync
Offboarded device still in inventory
Retention window, or sensor still running
Deliver offboarding policy; let inventory retention age it out
Common Errors
"Real-time protection is off" banners on newly onboarded devices — a leftover third-party product. Remove it cleanly (its uninstaller, not file deletion) before enforcing the Defender policy.
ASR audit noise from LOB tooling — expected. Tune with per-rule exclusions based on audit data; never ship rules straight to block.
Onboarding policy "succeeded" but sensor idle — connectivity or time skew. Validate egress to the MDE service endpoints and correct the clock.
Conflicting Defender settings — two policies (baseline + custom) fighting over the same value. Give each setting one owner and diff your baselines.
Visual Walkthrough
The audit-tune-enforce conveyor that keeps block mode safe to run.
Interactive FlowASR Rules — Event to Enforced Block5/5
Event 1122 = would-have-blocked; evidence without impact.
tune
3
Exclusions tuned
False positives resolved via path/signer exclusions.
enforce
4
Block mode 1121
Rule flips to block; event 1121 confirms real enforcement.
telemetry
5
MDE reports trend
Attack surface reduction report tracks blocks across fleet.
ASR Rules — Event to Enforced Block. 1. Behavior matches rule: Office spawning child, script downloading payload — rule fires. — 2. Audit mode logs 1122: Event 1122 = would-have-blocked; evidence without impact. — 3. Exclusions tuned: False positives resolved via path/signer exclusions. — 4. Block mode 1121: Rule flips to block; event 1121 confirms real enforcement. — 5. MDE reports trend: Attack surface reduction report tracks blocks across fleet.
Best Practices
Onboard → antivirus → ASR audit → enforce, in that order, with pilot groups between each stage.
One owner per Defender setting; avoid stacking baselines and custom policies on the same values.
Review ASR audit events on a schedule; tune, then enforce in waves, never fleet-wide overnight.
Keep a tested offboarding policy and a decommission runbook — leaving sensors on retired machines is inventory rot.
Watch the sensor health report weekly; it is the earliest warning of egress, servicing, or agent conflicts.
Security Considerations
Tamper protection stays on; it is what keeps local administrators from quietly disabling the engine.
Treat exclusions as attack surface: minimize count, scope them narrowly, and re-review quarterly.
Restrict Defender portal RBAC to named individuals; incident response rights are privileged access.
ASR enforcement changes can disrupt business processes — change-manage them like any production control.
Sensor telemetry contains process and file data; align retention and privacy expectations with your DPO before widening collection.
FAQ
Do I still need the onboarding script from the Defender portal?
Not for Intune-managed devices — the EDR policy carries the configuration. Scripts remain for non-Intune endpoints and servers.
How long until an onboarded device shows in the portal?
Typically minutes to an hour after policy application, assuming connectivity to the service endpoints.
Can ASR rules coexist with third-party antivirus?
Partial behavior at best; the Defender engine may sit passive. The reliable pattern is Defender as the sole AV engine.
What is the fastest way to find ASR false positives?
The ASR report plus an Advanced Hunting query over audit events, grouped by rule and initiating process — then tune with per-rule exclusions.
Is P1 enough?
Plan 1 covers core EDR and AV management; P2 adds threat and vulnerability management and advanced hunting depth. Choose by roadmap, not just budget.
Conclusion
MDE through Intune is less about installing anything and more about sequencing policy correctly: onboarding state through the EDR policy, engine posture through the antivirus profile, and ASR rules that earn their enforcement through audit evidence. Run that sequence, keep one owner per setting, and the Defender portal becomes what it should be — a reliable source of signal, not another dashboard of mystery gaps.
Comments
0No comments yet — be the first to share your thoughts.