Defender for Endpoint and the Endpoint Security baseline

Microsoft Defender for Endpoint (MDE) is the EDR (Endpoint Detection and Response) platform behind this chapter's monitoring controls: attack detection (3.14.6), unauthorized-use detection (3.14.7), continuous monitoring (3.12.3). The Endpoint Security baseline is the set of Layer 1 OIB policies that share Intune's Endpoint security blade with MDE (BitLocker, Windows Hello for Business, LAPS and local-admin posture, firewall, exploit and removable-media control). MDE can enforce a subset of them; GPO delivers the rest. Because MDE also reaches non-Intune-enrolled machines, those policies arrive over different channels by device type: the delivery matrix below maps delivery across Intune-managed workstations, MDE-managed workstations, and MDE-managed servers.

GCC High
Commercial

CMMC Relevance

CMMC Practice	NIST 800-171 Rev. 2 Control	How MDE Satisfies It
SI.L2-3.14.6	Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks	MDE endpoint sensors continuously monitor process, file, and network telemetry, detecting attacks and indicators of compromise across the fleet
SI.L2-3.14.7	Identify unauthorized use of organizational systems	MDE behavioral analytics and anomaly detection surface unexpected process execution, lateral movement, and data exfiltration patterns
CA.L2-3.12.3	Monitor security controls on an ongoing basis	MDE Secure Score, device health reports, and alert pipeline provide continuous monitoring evidence
IR.L2-3.6.1	Establish an operational incident-handling capability	MDE Incidents, automated investigation, and the Microsoft Defender portal provide the response workflow
IR.L2-3.6.2	Track, document, and report incidents	MDE incident timeline and audit log satisfy documentation requirements; exportable for assessors
CM.L2-3.4.6	Employ the principle of least functionality	Attack Surface Reduction (ASR) rules block execution of unnecessary system features and built-in living-off-the-land binaries
SI.L2-3.14.4	Update malicious code protection mechanisms	MDE platform and signature updates are managed by Microsoft; no separate update infrastructure required

NIST SP 800-171 Rev. 3 Relevance

NIST SP 800-171 Rev. 3 Requirement	How MDE Satisfies It
3.14.6 (System monitoring)	MDE endpoint sensors continuously monitor process, file, and network telemetry, detecting attacks, indicators of compromise, and unauthorized use across the fleet
3.12.3 (Continuous monitoring)	MDE Secure Score, device health reports, and alert pipeline provide continuous monitoring evidence
3.6.1 (Incident handling)	MDE Incidents, automated investigation, and the Microsoft Defender portal provide the response workflow
3.6.2 (Incident reporting)	MDE incident timeline and audit log satisfy documentation requirements; exportable for security program reviews
3.4.6 (Least functionality)	Attack Surface Reduction (ASR) rules block execution of unnecessary system features and built-in living-off-the-land binaries
3.14.2 (Malicious code protection)	Microsoft Defender Antivirus protection mechanisms plus Microsoft-managed platform and signature updates

License Note

GCC High: M365 E3 GCC High and M365 E5 GCC High both include MDE Plan 2; no separate license is required. Commercial: M365 E3 includes MDE Plan 1; M365 E5 includes MDE Plan 2, which adds full EDR, automated investigation and response (AIR), and threat and vulnerability management. For the full EDR capabilities described in this chapter, Plan 2 (E5 or a standalone MDE add-on) is required. Verify your license by checking Microsoft Defender > Settings > Endpoints > Licenses.

License Note

M365 E3 includes MDE Plan 1; M365 E5 includes MDE Plan 2, which adds full EDR, automated investigation and response (AIR), and threat and vulnerability management. For the full EDR capabilities described in this chapter, Plan 2 (E5 or a standalone MDE add-on) is required. Verify your license by checking Microsoft Defender > Settings > Endpoints > Licenses.

Management Models: Intune, MDE, and Defender for Cloud

Not every device that needs endpoint protection is enrolled in Intune. Workstations belonging to users without an Intune license, and servers (which aren't an Intune MDM enrollment target at all), are common cases. Three management models coexist in a typical tenant, and a given device falls into exactly one:

Intune-managed workstation: full MDM enrollment, Entra-joined. The complete Intune channel: Endpoint Security, Configuration, Compliance, Apps, and Platform Scripts.
MDE-managed workstation: Defender for Endpoint Security Settings Management delivers Endpoint Security policy to a device onboarded to MDE but not enrolled in Intune (Microsoft).
Defender for Cloud-managed server: Windows Server isn't an Intune MDM target, so servers onboard through Defender for Servers (Defender for Cloud): Azure VMs auto-provision the sensor, non-Azure servers connect via Azure Arc.

The capabilities and boundaries that separate them:

Dimension	Intune-managed workstation	MDE-managed workstation	Defender for Cloud server
Typical license	M365 E3 / E5 GCC High (Intune + MDE P2)	MDE P2 (standalone, per-user)	Defender for Servers P1 / P2 (per-server)
Enrollment / identity	Intune MDM, Entra-joined	MDE security settings management; synthetic Entra registration; `Managed by: MDE`	Azure VM or Azure Arc-enabled server (an Azure resource); gains the same synthetic Entra registration once the MDE channel manages it
Onboarding	Intune EDR policy	Local script / GPO / ConfigMgr	Defender for Cloud auto-provision (Arc for non-Azure)
Policy targeting	User or device groups	Device groups only: user-group assignments silently no-op	Azure scope (subscription / RG / Arc)
Security config (AV, ASR Rules, EDR, Firewall)	Intune channel ✓	MDE channel ✓ (this subset only)	MDE channel ✓ (settings management)
Other endpoint config (BitLocker, LAPS, Device Control, Exploit Protection, WHfB, audit)	Intune channel ✓	GPO	GPO (+ Azure Policy for OS baseline)
Compliance policy → compliant-device CA	✓	✗ (no MDM)	✗ (no MDM; Windows Server is not an Intune target)
MDE device-risk CA gate	✓ (via a compliance policy)	✗	✗
App deployment / platform scripts	✓	✗	✗ (use Azure / ConfigMgr)
Ongoing assurance surface	Intune compliance + device configuration report	MDE per-setting status + MDVM baselines (add-on) + Tamper Protection + GPO refresh	Defender for Cloud OS-config (MCSB) + regulatory dashboard + FIM + Secure Score
Enforce / auto-remediate lever	CA gate + Intune	Self-heal only (no access gate)	Machine Config `ApplyAndAutoCorrect` (in-guest self-heal)

The MDE-managed model in particular is narrower than Intune: Endpoint Security policy only, device-group targeting only (user-group assignments silently no-op), and an identity surface that appears in Intune as Managed by: MDE with a synthetic Entra registration MDE creates automatically (Join Type blank).

The third model (Defender for Cloud servers) shares the MDE security-settings channel for its AV/ASR/EDR/Firewall policy (it depends on the same tenant having at least one MDE user license active), but adds a Defender-for-Cloud assessment and enforcement surface that the workstation models don't have. Because both non-Intune models ride that same channel, Managed by: MDE in the Intune and Defender inventories does not distinguish them; the OS does (Windows client = MDE-managed workstation, Windows Server = Defender for Cloud server). Configuration Assurance for Non-Intune Devices below covers how each model is kept and proven in compliance over time.

Managed by: MDE proves the channel, not a healthy Entra registration

MDE-channel policy reaches a device through its Entra device object: policies are assigned to Entra device groups, and devices "get their assigned policies based on their Microsoft Entra ID device object" (Microsoft). Two degraded states keep showing Managed by: MDE in the Intune and Defender inventories while delivering no policy, and they need different fixes:

Registration never completed. An SCP or Entra Connect misconfiguration blocks the hybrid (or synthetic) registration. On the device, dsregcmd /status shows the pre-join Diagnostic Data tests, and HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus holds the MDE enrollment error code (36/37 = Entra Connect misconfiguration, 38/41 = DNS, 18 = certificate from another tenant) (Microsoft).
Registration completed, then the Entra object was deleted. Moving a computer object out of a synced OU causes Entra Connect to delete the Entra device (Microsoft), and stale-device cleanup does the same to long-offline machines. The device keeps its local join state: dsregcmd /status shows AzureAdJoined: YES but DeviceAuthStatus: FAILED. Device is either disabled or deleted, and sign-ins fail with AADSTS50155 (Microsoft). Deleted device objects cannot be restored. Fix the sync scope first, then re-register: elevated dsregcmd.exe /debug /leave, sign out, and sign back in (Microsoft).

In either state, only the GPO-delivered half and sensor-based assessment still operate. Treat the device as unmanaged for evidence purposes until the registration is repaired.

Target MDE-attached devices with device groups, not user groups

Because user-group assignments silently no-op on MDE-attached devices, build the targeting around device security groups from the start, so a single OIB Endpoint Security policy reaches every workstation in the tenant regardless of management mode.

Licensing: per-user for client OS, per-server for server OS

Client OS (Windows 10/11, macOS): MDE P2 is a per-user license (standalone or part of an E5 Security add-on). Assign it to a user account in the Microsoft 365 Admin Center; when that user signs into an onboarded device, the device consumes one of the user's concurrent device slots (typically up to 5 per user). For kiosks, shared workstations, and lab machines, confirm the applicable user or device entitlement with the licensing provider. Assigning a license to a service account does not establish coverage for every person using a shared device.

User-tier MDE P2 licenses do not cover servers

Defender for Endpoint P2 user licenses (the per-user SKUs included with E5 or sold as an add-on) cover MDE on the user's client devices only: Windows 10/11, macOS, mobile. They explicitly do not extend to Windows Server. Server protection requires a separate procurement no matter what other Defender SKUs the tenant already has. The server-licensing options below are independent of the client-tier user licensing.

Server OS (Windows Server, Linux): three legitimate licensing paths exist. The right choice depends on customer segment, scale, and whether infrastructure-security features beyond EDR are needed:

Option (cheapest → most expensive)	What it is	Eligibility	Cost (approx.)	What it provides	Microsoft licensing reference
MDE for Server (standalone)	Per-server SKU sold via Volume Licensing / EA / CSP	Any tenant; no other licensing prerequisite; no Azure Arc requirement	≈$3/server/mo equivalent annual	MDE EDR + AV only; no Defender for Cloud surface	Microsoft Defender service description — Microsoft Defender for Endpoint for Servers; GCC High SKU: Microsoft Defender for Endpoint Server for GCC High
Defender for Servers Plan 1 (Defender for Cloud)	Azure Defender for Cloud workload-protection plan, P1 tier	Any tenant with an Azure subscription; Azure Arc is recommended for non-Azure servers; direct MDE onboarding supports a subset of capabilities	≈$5/server/mo, hourly billed	MDE EDR + AV; Defender for Cloud server inventory and alerts	Defender for Servers overview; Pricing: Defender for Cloud; GCC High plan name: Microsoft Defender for servers - Government
Defender for Servers Plan 2 (Defender for Cloud)	Same as Plan 1 plus infrastructure-security features	Same as Plan 1	≈$15/server/mo, hourly billed	All P1 features plus premium vulnerability-management capabilities, agentless scanning, and File Integrity Monitoring; verify cloud availability	Plan selection: Defender for Servers; Pricing: Defender for Cloud
Defender for Business Servers (SMB commercial special case)	SMB-tier add-on for Defender for Business or Microsoft 365 Business Premium	M365 Business Premium / Defender for Business customers only (≤300 employees); commercial only (not available in GCC High); max 60 servers per tenant	≈$3/server/mo annual	MDE EDR + AV; native to the Defender for Business management surface	How to get Defender for Business Servers; Defender for Business FAQ — does Defender for Business support servers?

GCC High customers see Defender for Business Servers grayed out: that SKU is commercial-only. The choice in GCC High is between the standalone MDE for Server SKU and Defender for Servers P1/P2 in Defender for Cloud. See Microsoft Defender for Endpoint for US Government customers for the full GCC / GCC High / DoD server-licensing matrix.

Option (cheapest → most expensive)	What it is	Eligibility	Cost (approx.)	What it provides	Microsoft licensing reference
MDE for Server (standalone)	Per-server SKU sold via Volume Licensing / EA / CSP	Any tenant; no other licensing prerequisite; no Azure Arc requirement	≈$3/server/mo equivalent annual	MDE EDR + AV only; no Defender for Cloud surface	Microsoft Defender service description — Microsoft Defender for Endpoint for Servers
Defender for Servers Plan 1 (Defender for Cloud)	Azure Defender for Cloud workload-protection plan, P1 tier	Any tenant with an Azure subscription; Azure Arc is recommended for non-Azure servers; direct MDE onboarding supports a subset of capabilities	≈$5/server/mo, hourly billed	MDE EDR + AV; Defender for Cloud server inventory and alerts	Defender for Servers overview; Pricing: Defender for Cloud
Defender for Servers Plan 2 (Defender for Cloud)	Same as Plan 1 plus infrastructure-security features	Same as Plan 1	≈$15/server/mo, hourly billed	All P1 features plus premium vulnerability-management capabilities, agentless scanning, and File Integrity Monitoring; verify cloud availability	Plan selection: Defender for Servers; Pricing: Defender for Cloud
Defender for Business Servers (SMB special case)	SMB-tier add-on for Defender for Business or Microsoft 365 Business Premium	M365 Business Premium / Defender for Business customers only (≤300 employees); max 60 servers per tenant	≈$3/server/mo annual	MDE EDR + AV; native to the Defender for Business management surface	How to get Defender for Business Servers; Defender for Business FAQ — does Defender for Business support servers?

Recommendation matrix

Customer profile	Recommended	Why
Enterprise, EDR-only need, mature third-party vulnerability scanner already deployed (Tenable, Qualys, Rapid7), no Sentinel adoption planned	MDE for Server standalone	≈40% cheaper than P1; no Azure Arc requirement; same EDR feature set; no second Defender-for-Cloud operational surface to manage
GCC High / CMMC-pursuing, Enterprise (E3/E5), 30–100 servers, no Microsoft-equivalent vulnerability scanner currently in the SSP, no Sentinel adoption planned	Defender for Servers Plan 1, with door open to upgrade to P2 if the SSP gap analysis identifies vulnerability assessment as needing a Microsoft solution	Provides the EDR coverage; the Defender for Cloud regulatory-compliance dashboard is useful continuous-monitoring evidence at C3PAO assessment time; ≈$2/server/mo more than standalone for that surface; hourly billing favors mixed always-on / scheduled-off workloads
Enterprise needing infrastructure-security features (premium vulnerability management, agentless scanning, and FIM) with no Microsoft-equivalent already in place	Defender for Servers Plan 2	Adds these capabilities beyond P1; ≈3× the cost of P1, justified by specific feature mapping to CMMC controls (RA.L2-3.11.2 vulnerability scans, SI.L2-3.14.1 system flaw identification + audit log integrity)
GCC High / CMMC tenant with sufficient eligible paid ingestion to offset the P2 premium	Defender for Servers Plan 2	The 500 MB/day server allowance can offset the P2 premium when actual eligible ingestion and the workspace billing model produce sufficient savings; it does not cover all MDE telemetry. See SIEM Strategy § Why P2 is the right server-licensing choice when Sentinel is in scope for the dollar math at 50 servers.
SMB on Microsoft 365 Business Premium, ≤60 servers, commercial tenant	Defender for Business Servers	Cheapest of all options; native to the Defender for Business surface the tenant already uses; not available in GCC High

At 50 servers, this is what each upgrade buys you:

MDE for Server standalone (≈$1,800/year): MDE EDR + AV protection on every onboarded server. Same EDR feature set as Plan 1. Onboard via local script, GPO, or MECM; no Azure Arc, no Defender for Cloud, no additional operational surface. Sold annually via Volume Licensing / EA / CSP. The right floor for any server fleet that just needs endpoint detection and response.
Defender for Servers Plan 1 (≈$3,000/year, adds ≈$1,200/year over standalone): everything in standalone, plus the Defender for Cloud server inventory and alert pane (a useful continuous-monitoring artifact for CMMC C3PAO assessments) and hourly billing (scheduled-off servers don't accrue cost during downtime). The ≈$1,200/year delta buys the Defender for Cloud surface and the option to upgrade in place to Plan 2 without re-onboarding.
Defender for Servers Plan 2 (≈$9,000/year, adds ≈$6,000/year over Plan 1): everything in Plan 1, plus premium vulnerability-management capabilities, agentless scanning, and File Integrity Monitoring. Core vulnerability management is also included with P1. The ≈$6,000/year delta looks like the meaningful financial decision, and is, unless Sentinel is on the roadmap. P2 includes a 500 MB/server/day Sentinel data ingestion benefit (up to $4,035/month in the illustrative 50-server unified-meter calculation, if fully used by eligible data) that P1 and standalone do not. Walk through the dollar math at SIEM Strategy § Why P2 is the right server-licensing choice when Sentinel is in scope before committing to P1 or standalone.

Customer profile	Recommended	Why
Enterprise, EDR-only need, mature third-party vulnerability scanner already deployed (Tenable, Qualys, Rapid7), no Sentinel adoption planned	MDE for Server standalone	≈40% cheaper than P1; no Azure Arc requirement; same EDR feature set; no second Defender-for-Cloud operational surface to manage
Enterprise (E3/E5), 30–100 servers, no Microsoft-equivalent vulnerability scanner currently documented, no Sentinel adoption planned	Defender for Servers Plan 1, with door open to upgrade to P2 if a gap analysis identifies vulnerability assessment as needing a Microsoft solution	Provides the EDR coverage; the Defender for Cloud regulatory-compliance dashboard is useful continuous-monitoring evidence; ≈$2/server/mo more than standalone for that surface; hourly billing favors mixed always-on / scheduled-off workloads
Enterprise needing infrastructure-security features (premium vulnerability management, agentless scanning, and FIM) with no Microsoft-equivalent already in place	Defender for Servers Plan 2	Adds these capabilities beyond P1; ≈3× the cost of P1, justified by the added vulnerability-management, file-integrity-monitoring, and regulatory-dashboard capabilities
Tenant with sufficient eligible paid ingestion to offset the P2 premium	Defender for Servers Plan 2	The 500 MB/day server allowance can offset the P2 premium when actual eligible ingestion and the workspace billing model produce sufficient savings; it does not cover all MDE telemetry. See SIEM Strategy § Why P2 is the right server-licensing choice when Sentinel is in scope for the dollar math at 50 servers.
SMB on Microsoft 365 Business Premium, ≤60 servers	Defender for Business Servers	Cheapest of all options; native to the Defender for Business surface the tenant already uses

At 50 servers, this is what each upgrade buys you:

MDE for Server standalone (≈$1,800/year): MDE EDR + AV protection on every onboarded server. Same EDR feature set as Plan 1. Onboard via local script, GPO, or MECM; no Azure Arc, no Defender for Cloud, no additional operational surface. Sold annually via Volume Licensing / EA / CSP. The right floor for any server fleet that just needs endpoint detection and response.
Defender for Servers Plan 1 (≈$3,000/year, adds ≈$1,200/year over standalone): everything in standalone, plus the Defender for Cloud server inventory and alert pane (a useful continuous-monitoring artifact) and hourly billing (scheduled-off servers don't accrue cost during downtime). The ≈$1,200/year delta buys the Defender for Cloud surface and the option to upgrade in place to Plan 2 without re-onboarding.
Defender for Servers Plan 2 (≈$9,000/year, adds ≈$6,000/year over Plan 1): everything in Plan 1, plus premium vulnerability-management capabilities, agentless scanning, and File Integrity Monitoring. Core vulnerability management is also included with P1. The ≈$6,000/year delta looks like the meaningful financial decision, and is, unless Sentinel is on the roadmap. P2 includes a 500 MB/server/day Sentinel data ingestion benefit (up to $4,035/month in the illustrative 50-server unified-meter calculation, if fully used by eligible data) that P1 and standalone do not. Walk through the dollar math at SIEM Strategy § Why P2 is the right server-licensing choice when Sentinel is in scope before committing to P1 or standalone.

Policy architecture

One Endpoint Security policy set covers all workstations: the settings are identical for Intune-managed and MDE-managed alike. What differs is the delivery channel, and the channel dictates where each policy is assigned. The MDE security-settings-management channel enforces only a subset of endpoint security profile types (callout below). Assigning an Intune-only profile to an MDE-managed device isn't an error: it just never enforces. So split targeting by channel, delivering whatever the MDE channel can't enforce by GPO (GPO fallback for MDE-only fleets), or, for MDE-managed workstations, by full Intune enrollment. The three target groups, mapped to the matrix columns below:

Device group	Membership
`Workstations-Intune`	Intune MDM-enrolled workstations
`Workstations-MDE`	MDE-attached (non-Intune) workstations: define as a dynamic group on `managementType -eq "MicrosoftSense"` (Microsoft guidance)
`Servers-MDE`	MDE-attached servers (Windows Server isn't a supported Intune MDM enrollment target)

MDE-channel delivery is a strict subset of Intune endpoint security

Per the Windows table in Microsoft's Defender for Endpoint security settings management § Which solution should I use?, the MDE security-settings-management channel enforces only these profile types:

Antivirus: Microsoft Defender Antivirus, AV exclusions, Windows Security Experience (Tamper Protection), Defender Update controls
Attack Surface Reduction → ASR Rules (this profile only, not Exploit Protection, not Device Control)
Endpoint detection and response
Firewall and Firewall Rules

Everything else is Intune-channel only. Note that Attack Surface Reduction splits here: ASR Rules flows over the channel, but Exploit Protection and Device Control do not. The delivery matrix below gives the per-policy mapping.

Assignment filters are also ignored on MDE-channel devices. "Assignment filters aren't supported for devices communicating through the Microsoft Defender for Endpoint channel." Scope with Microsoft Entra device groups, not filters.

Policy delivery across management contexts

Each policy appears once, with how it's delivered in each of the three management contexts. The # is the canonical 1–21 ID from Open Intune Baseline Deployment. Compliance policies (18–21) require Intune MDM enrollment to evaluate, so they don't apply to MDE-managed devices at all.

Legend: MDE = enforced over the MDE security-settings channel · GPO = delivered by Group Policy · ✓ = applied via Intune MDM · — = not applicable.

#	Policy	Intune-managed `Workstations-Intune`	MDE workstation `Workstations-MDE`	MDE server `Servers-MDE`
1	`Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7`	✓	MDE	MDE
2	`Win - OIB - ES - Defender Antivirus - D - AV Configuration - v3.3`	✓	MDE	MDE (fork `Svr`)
3	`Win - OIB - ES - Defender Antivirus - D - Security Experience - v3.3`	✓	MDE	MDE
4	`Win - OIB - ES - Encryption - D - BitLocker (OS Disk) - v3.7`	✓	GPO	GPO
5	`Win - OIB - ES - Windows Firewall - D - Firewall Configuration - v3.1`	✓	MDE	MDE (fork `Svr`)
6	`Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2`	✓	GPO	n/a (workstations only)
7	`Win - OIB - SC - Device Security - D - Audit and Event Logging - v3.7`	✓	GPO	GPO
8	`Win - OIB - SC - Device Security - D - Login and Lock Screen - v3.8`	✓	GPO	GPO
9	`Win - OIB - SC - Device Security - U - Power and Device Lock - v3.6`	✓	GPO	n/a (user-scoped)
10	`Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust - v3.5`	✓	GPO	n/a (workstations only)
11	`Win - OIB - SC - Windows Update for Business - D - Reports and Telemetry - v3.0`	✓	GPO	GPO
12	`Win - OIB - ES - Windows LAPS - D - LAPS Configuration - v3.1`	✓	GPO	GPO
13	`Win - OIB - ES - Local Group Membership - D - Local Administrators - v3.7`	✓	GPO	GPO
14	`Win - OIB - SC - Device Security - D - Local Security Policies - v3.0`	✓	GPO	GPO
15	`Win - Custom - ES - Defender for Endpoint Onboarding`	✓	MDE	MDE / Defender for Cloud
16	`Win - Custom - ES - Device Control / Removable Media`	✓	GPO	GPO
17	`Win - Custom - ES - Exploit Protection`	✓	GPO	GPO
18	`Win - OIB - Compliance - U - Defender for Endpoint - v3.1`	✓	—	—
19	`Win - OIB - Compliance - U - Device Health - v3.1`	✓	—	—
20	`Win - OIB - Compliance - U - Device Security - v3.1`	✓	—	—
21	`Win - OIB - Compliance - U - Password - v3.1`	✓	—	—

Policies 15–17 are authored once per tenant (not in the OIB Settings Catalog import): see Appendix B: Defender for Endpoint, Removable Media, Exploit Protection. EDR onboarding (#15) is also documented at Step 2: Create an Endpoint Detection & Response Policy below.

Defender AV Update Rings are Layer 2, not Layer 1

The OIB project ships three additional ES policies (Win - OIB - ES - Defender Antivirus Updates - Ring 1 - Pilot - v3.4, Ring 2 - UAT - v3.4, and Ring 3 - Production - v3.4) for staged rollout of Defender signature updates. These are not part of Layer 1. CMMC 3.14.4 (update malicious code protection mechanisms) is satisfied by Defender's default automatic signature update behavior, which works out of the box without any policy. The three ring policies provide operational risk management (catch a bad signature on pilot machines before fleet-wide rollout), valuable for a mature operation, but not compliance-mandatory and not required for an MDE deployment to function. They live in Layer 2 (defense-in-depth) and can be added in a follow-on engagement after the Layer 1 baseline operates cleanly.

Defender AV Update Rings are Layer 2, not Layer 1

The OIB project ships three additional ES policies (Win - OIB - ES - Defender Antivirus Updates - Ring 1 - Pilot - v3.4, Ring 2 - UAT - v3.4, and Ring 3 - Production - v3.4) for staged rollout of Defender signature updates. These are not part of Layer 1. Malicious-code-protection currency is satisfied by Defender's default automatic signature update behavior, which works out of the box without any policy. The three ring policies provide operational risk management (catch a bad signature on pilot machines before fleet-wide rollout), valuable for a mature operation, but not required for an MDE deployment to function. They live in Layer 2 (defense-in-depth) and can be added in a follow-on engagement after the Layer 1 baseline operates cleanly.

Server Endpoint Security set

Servers are MDE-channel only (Windows Server isn't an Intune MDM target), so the MDE server column above is delivered entirely over the MDE channel or by GPO, never by Intune MDM. Two MDE-supported policies are forked to server-tuned Svr - variants; the rest carry the server-specific caveats below.

Forks: author a Svr - variant, then tune:

Forks	Server policy (new)	Server-specific tuning
2	`Svr - OIB - ES - Defender Antivirus - D - AV Configuration`	Schedule scans during low-load windows. Add Microsoft-documented exclusions for the server roles in scope: SQL data files, IIS application paths, Exchange databases, AD DS NTDS/SYSVOL paths. The exclusion list is the load-bearing reason for the fork: applying the workstation AV policy to a server with no exclusions risks AV scanning live database files and locking them mid-write.
5	`Svr - OIB - ES - Firewall - D - Firewall Rules`	Servers accept inbound traffic on service ports (SQL 1433, IIS 80/443, AD DS ports, etc.); workstation firewall blocks all inbound. Author server firewall rules from Microsoft's role-specific server firewall guidance, not from the workstation baseline.

Server caveats: the matrix gives the channel; these are the per-policy gotchas:

ASR Rules (1) / Security Experience (3): server-safe as-is. Office-trigger ASR rules no-op without Office; credential-theft and persistence rules still apply. On headless Server Core, Tamper Protection is the load-bearing Security Experience setting.
BitLocker (4): physical servers only; Azure VMs are platform-encrypted, so a duplicate policy is redundant. Use a TPM-only protector (no startup PIN, so unattended reboots work) plus Fixed Data Drive encryption for CUI volumes.
Windows LAPS (12): manages the built-in Administrator on the AD computer object. Exclude domain controllers, as they manage their own admin accounts via AD.

Local Administrators (13): GPO Restricted Groups; membership is Tier 1 server admins plus service accounts that legitimately need local admin (CMMC 3.1.5), not a primary user.

Local Administrators (13): GPO Restricted Groups; membership is Tier 1 server admins plus service accounts that legitimately need local admin (least privilege), not a primary user.

Device Control (16): branch-office, retail, and industrial-floor servers; skip datacenter racks (no physical access).
Exploit Protection (17): GPO or Set-ProcessMitigation; server-safe on modern Microsoft roles, but watch for a legacy line-of-business binary that breaks under mandatory ASLR.

Beyond the two forks above, create a Svr - variant only for a concrete tuning need: an audit-only ASR rollout for change-management caution, an allow-list for a conflicting server workload, or a rare server-specific Tamper Protection posture. Forks are mechanical: copy the workstation policy, retarget, change the differing settings.

GPO fallback for MDE-only fleets

The Intune endpoint security profiles that don't flow over the MDE channel (LAPS, Local Group Membership, Exploit Protection, Device Control, BitLocker (disk encryption), and Windows Hello for Business (workstations)) still need to be applied on MDE-managed workstations and servers to keep your CMMC controls satisfied. The right path differs by device type:

The Intune endpoint security profiles that don't flow over the MDE channel (LAPS, Local Group Membership, Exploit Protection, Device Control, BitLocker (disk encryption), and Windows Hello for Business (workstations)) still need to be applied on MDE-managed workstations and servers to keep your endpoint security controls satisfied. The right path differs by device type:

MDE-managed workstations: two real options:

Full Intune MDM enrollment (Hybrid Azure AD Join + Intune MDM). Workstations are a supported Intune enrollment target, so full enrollment unlocks them all via the Intune channel, the right answer when workstations are user-owned and ready for MDM. See Enrollment guide: Enroll Windows client devices in Microsoft Intune.
GPO / native Windows mechanisms on domain-joined workstations that won't move to Intune (table below).

MDE-managed servers: GPO is essentially the only path for these profiles. Windows Server is not a supported Intune MDM enrollment target, and Microsoft's Intune Windows enrollment guide explicitly notes that Configuration Manager supports Windows Server, i.e., Intune itself does not. Two adjacent server-side channels exist for the broader Defender stack, but neither closes these specific gaps: MDE security settings management (the channel we're already working around: AV, ASR Rules, EDR, Firewall) and Configuration Manager tenant attach (extends Antivirus, the Windows Security experience (Tamper Protection), ASR Rules, Exploit Protection, EDR, and Firewall to ConfigMgr-managed servers per the supported-profiles table, but not LAPS, Local Group Membership, or Device Control; in GCC High it requires Configuration Manager current branch 2107+, the version that added Azure US Government support. Some still-current Microsoft setup pages predate this and say Azure Government isn't supported). Azure Arc adds a different management plane (Update Manager, Machine Configuration via Azure Policy) but is not an Intune-equivalent for the endpoint security profiles in question.

The documented GPO / native alternatives, applied via Active Directory GPOs (the same mechanism that delivers these on domain-joined workstations that don't move to Intune):

Unsupported Intune profile	CMMC control	GPO / native alternative
Windows LAPS	AC.L2-3.1.5	Native Windows LAPS (built into Windows Server 2019/2022/2025 and Windows 10 22H2+/11) via GPO targeting the AD computer object. See Windows LAPS overview.
Local Group Membership	AC.L2-3.1.5 (Least Privilege)	GPO Restricted Groups under `Computer Configuration > Windows Settings > Security Settings > Restricted Groups`.
Exploit Protection	SI.L2-3.14.1 (flaw remediation)	GPO under Microsoft Defender Exploit Guard → Exploit Protection ("Use a common set of exploit protection settings" pointing at an XML export), or PowerShell `Set-ProcessMitigation` importing the same XML. See Enable exploit protection.
Device Control / Removable Media	MP.L2-3.8.1; MP.L2-3.8.7	GPO via the Defender Device Control ADMX (Defender > Device Control settings), or move the affected devices to full Intune enrollment so the Intune Device Control profile applies.
BitLocker (disk encryption)	SC.L2-3.13.16 (CUI at rest)	GPO under `Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption`. See BitLocker policy settings. Physical servers/workstations only; Azure VMs are platform-encrypted.
Windows Hello for Business (workstations)	IA.L2-3.5.3 (MFA)	GPO under `Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business` (Passport ADMX): Use Windows Hello for Business + Use cloud Kerberos trust for on-premises authentication (+ Use a hardware security device). Requires the Microsoft Entra Kerberos object in your hybrid environment. See Cloud Kerberos trust deployment. Where both GPO and Intune configure WHfB, GPO wins.

Whichever path you pick for each fleet, document the CMMC mapping in your SSP so the auditor sees the control satisfied by the alternative mechanism, not silently dropped.

Unsupported Intune profile	Control area	GPO / native alternative
Windows LAPS	Least privilege	Native Windows LAPS (built into Windows Server 2019/2022/2025 and Windows 10 22H2+/11) via GPO targeting the AD computer object. See Windows LAPS overview.
Local Group Membership	Least privilege	GPO Restricted Groups under `Computer Configuration > Windows Settings > Security Settings > Restricted Groups`.
Exploit Protection	Flaw remediation	GPO under Microsoft Defender Exploit Guard → Exploit Protection ("Use a common set of exploit protection settings" pointing at an XML export), or PowerShell `Set-ProcessMitigation` importing the same XML. See Enable exploit protection.
Device Control / Removable Media	Media protection	GPO via the Defender Device Control ADMX (Defender > Device Control settings), or move the affected devices to full Intune enrollment so the Intune Device Control profile applies.
BitLocker (disk encryption)	Data at rest	GPO under `Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption`. See BitLocker policy settings. Physical servers/workstations only; Azure VMs are platform-encrypted.
Windows Hello for Business (workstations)	Multi-factor authentication	GPO under `Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business` (Passport ADMX): Use Windows Hello for Business + Use cloud Kerberos trust for on-premises authentication (+ Use a hardware security device). Requires the Microsoft Entra Kerberos object in your hybrid environment. See Cloud Kerberos trust deployment. Where both GPO and Intune configure WHfB, GPO wins.

Whichever path you pick for each fleet, document the control mapping in your security plan so an auditor sees the control satisfied by the alternative mechanism, not silently dropped.

Configuration Assurance for Non-Intune Devices

An Intune-managed device closes the loop with a compliance policy that feeds compliant-device Conditional Access: the device both re-applies its configuration and is denied access if it falls out of compliance. MDE-managed workstations and Defender-for-Cloud servers get neither a compliance policy nor that CA gate, so their assurance model shifts from a preventive gate to detective monitoring plus self-healing re-assertion. Settings don't silently rot; you prove they're applied through reporting and assessment rather than gating access on them. The loop below also assumes the device's Entra registration is healthy: in the two degraded registration states described under Management Models, a device still reads Managed by: MDE yet receives no policy at all.

Non-Intune devices cannot be access-gated on configuration state

Compliant-device Conditional Access requires an Intune compliance policy, which only MDM-enrolled devices can evaluate. The MDE device-risk signal is no escape hatch: it is also consumed through a compliance policy (Microsoft), so it too is unavailable for MDE-only and Defender-for-Cloud devices. What remains is an identity gate: a hybrid-joined MDE-managed workstation can still be gated with the grant control Require Microsoft Entra hybrid joined device, which proves it is a known corporate device but says nothing about its configuration health (Microsoft). Treat their configuration as continuously monitored and self-healing, not as an access-control gate, and document that boundary in the SSP.

MDE-managed workstations

The full keep-and-verify loop comes with MDE P2; only a named-benchmark compliance report costs extra (broken out below).

Included with MDE P2: no additional purchase

Keep it applied (self-heal). The MDE security-settings channel is a managed channel: devices check in every 90 minutes to update policy (Microsoft), re-evaluating and re-applying the AV / ASR Rules / EDR / Firewall policy. A local change drifts back to policy within that window (or in ≈10 minutes if you force a Policy sync from the Defender portal's device page). Tamper Protection prevents a local admin or malware from disabling Defender's protections in the interim. The GPO-delivered half (BitLocker, LAPS, Device Control, etc.) is re-applied by the Group Policy refresh cycle (≈90 minutes + at reboot), so both halves self-heal on roughly the same cadence.
Prove it applied (per-setting status). Each MDE-channel policy reports per-device, per-setting Success / Error / Conflict: in Intune at Endpoint security → [policy] → View report → per-setting status, and in the Defender portal at Endpoints → Configuration management → Endpoint security policies → Policy settings status (Microsoft).
Detect misconfiguration (Configuration assessment → Secure Score for Devices). MDE P2 includes the core Defender Vulnerability Management capabilities: configuration assessment, security recommendations, and Microsoft Secure Score for Devices (capability comparison). These continuously evaluate each device's security-configuration state (antivirus, ASR, firewall, Tamper Protection, and OS / account / network controls) and surface drift as ranked, per-device recommendations with exposed-device counts and remediation tracking (Secure Score for Devices). This is genuine configuration-drift detection against Microsoft's recommended secure posture, with no add-on required. One boundary: devices inactive for more than 30 days drop out of the exposure-score and secure-score data (Microsoft), so a spun-down machine's posture evidence goes stale with it.

The one capability the core tier does not provide is compliance measured against a named external benchmark (CIS / STIG): that is where the add-on comes in.

Optional upgrade: Defender Vulnerability Management add-on (benchmark compliance)

The Defender Vulnerability Management (MDVM) add-on to MDE P2 adds Security Baselines Assessment: you build a profile from a named industry benchmark (CIS or STIG) and get continuous per-configuration and per-device pass/fail against that benchmark, with exceptions and top-failing-device views (Microsoft). It reads the device's effective configuration, which suits the GPO-delivered settings the MDE channel can't enforce.

What you're actually buying is the benchmark frame, not config monitoring. Core already does that. The value is the auditor-grade artifact: compliance measured against CIS Level 1 / STIG, not just "Microsoft's recommended posture." The same SKU also bundles vulnerability-focused premium tools (block vulnerable apps; browser-extension, digital-certificate, network-share, and hardware/firmware assessment) that aren't config-assurance (capability comparison).

	Detail
What it adds (for assurance)	Security Baselines Assessment: CIS / STIG benchmark profiles, per-config and per-device pass/fail, exceptions, top-failing devices
Licensing	Per-user add-on to MDE P2; license every user whose client devices you assess
Cost	≈ $2 per user / month (commercial list price; not published on Microsoft Learn; confirm current figure with your reseller. GCC High is priced separately.)
GCC High caveat	The MDVM self-service trial is not available in GCC High or DoD (Microsoft). Acquire the add-on through your CSP / reseller.
Servers	Not needed for servers. Defender for Servers Plan 2 already includes premium MDVM (Security Baselines Assessment included). This is a client-device decision only.

The decision: stay on core unless your control owner or C3PAO specifically needs measured CIS/STIG benchmark compliance as the evidence artifact for the MDE-managed client fleet.

	Detail
What it adds (for assurance)	Security Baselines Assessment: CIS / STIG benchmark profiles, per-config and per-device pass/fail, exceptions, top-failing devices
Licensing	Per-user add-on to MDE P2; license every user whose client devices you assess
Cost	≈ $2 per user / month (list price; not published on Microsoft Learn; confirm current figure with your reseller)
Servers	Not needed for servers. Defender for Servers Plan 2 already includes premium MDVM (Security Baselines Assessment included). This is a client-device decision only.

The decision: stay on core unless your control owner specifically needs measured CIS/STIG benchmark compliance as the evidence artifact for the MDE-managed client fleet.

Defender for Cloud servers

Servers run through Defender for Cloud, which adds a richer assessment surface and the one auto-remediation lever the workstation models lack:

OS baseline (Machine Configuration). Assesses the in-guest security baseline against the Microsoft Cloud Security Benchmark (AuditIfNotExists) and, with the guest assignment set to ApplyAndAutoCorrect, continuously self-corrects drift inside the machine (Microsoft), the auto-remediation the MDE-managed models can't do.
Regulatory compliance dashboard. Continuous pass/fail against a standard you add (e.g., NIST SP 800-171), exportable as assessor evidence (Microsoft).
File Integrity Monitoring. Near-real-time detection of changes to OS files, the registry, and application files (Microsoft).
Secure-score recommendations cover the remaining attack surface (open ports, vulnerable software), continuously assessed, then remediated on demand (manual steps, or a one-click Fix where offered), not continuously auto-corrected like the OS baseline (Microsoft).

All GA in Azure Government.

What this means for CMMC

Continuous monitoring (CA.L2-3.12.3 / NIST SP 800-171 Rev. 3 3.12.3) is satisfied for all three models. Intune compliance reports, MDE per-setting status + MDVM baselines, and the Defender-for-Cloud assessment surfaces are all valid ongoing-monitoring evidence.
The access-control dimension that compliant-device CA provides for Intune-managed devices is absent on the non-Intune models by design; a hybrid-joined MDE-managed workstation can still be identity-gated via Require Microsoft Entra hybrid joined device, but nothing gates on configuration health. Record that in the SSP, with re-assertion + Tamper Protection + per-setting status + baseline assessment (workstations) and Defender-for-Cloud assessment + FIM + Azure Policy remediation (servers) as the compensating detective and self-healing controls.

All GA in Azure commercial.

What this means for ongoing assurance

Continuous monitoring (NIST SP 800-171 Rev. 3 3.12.3) is satisfied for all three models. Intune compliance reports, MDE per-setting status + MDVM baselines, and the Defender-for-Cloud assessment surfaces are all valid ongoing-monitoring evidence.
The access-control dimension that compliant-device CA provides for Intune-managed devices is absent on the non-Intune models by design; a hybrid-joined MDE-managed workstation can still be identity-gated via Require Microsoft Entra hybrid joined device, but nothing gates on configuration health. Record that in your security plan, with re-assertion + Tamper Protection + per-setting status + baseline assessment (workstations) and Defender-for-Cloud assessment + FIM + Azure Policy remediation (servers) as the compensating detective and self-healing controls.

Portal & Tenant Endpoints

GCC High
Commercial

GCC High MDE operates on the US Government sovereign cloud. The portal and all telemetry remain within the US Government cloud boundary.

	Value
Portal	`https://security.microsoft.us`
Onboarding package endpoint	`*.security.microsoft.us`
Data residency	United States (FedRAMP High boundary)
SIEM / Streaming API	Event Hub or Sentinel (GCC High workspace required)

Tenant verification: In the Defender portal, navigate to Settings > Endpoints > General > About. Confirm Cloud shows US Government.

	Value
Portal	`https://security.microsoft.com`
Onboarding package endpoint	`*.security.microsoft.com`
Data residency	Per your M365 tenant geography
SIEM / Streaming API	Event Hub or Sentinel (any workspace)

Onboarding

How each device population receives the MDE sensor depends on its management model. The matrix routes each population to the right procedure below:

Device population	Onboarding mechanism	Where covered
Intune MDM-managed	Intune EDR policy pushes the sensor automatically	Onboarding Devices via Intune below
MDE-managed workstations	Local script, Group Policy, or MECM	Onboarding MDE-Attached Workstations below
MDE-managed servers	Local script (Defender for Business Servers or standalone MDE for Server) or Defender for Cloud + Azure Arc (Defender for Servers P1/P2, non-Azure servers)	Onboarding MDE-Attached Servers below

Onboarding Devices via Intune

For Intune-managed devices, the recommended onboarding method is Intune MDM: no scripts, no GPO, no manual package distribution. Intune deploys the MDE sensor directly through the Endpoint Security policy.

Step 1: Enable the MDE–Intune Integration

GCC High
Commercial

Sign in to https://security.microsoft.us with a Global Admin or Security Admin account
Open System > Settings (or the gear icon). The Settings page is a hub listing eight areas; select the Endpoints row, then in the Endpoints navigation choose General > Optional features. Microsoft's documentation still calls this page Advanced features, and older tenants may still show that label; it is the same page, the one that opens with Restrict correlation to within scoped device groups and Enable EDR in block mode
Scroll down the page to Microsoft Intune connection and toggle it to On
Select Save preferences

Sign in to https://security.microsoft.com
Open System > Settings (or the gear icon). The Settings page is a hub listing eight areas; select the Endpoints row, then in the Endpoints navigation choose General > Optional features. Microsoft's documentation still calls this page Advanced features, and older tenants may still show that label; it is the same page, the one that opens with Restrict correlation to within scoped device groups and Enable EDR in block mode
Scroll down the page to Microsoft Intune connection and toggle it to On
Select Save preferences

Then finish the handshake on the Intune side: Intune > Endpoint security > Microsoft Defender for Endpoint. Within about 15 minutes of the Defender-side toggle the page shows a Last synchronized timestamp and Connection status leaves Unavailable. A tenant whose connection is established but has nothing on this page turned on shows Available, a state Learn does not document (it lists only Unavailable and Enabled); it is not a fault. Under Compliance policy evaluation, turn on Connect Windows devices version 10.0.15063 and above to Microsoft Defender for Endpoint and select Save; the status changes to Enabled immediately (field-verified in GCC High, September 2026), and this toggle is what lets the row 18 compliance policy read the machine risk score. Expect a blue banner afterward saying the connector is active for Windows but no compliance policy includes a risk assessment; it clears once the row 18 compliance policy is deployed and is not something to fix here (Configure Conditional Access in Defender for Endpoint; Connect Defender for Endpoint to Intune). A second, independently documented check that Step 2's Auto from connector option will work: Tenant administration > Connectors and tokens > Microsoft Defender for Endpoint shows Connected (Deploy EDR policy with Intune).

Once connected, Intune and the Defender portal share device state: compliance policies can reference MDE risk levels, and Intune shows the MDE onboarding status per device.

Step 2: Create an Endpoint Detection & Response Policy

Navigate to Intune > Endpoint security > Endpoint detection and response > Create policy
Platform: Windows 10, Windows 11, and Windows Server
Profile: Endpoint detection and response
Name: Win - Custom - ES - Defender for Endpoint Onboarding. This policy is Layer 1 row 15 of the Open Intune Baseline deployment, one of the three manual creations because the onboarding blob is tenant-specific; naming it the OIB way keeps it sorted with the rest of the baseline. The OIB compliance policy Win - OIB - Compliance - U - Defender for Endpoint - v3.1 (row 18) reads the machine risk score this sensor reports, so it marks any device this policy has not reached as non-compliant.

Setting	Value	Reason
Microsoft Defender for Endpoint client configuration package type	Auto from connector	Intune retrieves the onboarding blob automatically from the MDE–Intune connector; stays current if Microsoft rotates the onboarding payload. Pick plain Onboard only if the connector is unavailable, and fix the connector rather than pasting a manual blob that will drift out of date
Sample sharing	None	CMMC best practice. Automated investigation's submission of suspect files can inadvertently send CUI to Microsoft Commercial analysis infrastructure. Sample sharing must be off for CUI-scoped tenants
[Deprecated] Telemetry reporting frequency	Not configured	Deprecated setting. Configuring it in GCC High produces persistent error states in the Intune policy assignment report. Leave unconfigured

Setting	Value	Reason
Microsoft Defender for Endpoint client configuration package type	Auto from connector	Intune retrieves the onboarding blob automatically from the MDE–Intune connector; stays current if Microsoft rotates the onboarding payload. Pick plain Onboard only if the connector is unavailable, and fix the connector rather than pasting a manual blob that will drift out of date
Sample sharing	None	Recommended for tenants handling sensitive data. Automated investigation's submission of suspect files can inadvertently send sensitive content to Microsoft analysis infrastructure. Turn sample sharing off where data sensitivity warrants it
[Deprecated] Telemetry reporting frequency	Not configured	Deprecated setting that can produce persistent error states in the Intune policy assignment report. Leave unconfigured

Assign to All Devices (or your managed device group)

Step 3: Verify Onboarding

Allow 15–30 minutes after policy assignment for devices to check in and onboard.

In the Defender portal:

Navigate to Assets > Devices
Onboarded devices appear with a Sensor health of Active
Devices show Onboarded in the Onboarding state column

In Intune:

Navigate to Endpoint security > Endpoint detection and response and open the EDR Onboarding Status tab: a device-count summary plus a per-device list with onboarding status and sensor health. Select a device to drill in. The Summary tab on the same page reports the policy's deployment status (Monitor and validate EDR deployment).
Fleet-level: Endpoint security > Overview shows the connector status and the count of Windows devices onboarded versus not onboarded (Endpoint security dashboard).
The redesigned per-device page (Devices > [device]) has no Endpoint security section; onboarding state is not shown there, so do not look for it on the device Overview.
These Intune views lag the Defender portal, sometimes by hours. Microsoft describes the onboarding chart as the count of devices that report sensor status, and that report reaches Intune through the device's MDM check-in against the EDR policy, not through the Defender connector. A device that the Defender inventory already shows as Onboarded and Active can sit at 0 / 0 in Intune until it checks in after the policy landed (steady-state check-in is about every 8 hours; the change notification that follows a new assignment can take "immediately up to a few hours"), and Learn adds that reports can trail the device further (policy refresh intervals; onboarding status data source). Force it with Devices > [device] > Sync, wait a few minutes, confirm the EDR policy shows Succeeded for the device, then Refresh the report. The Defender portal plus the on-device registry and service checks are the authoritative pair; the Intune report is confirmation, not the source of truth.

On-device verification:

Get-Service -Name Sense | Select-Object Status, StartType

Status should be Running, StartType should be Automatic.

Onboarding here also onboards the device for Purview Endpoint DLP; there is no second package. Confirm that side in Endpoint DLP Uses the Same Onboarding below.

Onboarding MDE-Attached Workstations

Since these devices are not enrolled in Intune, you cannot use the Intune EDR policy to push the onboarding package. Pick the deployment mechanism that fits the fleet: local script for ad-hoc and small groups, Group Policy for domain-joined estates, or MECM for environments with an existing ConfigMgr infrastructure. All three paths produce the same end state.

Prerequisites (all paths)

MDE P2 license assigned to a user account. For kiosk or shared machines with no regular signed-in user, create a dedicated licensing-anchor service account and assign the P2 license to it.
In the Defender portal, Settings → Endpoints → Advanced features, ensure Microsoft Intune connection is on (this is what makes MDE-attached devices appear in Intune for Security Settings Management).
In Intune, Endpoint security → Microsoft Defender for Endpoint, ensure Allow Microsoft Defender for Endpoint to enforce Endpoint Security configurations is turned on.
Confirm the correct tenant cloud before downloading any package: security.microsoft.us for GCC High, security.microsoft.com for Commercial. A GCC High tenant that runs a Commercial-downloaded package will fail at the discovery stage every time.

MDE P2 license assigned to a user account. For kiosk or shared machines with no regular signed-in user, create a dedicated licensing-anchor service account and assign the P2 license to it.
In the Defender portal, Settings → Endpoints → Advanced features, ensure Microsoft Intune connection is on (this is what makes MDE-attached devices appear in Intune for Security Settings Management).
In Intune, Endpoint security → Microsoft Defender for Endpoint, ensure Allow Microsoft Defender for Endpoint to enforce Endpoint Security configurations is turned on.
Confirm the correct tenant cloud before downloading any package from security.microsoft.com. Downloading from the wrong tenant cloud causes the package to fail at the discovery stage every time.

Path A: Local onboarding script

Best for small populations, lab machines, and one-off fixes.

Open the Defender portal and go to Settings → Endpoints → Onboarding.
Select the operating system (Windows 10/11).
Select deployment method Local script (for up to 10 machines).
Click Download onboarding package, a .zip containing WindowsDefenderATPLocalOnboardingScript.cmd.
Copy the .cmd to the target workstation and run it from an elevated command prompt. The script writes the onboarding blob to the registry and starts the sensor.
Verify on the device within 10–15 minutes:
- Get-MpComputerStatus shows AMRunningMode = Normal and OnboardingState = 1.
- Event log Microsoft-Windows-SENSE/Operational shows event ID 5 ("Onboarded to Microsoft Defender for Endpoint").
Verify in the Defender portal (Device inventory) within 15–30 minutes: the device appears with Sensor health = Active.

Path B: Group Policy

Best for domain-joined fleets where machines are not Entra-joined and not in Intune.

Download the onboarding package as in Path A, but select deployment method Group Policy.
The .zip contains WindowsDefenderATPOnboardingScript.cmd and a structured folder. Extract to a domain controller share readable by Domain Computers (e.g., \\dc01\netlogon\MDE\).
In Group Policy Management, create or edit a GPO scoped to the target OU (workstations only; do not mix with server OUs).
Navigate to Computer Configuration → Preferences → Control Panel Settings → Scheduled Tasks. Create an immediate task that runs WindowsDefenderATPOnboardingScript.cmd as SYSTEM. A scheduled task is more reliable than a startup script because it executes without waiting for a reboot.
Link the GPO to the workstation OU and force an update: gpupdate /force on a pilot machine.
Verify on the device with the same checks as Path A.
Confirm tenant-wide rollout by watching the Defender portal Device inventory count climb over the next 24 hours as machines pick up the GPO on their next policy cycle.

Path B: Onboard Defender for Endpoint after Entra hybrid join completes

Order matters: if onboarding runs before hybrid join completes, Security Settings Management creates a synthetic Entra device object that cannot support device-based Conditional Access. Since Entra Hybrid Join is an 8-step process, onboarding completes first unless the onboarding script is written to wait for Entra Hybrid Join completion.

This failure chain is undocumented

Use the script below to enforce ordering and avoid the problem.

The troubleshooting page covers enrollment error codes but says nothing about duplicate device objects. Gate onboarding on completed hybrid join. A device that is already registered reuses its existing registration and no synthetic object is created.
Microsoft's position is that this heals itself: "When a device with a synthetic registration has a full Microsoft Entra registration created for it, the synthetic registration is removed and the devices management continues on uninterrupted".
Microsoft's own device FAQ concedes what happens next: duplicate records can cause "a nondeterministic evaluation of the device and cause access issues."
Field-observed: the removal fails, hybrid join lands a second Entra object for the same machine, and both persist.
In practice, Conditional Access resolves against the synthetic object and users on a correctly hybrid-joined machine are blocked with AADSTS53001 (DeviceNotDomainJoined) on a require-hybrid-joined policy, or AADSTS53000 (DeviceNotCompliant) on a require-compliant policy (error code reference). To see which device claim was actually evaluated, open the failed sign-in in the Entra sign-in logs and check Device info → Join type.

Deploy the following wrapper as the Path B mechanism: point the scheduled task at this script instead of the raw .cmd (action: powershell.exe -ExecutionPolicy Bypass -File \\dc01\netlogon\MDE\MDE-Onboarding-Gate.ps1, run as SYSTEM). It is idempotent, defers until hybrid join is complete, and surfaces stuck devices in the Application event log instead of deferring silently forever. Do not leave the original raw onboarding task in place alongside it; that reopens the race condition.

# MDE-Onboarding-Gate.ps1
# Gates MDE onboarding on completed Entra hybrid join so Security Settings
# Management binds to the hybrid device object instead of minting a synthetic one.

$PayloadPath   = '\\dc01\netlogon\MDE\WindowsDefenderATPOnboardingScript.cmd'  # GPO package, NOT the Local script
$StateKey      = 'HKLM:\SOFTWARE\YourOrg\MdeOnboardingGate'
$MaxQuietDefer = 12    # after ~12 GP cycles, raise a Warning so stuck devices surface

$EventSource = 'MDE-Onboarding-Gate'
if (-not [System.Diagnostics.EventLog]::SourceExists($EventSource)) {
    New-EventLog -LogName Application -Source $EventSource
}

# 1. Idempotence: the documented onboarded check is OnboardingState = 1
$atp = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' -ErrorAction SilentlyContinue
if ($atp.OnboardingState -eq 1) { exit 0 }

# 2. The gate: hybrid join must be complete BEFORE onboarding
$dsreg = dsregcmd /status
$azureAdJoined = [bool]($dsreg | Select-String -Quiet '^\s*AzureAdJoined\s*:\s*YES')
$domainJoined  = [bool]($dsreg | Select-String -Quiet '^\s*DomainJoined\s*:\s*YES')

if (-not ($azureAdJoined -and $domainJoined)) {
    New-Item -Path $StateKey -Force | Out-Null
    $n = 1 + [int](Get-ItemProperty $StateKey -ErrorAction SilentlyContinue).DeferCount
    Set-ItemProperty -Path $StateKey -Name DeferCount -Value $n
    if ($n -eq $MaxQuietDefer) {
        Write-EventLog -LogName Application -Source $EventSource -EventId 2001 -EntryType Warning -Message `
          "MDE onboarding deferred $n times; hybrid join has not completed. Check the SCP and Entra Connect sync scope (HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus: 16/17 = SCP, 36/37 = Entra Connect) and dsregcmd /status."
    }
    exit 0   # try again on the next policy cycle
}

# 3. Onboard, unattended. (The Local package's .cmd contains a Y/N console prompt
#    and a trailing pause; it hangs a SYSTEM task. Use the GPO package.)
if (-not (Test-Path $PayloadPath)) {
    Write-EventLog -LogName Application -Source $EventSource -EventId 2002 -EntryType Error -Message "Onboarding payload not found: $PayloadPath"
    exit 1
}
$proc = Start-Process -FilePath 'cmd.exe' -ArgumentList '/c', "`"$PayloadPath`"" -Wait -PassThru -WindowStyle Hidden

# 4. Verify against the documented state flag, not the payload exit code alone
Start-Sleep -Seconds 30
$atp = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' -ErrorAction SilentlyContinue
if ($atp.OnboardingState -eq 1) {
    Write-EventLog -LogName Application -Source $EventSource -EventId 2000 -EntryType Information -Message "MDE onboarded after hybrid join (payload exit $($proc.ExitCode))."
    Remove-Item -Path $StateKey -Recurse -Force -ErrorAction SilentlyContinue
    exit 0
}
Write-EventLog -LogName Application -Source $EventSource -EventId 2003 -EntryType Error -Message "Payload ran (exit $($proc.ExitCode)) but OnboardingState is not 1. See https://learn.microsoft.com/defender-endpoint/troubleshoot-onboarding."
exit 1

For devices already duplicated: keep the Hybrid joined object and remove the synthetic one (blank Join Type, managementType = MicrosoftSense) through one of the two supported paths, Intune Devices → All devices → Delete or removal from the Defender portal's Configuration Management scope; the change propagates between the two services (deletion FAQ). Do not delete the hybrid object directly in Entra. The identification priority table and cleanup order live in Entra Device Hygiene. For a device wedged client-side, the community-verified reset (not documented by Microsoft) is: offboard MDE, delete the HKLM\SOFTWARE\Microsoft\SenseCM registry key, run dsregcmd /leave elevated, reboot, and re-onboard through the gate.

Path C: Microsoft Endpoint Configuration Manager (MECM)

Best for environments with an existing ConfigMgr infrastructure, particularly large Windows fleets with mixed server and workstation populations.

Download the onboarding package as in Path A, but select deployment method System Center Configuration Manager (current branch) or Microsoft Endpoint Configuration Manager. This produces a .zip tuned for MECM deployment.
In the MECM console, navigate to Assets and Compliance → Endpoint Protection → Microsoft Defender ATP Policies. (The ConfigMgr console, current branch 2207+, retains the legacy "Microsoft Defender ATP" node name even though the product is now Microsoft Defender for Endpoint.)
Select Create Microsoft Defender ATP Policy and import the .onboarding file from the downloaded package.
Configure the policy settings: set Sample sharing to None (CMMC best practice), leave telemetry reporting at default, save the policy.
Deploy the policy to a device collection containing the target workstations. Use a pilot collection first before rolling to production collections.
Monitor deployment status in Monitoring → Deployments until the policy shows compliant across the pilot collection.
Verify on individual devices with the same checks as Path A, and verify fleet-wide appearance in the Defender portal's Device inventory.

Download the onboarding package as in Path A, but select deployment method System Center Configuration Manager (current branch) or Microsoft Endpoint Configuration Manager. This produces a .zip tuned for MECM deployment.
In the MECM console, navigate to Assets and Compliance → Endpoint Protection → Microsoft Defender ATP Policies. (The ConfigMgr console, current branch 2207+, retains the legacy "Microsoft Defender ATP" node name even though the product is now Microsoft Defender for Endpoint.)
Select Create Microsoft Defender ATP Policy and import the .onboarding file from the downloaded package.
Configure the policy settings: set Sample sharing to None (recommended for sensitive-data tenants), leave telemetry reporting at default, save the policy.
Deploy the policy to a device collection containing the target workstations. Use a pilot collection first before rolling to production collections.
Monitor deployment status in Monitoring → Deployments until the policy shows compliant across the pilot collection.
Verify on individual devices with the same checks as Path A, and verify fleet-wide appearance in the Defender portal's Device inventory.

Convergence point (all paths)

Regardless of the onboarding mechanism, once the sensor is reporting, the device appears in two places:

Defender portal → Device inventory: Sensor health = Active and Onboarding state = Onboarded.
Intune → Devices → All devices: Managed by = MDE (not Intune).

At that point, add the device to the Workstations-MDE Entra device group (via dynamic rule or manual assignment) and the Win - OIB - ES - * policy set applies automatically, the same canonical OIB Endpoint Security set already targeting your Intune-managed workstations. No further per-device action is required, and no separate MDE-only policy set is needed.

Onboarding MDE-Attached Servers

Server onboarding depends on which server-licensing SKU from the Licensing matrix above is in play. Pick the path that matches the chosen SKU.

Defender for Servers Plan 1 or Plan 2 (Defender for Cloud)

Azure portal → Defender for Cloud → Environment settings → [subscription]
Enable Defender for Servers Plan 1 or Plan 2 on the subscription
For Azure VMs: Defender for Cloud auto-provisions the MDE agent; no manual action needed
For on-premises or other cloud servers: install the Azure Arc agent first to connect the server to Azure, then Defender for Cloud auto-provisions MDE through Arc
For eligible servers without Arc: configure direct onboarding through MDE, including the Defender for Cloud subscription association. Merely running the local MDE onboarding script does not configure that association. Review the reduced feature coverage.

Defender for Business Servers (commercial SMB) or MDE for Server standalone (any tenant)

No Azure subscription, no Defender for Cloud, no Azure Arc required. Onboard via the same local-script path used for MDE-attached workstations:

Defender portal → Settings → Endpoints → Onboarding
Select Windows Server [version] as the operating system
Choose deployment method: Local script (ad-hoc / small fleets), Group Policy (domain-joined estates), or Microsoft Endpoint Configuration Manager (existing MECM environments)
Run the onboarding package on each server

Once onboarded by either path, the server appears in the Defender portal (device inventory) and Intune (Managed by: MDE). The Endpoint Security policies assigned to the Servers-MDE device group (both the forked Svr - set and the workstation policies that target both groups) apply automatically.

Defender for Cloud vs. Defender portal: applies only to Defender for Servers P1/P2

For tenants on Defender for Servers P1 or P2, both portals show the same servers but serve different purposes:

Portal	What it manages
Defender portal (`security.microsoft.us`)	Alerts, incidents, device inventory, threat hunting (the SOC/security operations view)
Defender for Cloud (Azure portal)	Server onboarding, licensing, vulnerability assessment, adaptive application controls, file integrity monitoring, regulatory compliance dashboard (the infrastructure security view; P2 features only)
Intune	Endpoint Security policy assignment: Antivirus, Firewall, ASR, EDR only

You do not need to choose between them.

For tenants on Defender for Business Servers or the standalone MDE for Server SKU, Defender for Cloud is not part of the picture; only the Defender portal and Intune apply.

Defender for Cloud vs. Defender portal: applies only to Defender for Servers P1/P2

For tenants on Defender for Servers P1 or P2, both portals show the same servers but serve different purposes:

Portal	What it manages
Defender portal (`security.microsoft.com`)	Alerts, incidents, device inventory, threat hunting (the SOC/security operations view)
Defender for Cloud (Azure portal)	Server onboarding, licensing, vulnerability assessment, adaptive application controls, file integrity monitoring, regulatory compliance dashboard (the infrastructure security view; P2 features only)
Intune	Endpoint Security policy assignment: Antivirus, Firewall, ASR, EDR only

You do not need to choose between them.

For tenants on Defender for Business Servers or the standalone MDE for Server SKU, Defender for Cloud is not part of the picture; only the Defender portal and Intune apply.

Onboarding and management-state failures. Three field-diagnosed cases where a device reports a healthy state it does not have:

Endpoint DLP Uses the Same Onboarding

Device onboarding is one mechanism shared by Defender for Endpoint and Microsoft Purview. A Windows device onboarded to MDE by any path above is already onboarded for Purview's device-based features (Endpoint DLP and insider risk management), and a device onboarded from the Purview portal is onboarded to MDE by the same act. There is no second agent and no second package; the Sense sensor carries both (Onboard Windows devices into Microsoft 365; Learn about Endpoint DLP). What remains is one tenant-wide switch and a per-device confirmation.

Step 1: Turn on device onboarding in Purview (once per tenant)

GCC High
Commercial

Sign in to https://purview.microsoft.us.
Open Settings (the gear) > Device onboarding > Devices.
Select Turn on device onboarding.

Sign in to https://purview.microsoft.com.
Open Settings (the gear) > Device onboarding > Devices.
Select Turn on device onboarding.

Microsoft documents about 60 seconds for the switch to take effect and says to allow up to 30 minutes before escalating. Every device already onboarded to MDE then appears in this list with no further action. Only a device that is not in MDE needs a package from this page's Onboarding button (Intune, Configuration Manager, Group Policy, local script, or VDI), and the Intune option is the EDR policy from Step 2 above, so for an Intune-managed fleet the answer is always "fix the MDE onboarding," never "onboard again here."

Step 2: Confirm a specific device

On the same Devices page, find the device by name and read three things:

Check	Healthy	If not
Listed at all	The device appears	Either the tenant switch was just flipped (wait) or the device is not MDE-onboarded. The Purview list follows the MDE inventory, so go back to Step 3: Verify Onboarding and fix the sensor; nothing on this page can substitute for that
Configuration status	Updated: the device heartbeats to Purview and Defender Antivirus real-time protection and behavior monitoring are on	Not updated points at the antivirus settings; Not available means just onboarded or an OS too old to report properties
Policy sync status	Updated: the device holds the current version of every DLP policy that targets Devices	Not available is the expected value until at least one Endpoint DLP policy exists, so a freshly built tenant shows it on every device until the 14-3 device policies are published. Not updated can take up to two hours to clear, and the device must be online to sync

Selecting the device opens a details pane with Last seen, Last policy sync time, Endpoint DLP status (enabled or disabled for this device), and Valid user, which reports whether the signed-in user has an Entra account and is in scope of a Devices-targeted DLP policy (status values and the troubleshooting workflow).

The same attributes are queryable in Defender advanced hunting, where the DeviceInfo table carries a DlpInfo JSON column; IsDlpEnabled and IsDlpConfigurationValid both true is the healthy state:

DeviceInfo
| where DlpInfo != ""
| summarize arg_max(Timestamp, DlpInfo) by DeviceName
| where DeviceName startswith "<device>"

On the device itself, the signals are the MDE ones: OnboardingState = 1 under HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status and the Sense service running. Microsoft documents no separate on-device marker for the DLP layer; its health is read from the service side. A positive end-to-end signal is the device's file activity appearing in Purview Activity explorer, which happens before any policy exists because Always audit file activity for devices is on by default (Endpoint DLP settings).

What onboarding does not give you

Licensing is per user, not per device. Endpoint DLP needs E5 or G5 Compliance (or the equivalent add-on) on the signed-in user; the Valid user attribute goes false otherwise (Get started with Endpoint DLP).
Browser enforcement is Edge-native. Chrome and Firefox need the Purview extension; other browsers are treated as unallowed and redirected. The policies in 14-3 assume this.
Windows Server is opt-in. An onboarded server reports no Endpoint DLP events until Endpoint DLP support for onboarded servers is turned on under the DLP Settings > Endpoint settings (Enable Endpoint DLP for Windows Servers).
Connectivity is the MDE URL set. Endpoint DLP reports through the same WinHTTP channel as the sensor and Microsoft points proxy administrators at the Defender for Endpoint URL list, so the government connectivity URLs already allowed for MDE cover it (Configure device proxy for Endpoint DLP).

Offboarding

For obvious reasons, Defender does not make itself easy to remove. Offboarding is an easy step to miss, and skipping it fails quietly. The sensor keeps reporting to the tenant that onboarded it, that tenant keeps a live-looking device record, and a later onboarding to a different tenant is refused or leaves the device split between two organizations: Security Settings Management reports Tenant mismatch (enrollment status 15) when the Defender tenant and the Entra tenant disagree (troubleshooting). Offboard before the Intune retire, before the Entra record is touched, and before any move to another tenant. It is the first step of the retirement order, of every single-device tear-down, and of a tenant move.

Get the package from the tenant the device currently reports to. Defender portal (security.microsoft.ussecurity.microsoft.com) → System → Settings → Endpoints → Device management → Offboarding. Select the operating system and a deployment method; the download is WindowsDefenderATPOffboardingPackage_valid_until_YYYY-MM-DD.zip.

Method	Use when	Mechanics
Defender deployment tool (the Offboard button)	One-off moves, lab devices, a wedged machine	The zip holds only the `.offboarding` file. The tool is a separate download: Settings → Endpoints → Onboarding → Windows → Onboard, name the package, pick the shortest expiry, Generate, Download deployment tool. It arrives named after the package (`DefenderDeploymentTool_Onboard_<name>.exe`; Learn calls it `DefenderDT.exe`), and the access key shown beside it is an onboarding credential, not needed here and to be handled as a secret. Put the exe and the `.offboarding` file in one folder and, from an elevated prompt there, run `<exe> -?` to confirm the switches, then `<exe> -Offboard` (add `-File:<path>` if the file is elsewhere) and answer Y; success prints `exit code: 0 [Success]` (`3` = not onboarded here, `302` = invalid or expired file). Never double-click the tool: that starts onboarding with that key. Afterwards, expire or hide the unused onboarding package under Settings → Endpoints → Deployment packages, and keep the exe for next time
Intune EDR policy	Group or fleet offboarding of Intune-managed devices	Endpoint security → Endpoint detection and response, new policy with client configuration package type = Offboard; paste the contents of the `.offboarding` file
Intune custom OMA-URI	Tenants that keep EDR policy reserved for onboarding	`./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Offboarding`, String, value = the `.offboarding` file contents
Group Policy or ConfigMgr	MDE-attached fleets without Intune	Immediate scheduled task running the `.cmd` (GPO), or the ConfigMgr offboarding configuration file

The card you pick decides what is inside the zip, and none of them contains anything runnable. Defender deployment tool (Offboard) and Mobile device management (Download file) each yield a lone .offboarding text file that does nothing if double-clicked; the first is consumed by DefenderDT.exe on the device, the second is pasted into an Intune EDR policy or OMA-URI, and you should download the file from the card that matches the method you will use. Configuration Manager yields the ConfigMgr configuration file. The Intune card at the top of the page downloads nothing; it creates an EDR offboarding policy through the connector, which only reaches a device that is still enrolled. Older portal versions, and the current Learn pages, also offer a Local script method whose zip holds a runnable .cmd; if your portal shows it, that is the equivalent one-device path.

Exit code 3 (NotOnboarded) from the deployment tool is a claim to check, not a conclusion. Confirm the local state before deciding there is nothing to offboard: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status' (OnboardingState 1 = onboarded) and sc.exe query sense (RUNNING when onboarded), and look the device up in the portal's device inventory. If the sensor is not onboarded, skip the step; a device carrying Intune's Defender Antivirus policy has not necessarily received the EDR onboarding policy. If it is onboarded, the tool has misjudged it: fall back to the Intune EDR offboarding policy (the Intune card) or the MDM file through a custom OMA-URI while the device is still enrolled.

Four facts govern every method (Offboard devices, offboarding with MDM, Intune EDR offboarding):

The package expires days after download, and the number is disputed. Learn documents seven days for the script and MDM packages; the portal's own help pane currently says three. The exact date is shown at download and embedded in the filename (valid_until_YYYY-MM-DD), and expired packages are rejected. Plan on three: download when you are ready to run it, not when you plan the work.
Offboarding disables the sensor; it does not uninstall anything. Telemetry stops, the device shows Inactive in the portal after seven days, and historical data stays until the retention period ends (the device profile lingers in inventory for up to 180 days). That inactive record is normal, not a failed offboarding.
Never target a device with onboarding and offboarding at the same time. Exclude the device from the onboarding EDR policy's assignment before the offboarding policy reaches it; the collision is unpredictable.
The package is tenant-specific. Running one from the wrong tenant fails with Event ID 70, "Offboarding script is for a different organization" (onboarding troubleshooting), which is also the tell that a device you assumed was clean still belongs to another organization.

Verify. If you used the deployment tool, its console result and the WDATPOffboarding source in the Application event log confirm the local action (its own log is under C:\ProgramData\Microsoft\DefenderDeploymentTool\). For policy-delivered offboarding, two places. In Intune, Endpoint security → Endpoint detection and response → [offboarding policy]: the Device and user check-in status chart shows the device Succeeded (use View report to find it by name; the same list is under Devices → [device] → Device configuration). Status stays Pending until the device checks in, so force a sync rather than wait, and expect Per setting status to show the Health Status for offboarded devices setting in an odd state; Microsoft documents it as read-only and non-remediable, not a failure. Succeeded means the instruction was delivered and applied; the proof the sensor stopped is the Defender portal's device inventory, where the last-seen time stops advancing and the device drops to Inactive within seven days. The device's Intune record still shows Managed by: MDE until you delete it; that record does not clear itself.

Key Policies

Tamper Protection

Tamper Protection prevents local administrators, malware, and scripts from disabling MDE components (real-time protection, behavior monitoring, cloud-delivered protection). Enable this before any other MDE configuration.

Navigate to Intune > Endpoint security > Antivirus > Create policy
Platform: Windows 10, Windows 11
Profile: Microsoft Defender Antivirus

Setting	Value
Allow Tamper Protection	Allowed
Turn on cloud-delivered protection	Enabled
Cloud-delivered protection level	High
Turn on real-time protection	Enabled

Do not manage Tamper Protection via Settings Catalog

Tamper Protection can only be reliably managed through the Endpoint Security > Antivirus profile. If configured via Settings Catalog at the same time, conflicts will result and Intune marks the setting as Conflict, leaving the device in an indeterminate state.

Attack Surface Reduction (ASR) Rules

ASR rules block specific high-risk behaviors that malware commonly exploits (Office macros launching child processes, credential scraping, script obfuscation) without requiring signature updates.

The OIB ships a pre-configured ASR policy (Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2) - v3.7) covering 18 rules. For the complete rule list and configured modes, see Attack Surface Reduction in the Appendix. This section covers the enforcement mode progression and the rules that require judgment before deploying.

Enforcement Modes

Mode	Behavior	Appropriate State
Audit	Behavior is allowed; event logged silently	Initial deployment validation only: 2–4 weeks to surface compatibility issues. Never a permanent production state for high-value rules
Warn	Behavior is blocked; user sees a notification and can choose to allow it once	Intermediate state for rules where legitimate use is possible but needs visibility before committing to Block
Block	Behavior is terminated silently; no user override	Target production state for all managed devices

Deploy new ASR rules in Audit for 2–4 weeks, advance to Warn to confirm block behavior with user visibility, then promote to Block. Audit and Warn events both appear in Defender portal > Reports > Attack surface reduction rules and in the Windows Event Log (Event ID 1121 = blocked/warned, 1122 = audited).

Policy conflict resolution: Block beats Warn beats Audit

When multiple Intune policies target the same device with different modes for the same ASR rule, the strictest mode wins: Block overrides Warn, Warn overrides Audit. The weaker policy is silently overridden; its events continue to be logged, but the enforced behavior is the stricter value. Verify no higher-priority policy is silently promoting your Audit or Warn rules to Block before concluding your validation period.

Rules Requiring Judgment

Most OIB rules ship at Block and need no customization. The rules below ship at Warn or Audit because the OIB acknowledges legitimate compatibility impact or higher false positive risk.

Rule	OIB Mode	Rationale
Block all Office applications from creating child processes	Block	Highest-value rule: stops macro-launched malware. Known OAuth impact in thick-client Outlook (see note below).
Block Office communication application from creating child processes	Warn	Affects Outlook OAuth and Teams integrations. Ships at Warn (user can override once) to surface impacted workflows before full enforcement.
Block executable files by prevalence, age, or trusted list	Audit	High false-positive rate for custom or legacy line-of-business apps. Validate before promoting to Warn or Block.
Block rebooting machine in Safe Mode	Audit	Admins use Safe Mode for recovery and troubleshooting. Evaluate operational impact before promoting.
Enable Controlled Folder Access	Audit Mode	Ransomware mitigation: blocks unauthorized writes to Documents, Desktop, and similar folders. Ships at Audit because many legitimate apps write there; exclude them before promoting to Block.

Block Office child processes breaks OAuth in thick-client Outlook: resolve by workflow change, not policy weakening

When Block all Office applications from creating child processes is set to Block, Outlook cannot spawn the WebView2 child process it requires to display OAuth authentication popups. Adding any OAuth-authenticated external account (Gmail, Google Workspace, third-party calendar connectors) in classic Outlook silently fails. The authentication window never opens.

Why it breaks: Outlook's "Add Account" flow for modern-auth providers launches WebView2 as a child process to render the OAuth consent screen. The ASR rule terminates this at the OS level before WebView2 initializes, so the failure appears unrelated to any policy and only manifests on managed devices where Block mode is active.

The correct response is a decision, not a workaround. This rule is one of the highest-value ASR controls because it directly blocks macro-launched malware, a primary delivery mechanism for ransomware and credential stealers. Weakening the rule in response to a compatibility complaint is not an acceptable permanent state for any managed device environment.

Before relaxing the rule, ask the workflow question first:

Option 1: Workflow change (preferred): Access Gmail in a browser. This achieves the same user outcome without weakening the device's security posture. For environments processing regulated or sensitive data, this is the strongly recommended path: connecting a personal Gmail account to the same thick-client Outlook instance that handles sensitive business mail creates a commingling risk: the same application window, clipboard, and attachment handling context for both regulated and personal data. The ASR rule is surfacing a workflow that should not exist on a managed device in the first place.

Option 2: ASR rule exclusion (if business-justified): If connecting an OAuth provider to thick-client Outlook is a genuine, documented business requirement approved by the security team, add Outlook to the per-rule exclusion list rather than changing the rule mode. This is narrower than Warn or Audit: it allows only Outlook to spawn child processes while the rule remains enforced for Word, Excel, PowerPoint, and all other Office apps.

Navigate to Intune > Endpoint security > Attack surface reduction > [your ASR policy] > Edit
Under Attack Surface Reduction Only Exclusions, add:
```
%ProgramFiles%\Microsoft Office\root\Office16\OUTLOOK.EXE
```
Note: exclusions apply to all rules in that policy, not a single rule. To limit scope, isolate the child-process rules into their own ASR policy and add the exclusion only there.

Option 3: Warn mode (structured validation): The OIB ships Block Office communication application from creating child processes at Warn for exactly this reason: users can override once, which surfaces the workflow in your Audit logs without leaving the rule entirely unenforced. Use Warn as a time-limited validation step, not a permanent state. Audit mode (fully allow + log) is appropriate only during initial deployment and is a finding if used as a long-term configuration for a high-value rule.

EDR in Block Mode

EDR in Block Mode is the post-breach backstop for fleets where a non-Microsoft antivirus is primary and Microsoft Defender Antivirus runs in passive mode: it lets Defender block and remediate behavioral EDR detections the third-party AV missed (EDR in block mode). Enable it only in that scenario.

Where Defender AV is your active, primary AV (the typical Intune-managed posture), Microsoft recommends leaving it off: "Microsoft recommends disabling EDR in block mode, when the primary antivirus software on the system is Microsoft Defender Antivirus" (EDR block mode FAQ). Active Defender AV, ASR, and the always-on client behavioral blocking and feedback-loop blocking already cover this, so 3.14.2 (protection from malicious code) is satisfied without it; enabling block mode adds nothing but redundant overhead.

Third-party AV primary (Defender AV passive): in the Endpoint detection and response policy (Step 2 above), set EDR in block mode: Enabled.
Defender AV primary: leave EDR in block mode: Not configured / Off.
Verify the running mode on a device: Get-MpComputerStatus | Select-Object AMRunningMode (Normal = active AV; Passive = passive; EDR Block Mode = passive with block mode on).

Microsoft Sentinel Integration

For organizations operating a SOC or requiring a SIEM for continuous monitoring (GCC High: CA.L2-3.12.3 / Commercial: NIST SP 800-171 Rev. 3 3.12.3), MDE integrates natively with Microsoft Sentinel.

For organizations operating a SOC or requiring a SIEM for continuous monitoring (NIST SP 800-171 Rev. 3 3.12.3), MDE integrates natively with Microsoft Sentinel.

Connection Method

GCC High
Commercial

In Microsoft Sentinel (Azure Government), navigate to Content hub and install the Microsoft Defender XDR solution
Navigate to Data connectors > Microsoft Defender XDR
Connect. Sentinel begins ingesting MDE incidents, alerts, and device events into the SecurityIncident, SecurityAlert, and DeviceEvents tables
Confirm data is flowing: run DeviceEvents | take 10 in the Log Analytics workspace

GCC High Sentinel workspace requirement

The Sentinel workspace must be in Azure Government (azure.us) to receive data from the GCC High MDE tenant. A Commercial Azure workspace cannot receive GCC High telemetry.

In Microsoft Sentinel, navigate to Content hub and install the Microsoft Defender XDR solution
Navigate to Data connectors > Microsoft Defender XDR
Connect. Sentinel begins ingesting MDE incidents, alerts, and device events
Confirm: run DeviceEvents | take 10 in Log Analytics

GCC High
Commercial

Key Tables for CMMC Audit Evidence

Table	Contains	CMMC Use
`SecurityIncident`	MDE incidents (aggregated alerts)	IR.L2-3.6.2 incident documentation
`SecurityAlert`	Individual MDE alerts	CA.L2-3.12.3 monitoring evidence
`DeviceEvents`	Process creation, file events, network connections	SI.L2-3.14.7 unauthorized use detection
`DeviceLogonEvents`	Interactive and remote logons per device	IA.L2-3.5.1 identification evidence
`DeviceNetworkEvents`	Outbound/inbound connections	SC.L2-3.13.1 network boundary monitoring

Key Tables for Security Program Evidence

Table	Contains	NIST SP 800-171 Rev. 3 Use
`SecurityIncident`	MDE incidents (aggregated alerts)	3.6.2: incident documentation
`SecurityAlert`	Individual MDE alerts	3.12.3: continuous monitoring evidence
`DeviceEvents`	Process creation, file events, network connections	3.14.6: unauthorized use detection
`DeviceLogonEvents`	Interactive and remote logons per device	3.5.1: user identification evidence
`DeviceNetworkEvents`	Outbound/inbound connections	3.13.1: network boundary monitoring

Recommended Workbook

The Microsoft Defender for Endpoint workbook (available in Sentinel's Workbooks gallery) provides a pre-built dashboard covering device health, alert trends, and ASR rule hits, useful for periodic security reviews and as evidence of continuous monitoring for compliance assessments and security program documentation.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.

CMMC Relevance​

NIST SP 800-171 Rev. 3 Relevance​

Management Models: Intune, MDE, and Defender for Cloud​

Licensing: per-user for client OS, per-server for server OS​

Recommendation matrix​

Policy architecture​

Policy delivery across management contexts​

Server Endpoint Security set​

GPO fallback for MDE-only fleets​

Configuration Assurance for Non-Intune Devices​

MDE-managed workstations​

Included with MDE P2: no additional purchase​

Optional upgrade: Defender Vulnerability Management add-on (benchmark compliance)​

Defender for Cloud servers​

What this means for CMMC​

What this means for ongoing assurance​

Portal & Tenant Endpoints​

Onboarding​

Onboarding Devices via Intune​

Step 1: Enable the MDE–Intune Integration​

Step 2: Create an Endpoint Detection & Response Policy​

Step 3: Verify Onboarding​

Onboarding MDE-Attached Workstations​

Prerequisites (all paths)​

Path A: Local onboarding script​

Path B: Group Policy​

Path B: Onboard Defender for Endpoint after Entra hybrid join completes​

Path C: Microsoft Endpoint Configuration Manager (MECM)​

Convergence point (all paths)​

Onboarding MDE-Attached Servers​

Endpoint DLP Uses the Same Onboarding​

Step 1: Turn on device onboarding in Purview (once per tenant)​

Step 2: Confirm a specific device​

What onboarding does not give you​

Offboarding​

Key Policies​

Tamper Protection​

Attack Surface Reduction (ASR) Rules​

Enforcement Modes​

Rules Requiring Judgment​

EDR in Block Mode​

Microsoft Sentinel Integration​

Connection Method​

Key Tables for CMMC Audit Evidence​

Key Tables for Security Program Evidence​

Recommended Workbook​