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

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

Commercial

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:

1. Intune-managed workstation: full MDM enrollment, Entra-joined. The complete Intune channel: Endpoint Security, Configuration, Compliance, Apps, and Platform Scripts.
2. 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).
3. 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:

1. 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).
2. 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 without a regular signed-in user, create a service account as the licensing anchor.

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; non-Azure servers require Azure Arc	≈$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 Microsoft Defender Vulnerability Management, File Integrity Monitoring, Adaptive Application Controls, Regulatory Compliance dashboard	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; non-Azure servers require Azure Arc	≈$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 Microsoft Defender Vulnerability Management, File Integrity Monitoring, Adaptive Application Controls, Regulatory Compliance dashboard	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 (vulnerability assessment, FIM, Adaptive Application Controls, regulatory-compliance dashboard) with no Microsoft-equivalent already in place	Defender for Servers Plan 2	Only path that provides these features; ≈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)
Any GCC High / CMMC tenant planning Sentinel adoption with server security telemetry (regardless of feature need)	Defender for Servers Plan 2	The per-server 500 MB/day Sentinel data ingestion benefit recovers the P2 license premium several times over at typical instrumentation levels, making P2 the cheapest option once Sentinel ingestion is in the picture, not the most expensive. 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 Microsoft Defender Vulnerability Management (the on-server vulnerability scanner that maps to RA.L2-3.11.2), File Integrity Monitoring (maps to SI.L2-3.14.1 system flaw identification + audit log integrity), Adaptive Application Controls, and the Regulatory Compliance dashboard. 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 (worth ≈$4,035/month for 50 servers at Azure Gov PAYG) 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 (vulnerability assessment, FIM, Adaptive Application Controls, regulatory-compliance dashboard) with no Microsoft-equivalent already in place	Defender for Servers Plan 2	Only path that provides these features; ≈3× the cost of P1, justified by the added vulnerability-management, file-integrity-monitoring, and regulatory-dashboard capabilities
Any tenant planning Sentinel adoption with server security telemetry (regardless of feature need)	Defender for Servers Plan 2	The per-server 500 MB/day Sentinel data ingestion benefit recovers the P2 license premium several times over at typical instrumentation levels, making P2 the cheapest option once Sentinel ingestion is in the picture, not the most expensive. 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 Microsoft Defender Vulnerability Management (the on-server vulnerability scanner), File Integrity Monitoring, Adaptive Application Controls, and the Regulatory Compliance dashboard. 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 (worth ≈$4,035/month for 50 servers at PAYG) 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.1	✓	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:

1. 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.
2. 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

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.

Commercial

	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

1. Sign in to https://security.microsoft.us with a Global Admin or Security Admin account
2. Navigate to Settings > Endpoints > Advanced features
3. Enable Microsoft Intune connection
4. Save

Commercial

1. Sign in to https://security.microsoft.com
2. Navigate to Settings > Endpoints > Advanced features
3. Enable Microsoft Intune connection
4. Save

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

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 Intune > Devices > [device] > Endpoint security
• Microsoft Defender for Endpoint shows Onboarded

On-device verification:

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

Status should be Running, StartType should be Automatic.

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)

1. 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.
2. 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).
3. In Intune, Endpoint security → Microsoft Defender for Endpoint, ensure Allow Microsoft Defender for Endpoint to enforce Endpoint Security configurations is turned on.
4. 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.

1. 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.
2. 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).
3. In Intune, Endpoint security → Microsoft Defender for Endpoint, ensure Allow Microsoft Defender for Endpoint to enforce Endpoint Security configurations is turned on.
4. 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.

1. Open the Defender portal and go to Settings → Endpoints → Onboarding.
2. Select the operating system (Windows 10/11).
3. Select deployment method Local script (for up to 10 machines).
4. Click Download onboarding package, a .zip containing WindowsDefenderATPLocalOnboardingScript.cmd.
5. 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.
6. 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").
7. 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.

1. Download the onboarding package as in Path A, but select deployment method Group Policy.
2. The .zip contains WindowsDefenderATPOnboardingScript.cmd and a structured folder. Extract to a domain controller share readable by Domain Computers (e.g., \\dc01\netlogon\MDE\).
3. In Group Policy Management, create or edit a GPO scoped to the target OU (workstations only; do not mix with server OUs).
4. 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.
5. Link the GPO to the workstation OU and force an update: gpupdate /force on a pilot machine.
6. Verify on the device with the same checks as Path A.
7. 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.

1. 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.
2. 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.)
3. Select Create Microsoft Defender ATP Policy and import the .onboarding file from the downloaded package.
4. Configure the policy settings: set Sample sharing to None (CMMC best practice), leave telemetry reporting at default, save the policy.
5. Deploy the policy to a device collection containing the target workstations. Use a pilot collection first before rolling to production collections.
6. Monitor deployment status in Monitoring → Deployments until the policy shows compliant across the pilot collection.
7. Verify on individual devices with the same checks as Path A, and verify fleet-wide appearance in the Defender portal's Device inventory.

1. 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.
2. 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.)
3. Select Create Microsoft Defender ATP Policy and import the .onboarding file from the downloaded package.
4. Configure the policy settings: set Sample sharing to None (recommended for sensitive-data tenants), leave telemetry reporting at default, save the policy.
5. Deploy the policy to a device collection containing the target workstations. Use a pilot collection first before rolling to production collections.
6. Monitor deployment status in Monitoring → Deployments until the policy shows compliant across the pilot collection.
7. 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)

1. Azure portal → Defender for Cloud → Environment settings → [subscription]
2. Enable Defender for Servers Plan 1 or Plan 2 on the subscription
3. For Azure VMs: Defender for Cloud auto-provisions the MDE agent; no manual action needed
4. 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
5. For servers that cannot run Arc: fall back to the local onboarding script from the Defender portal (same as the standalone-SKU path below)

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:

1. Defender portal → Settings → Endpoints → Onboarding
2. Select Windows Server [version] as the operating system
3. Choose deployment method: Local script (ad-hoc / small fleets), Group Policy (domain-joined estates), or Microsoft Endpoint Configuration Manager (existing MECM environments)
4. 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.

---

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

1. In Microsoft Sentinel (Azure Government), navigate to Content hub and install the Microsoft Defender XDR solution
2. Navigate to Data connectors > Microsoft Defender XDR
3. Connect. Sentinel begins ingesting MDE incidents, alerts, and device events into the SecurityIncident, SecurityAlert, and DeviceEvents tables
4. 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.

Commercial

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

GCC High

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

Commercial

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.