Defender for Endpoint and the Endpoint Security baseline

Microsoft Defender for Endpoint (MDE) is the EDR (Endpoint Detection and Response) platform for Intune-managed devices and the foundation of the SOC-side compliance evidence chain — alert monitoring (3.14.3), malicious-code protection (3.14.2), system monitoring (3.14.6). MDE is one part of a broader Endpoint Security baseline in Intune. The same Intune blade (Endpoint security) also configures volume encryption (BitLocker), phishing-resistant authentication (Windows Hello for Business), local-admin posture (LAPS, Local Administrators), boundary protection (Windows Firewall), exploit mitigation, and removable-media control — none of which are Defender features per se, but all of which co-locate with MDE in the same admin surface and ship as one OIB baseline.

This chapter covers both: MDE specifically (onboarding paths, custom-detection rules, Sentinel integration) and the 12 Layer 1 policies that make up the OIB Endpoint Security baseline.

Scope of this chapter

The 12 Layer 1 policies covered here are 9 OIB-shipped (ASR, Defender Antivirus AV Configuration, Defender Antivirus Security Experience, BitLocker, Local Administrators, Windows Firewall, WHfB Configuration, Cloud Kerberos Trust, LAPS) plus 3 manually authored (EDR Onboarding, Exploit Protection, Device Control / Removable Media). Four are Defender for Endpoint features specifically (ASR, AV Configuration, Security Experience, EDR Onboarding); the rest configure other Windows endpoint subsystems. Eleven of the twelve live under Intune's Endpoint security blade — Cloud Kerberos Trust is the exception, a Settings Catalog policy that pairs with WHfB Configuration to enable hybrid Entra-to-AD trust (skip for cloud-only tenants).

The full 21-policy Layer 1 baseline — which adds Audit and Event Logging, Local Security Policies, Login and Lock Screen, Power and Device Lock, Reports and Telemetry, and the four OIB Compliance policies — is documented in Open Intune Baseline Deployment § Layered Deployment Strategy. The three Defender Antivirus Update Ring policies (Pilot/UAT/Production) belong to Layer 2 — see the note in the workstation ES section below.

GCC High

CMMC Relevance

CMMC Practice	NIST 800-171 Rev. 2 Control	How MDE Satisfies It
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.7 (Identify unauthorized use)	MDE behavioral analytics and anomaly detection surface unexpected process execution, lateral movement, and data exfiltration patterns
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.4 (Malicious code updates)	MDE platform and signature updates are managed by Microsoft — no separate update infrastructure required

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.

---

Management Models: Intune MDM vs. MDE Security Settings Management

Not every device that needs endpoint protection will be fully enrolled in Intune. Workstations in isolated environments, servers, and machines belonging to users without M365 licenses are common examples. MDE provides a second management path — Security Settings Management — that allows these devices to receive Endpoint Security policies from Intune without full MDM enrollment.

Compared to Intune-managed devices, three things are narrower for MDE-managed:

• Policy scope — Endpoint Security only (Antivirus, Firewall, ASR, EDR). No Configuration profiles, Compliance policies, App deployments, or Platform Scripts.
• Targeting must use device groups — user-group assignments are silently ignored. No error, no policy tip; the policy simply does not apply.
• Identity surface — appears in Intune as Managed by: MDE with a synthetic Entra registration created automatically by MDE (Join Type is blank).

MDE-attached devices silently ignore user-group assignments

If you assign an Endpoint Security policy to a user group, Intune-managed devices receive it normally but MDE-attached devices receive nothing — no error, no alert, no policy tip. The policy simply does not apply. Always use device security groups when targeting MDE-attached machines, and build the targeting around device groups from the start so a single OIB Endpoint Security policy can reach 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 P1 plus infrastructure-security features	Same as P1	≈$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.

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. Once Sentinel ingestion of server security telemetry is in the picture, the benefit recovers the P2 license premium several times over and P2 becomes the cheapest option, not the most expensive. 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.

Onboarding paths

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

Policy architecture

One Endpoint Security policy set is authored for all workstations — Intune-managed and MDE-managed alike — because the settings are identical for both populations. What differs is the delivery channel: the MDE security-settings-management channel enforces only a subset of endpoint security profile types (callout below). MDE-managed workstations that need the unsupported profiles to satisfy CMMC can either move to full Intune MDM enrollment or get those controls via GPO; MDE-managed servers must use GPO — Windows Server isn't a supported Intune MDM enrollment target (GPO fallback for MDE-only fleets at the end of this section). Most of the workstation policies also work on servers as-is; the ones that need a dedicated Svr - variant are AV Configuration (different exclusions for SQL, IIS, Exchange, AD DS NTDS/SYSVOL paths), Local Administrators (different membership: Tier 1 server admins, not the workstation primary user), and Firewall Rules (servers must allow inbound on service ports rather than blocking all inbound).

MDE-channel delivery is a subset of Intune endpoint security

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

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

The following Intune endpoint security profiles assign successfully to MDE-managed devices but do not enforce — they need a GPO on those devices to satisfy CMMC. (Workstations can alternatively be brought into full Intune MDM enrollment, which unlocks all four; Windows Server isn't a supported Intune MDM target, so GPO is the answer for MDE-managed servers — details in GPO fallback for MDE-only fleets.) Affected policies are marked below with ⚠ MDE-only: GPO fallback.

• Account Protection → Windows LAPS — Win - OIB - ES - Windows LAPS - D - LAPS Configuration
• Account Protection → Local user group membership — Win - OIB - ES - Local Group Membership - D - Local Administrators and its Svr - variant
• Attack Surface Reduction → Exploit Protection — Win - Custom - ES - Exploit Protection
• Attack Surface Reduction → Device Control — Win - Custom - ES - Device Control / Removable Media. Note 1 to the Microsoft Windows table: "This profile is visible in the Defender portal but isn't supported for devices managed only by Microsoft Defender through the Microsoft Defender security settings management scenario."

Assignment filters are also ignored on MDE-channel devices — "Assignment filters aren't supported for devices communicating through the Microsoft Defender for Endpoint channel." Use Microsoft Entra device groups (e.g., a dedicated MDE Servers group) to scope assignments rather than filters when targeting MDE-managed populations.

GPO alternatives for each unsupported profile are at GPO fallback for MDE-only fleets at the end of this section.

Workstation Endpoint Security set

The workstation set has two parts: 9 OIB-shipped policies that import as Settings Catalog JSON (8 surface under Endpoint Security; Cloud Kerberos Trust surfaces under Settings Catalog and pairs with WHfB Configuration), and 3 manual creations that must be authored once per tenant (the EDR onboarding blob is tenant-specific; Exploit Protection and Device Control are tenant-customized policies — Exploit Protection enforces process mitigations and the override lockdown, Device Control is keyed to your approved hardware IDs — and neither ships pre-packaged in OIB).

9 OIB Settings Catalog imports. Already in your tenant if you've completed the OIB import process — see Open Intune Baseline Deployment for the step-by-step. Assign these to the Workstations-ES device group, which contains both Intune-managed and MDE-managed workstations:

1. Win - OIB - ES - Attack Surface Reduction - D - ASR Rules (L2)
2. Win - OIB - ES - Defender Antivirus - D - AV Configuration
3. Win - OIB - ES - Defender Antivirus - D - Security Experience
4. Win - OIB - ES - Encryption - D - BitLocker (OS Disk)
5. Win - OIB - ES - Local Group Membership - D - Local Administrators — ⚠ MDE-only: GPO fallback (Account Protection profile; not enforced via MDE channel)
6. Win - OIB - ES - Windows Firewall - D - Firewall Configuration
7. Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration
8. Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust (skip for cloud-only tenants)
9. Win - OIB - ES - Windows LAPS - D - LAPS Configuration — ⚠ MDE-only: GPO fallback (Account Protection profile; not enforced via MDE channel)

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, Ring 2 - UAT, and Ring 3 - Production — 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.

3 manual creations. Not in the OIB Settings Catalog import — author once per tenant:

Policy	Why manual	Where documented
Win - Custom - ES - Defender for Endpoint Onboarding	Onboarding blob is tenant-specific; cannot be pre-packaged in OIB JSON	Step 2: Create an Endpoint Detection & Response Policy below; Appendix B § Defender for Endpoint
Win - Custom - ES - Exploit Protection ⚠ MDE-only: GPO fallback	Settings Catalog policy enforcing DEP, ASLR, SEHOP, CFG plus DisallowExploitProtectionOverride for tamper protection; OIB does not pre-package it. The Exploit Protection profile under ASR does not flow via the MDE channel — MDE-managed devices need a GPO (GPO fallback).	Appendix B § Exploit Protection
Win - Custom - ES - Device Control / Removable Media ⚠ MDE-only: GPO fallback	Device Control rules are keyed to approved hardware IDs unique to each tenant; OIB cannot pre-package the per-drive identifiers. The Device Control profile assigns to MDE-managed devices without error but does not enforce (Microsoft Note 1) — MDE-managed devices need a GPO (GPO fallback).	Appendix B § Removable Media

Server Endpoint Security set — new policies to create

These three policies do not ship in OIB and must be created. Build each one from the corresponding workstation policy as a starting point, then tune for server workloads. Assign the new server policies to the Servers-ES device group:

Server policy (new)	Server-specific tuning
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.
Svr - OIB - ES - Local Group Membership - D - Local Administrators ⚠ MDE-only: GPO fallback	Membership differs from the workstation version — Tier 1 server admins (and any role-specific service accounts that legitimately need local admin), not the workstation's primary user. Satisfies CMMC 3.1.5 Least Privilege on the server tier. Account Protection does not flow via the MDE channel — for MDE-only servers, use GPO Restricted Groups (GPO fallback).
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.

Six of the workstation policies cover servers without forking — assign each to Servers-ES as a second target rather than authoring Svr - variants:

• Win - OIB - ES - Windows LAPS - D - LAPS Configuration — manages the built-in Administrator account uniformly on workstations and member servers. Exclude domain controllers from the assignment (DCs manage their own admin accounts via AD, not LAPS). ⚠ MDE-only servers/workstations: Account Protection does not flow via the MDE channel — use native Windows LAPS via GPO (GPO fallback).
• Win - OIB - ES - Defender Antivirus - D - Security Experience — Tamper Protection enabled is the only load-bearing setting; the UI-hiding settings are no-ops on headless Server Core but harmless on Server with Desktop Experience.
• Win - OIB - ES - Attack Surface Reduction - D - ASR Rules — server-safe in practice. Office-trigger rules (block Office child processes, block macro injection, block JavaScript/VBScript from launching downloaded content, etc.) become silent no-ops on servers without Office or email clients; credential-stealing and persistence rules (block PSExec/WMI process creation, block credential stealing from LSASS, block persistence through WMI subscription) apply equally to both fleets.
• Win - Custom - ES - Defender for Endpoint Onboarding — the EDR onboarding blob is tenant-specific, not fleet-specific. Assignment-only difference. (For MDE-Attached servers that aren't Intune-managed, onboarding flows through Defender for Cloud instead — see Onboarding MDE-Attached Servers.)
• Win - Custom - ES - Exploit Protection — server-safe on modern Microsoft server roles. ⚠ MDE-only servers/workstations: the Exploit Protection profile does not flow via the MDE channel — apply mitigations via GPO or PowerShell Set-ProcessMitigation (GPO fallback).
• Win - Custom - ES - Device Control / Removable Media — applies on branch-office, retail, and industrial-floor servers; skip on datacenter racks (no physical access). ⚠ MDE-only servers/workstations: the Device Control profile assigns without error but does not enforce — apply via GPO (GPO fallback).

Fork to a separate Svr - variant only when you've identified a concrete tuning need:

• legacy line-of-business binary that breaks under mandatory ASLR (Exploit Protection)
• distinct approved-drive list or ops group for server maintenance USBs, or separate Defender custom-detection rules for server alerting (Device Control)
• 24H2+ Server SKU where you want Automatic Account Management and built-in Administrator disable behavior of the (24H2+) LAPS+LSP pair (LAPS)
• audit-only rollout of selected ASR rules on servers for change-management caution, or an allow-list for a server workload that conflicts with a specific rule (ASR Rules)
• Tamper Protection or notification posture that should be different on servers vs. workstations (Security Experience — rare)

Forks are mechanical when the time comes — copy the workstation policy, retarget the assignment, change the differing settings.

Optionally, depending on your server estate:

Optional server policy	When to create it
Svr - OIB - ES - Encryption - D - BitLocker	Physical servers only. Azure VMs are encrypted at the platform layer (Azure Storage Service Encryption plus optional Azure Disk Encryption); a duplicate BitLocker policy is redundant in cloud-only deployments. Server BitLocker content also differs from workstation: TPM-only protector (no startup PIN, so unattended reboots work) and Fixed Data Drive encryption for any data volumes hosting CUI.

The non-ES OIB policies (Configuration, Compliance, Apps, Scripts) keep their existing assignments and are naturally scoped to Intune-managed devices — MDE-managed devices cannot accept these policy types regardless of how they're targeted.

GPO fallback for MDE-only fleets

The four Intune endpoint security profiles that don't flow over the MDE channel (LAPS, Local Group Membership, Exploit Protection, Device Control) still need to be applied on MDE-managed workstations and servers to keep your CMMC 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 all four profiles 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 four profiles. Windows Server is not a supported Intune MDM enrollment target — 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, ASR Rules, EDR, and Windows Security experience to ConfigMgr-managed servers per the supported-profiles table — but not LAPS, Local Group Membership, Exploit Protection, or Device Control either). 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 — apply 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.

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.

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.

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

Convergence point (all paths)

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

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

At that point, add the device to the Workstations-ES 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-ES 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. Defender for Cloud handles onboarding and server-specific security features. The Defender portal handles alert triage and investigation. Intune handles policy delivery via Security Settings Management.

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.

---

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 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

• 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.

---

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)) 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. Has a known OAuth compatibility impact in thick-client Outlook; see the note below
Block Office communication application from creating child processes	Warn	Affects Outlook OAuth flows and Teams integrations. OIB ships at Warn — the user can override once — rather than Block, to surface impacted workflows during the validation period before committing to full enforcement
Block executable files by prevalence, age, or trusted list	Audit	High false positive rate for custom or legacy line-of-business applications. Validate thoroughly before promoting to Warn or Block
Block rebooting machine in Safe Mode	Audit	Administrators legitimately use Safe Mode for recovery and troubleshooting. Evaluate operational impact before promoting
Enable Controlled Folder Access	Audit Mode	Protects Documents, Desktop, and other common folders from unauthorized writes — effective ransomware mitigation. Ships at Audit because many legitimate applications write to protected folders. Identify and exclude affected apps 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 enables MDE to remediate detections even when a third-party antivirus product is the primary AV. For environments running only MDE as the AV (the typical Intune-managed posture), this provides an additional remediation layer for post-breach detections.

• In the Endpoint detection and response policy (Step 2 above), set:
  • EDR in block mode: Enabled

---

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.

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.7 — 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.