Defender for Endpoint

Microsoft Defender for Endpoint (MDE) is the EDR (Endpoint Detection and Response) platform for Intune-managed devices. MDE is the recommended EDR for all Intune environments — it directly satisfies several security and compliance practices that have no practical alternative in the Microsoft stack.

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.

---

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 — no manual package download
Sample sharing	All samples	Required for automated investigation to submit files to cloud analysis
Telemetry reporting frequency	Expedited	Faster alert generation; acceptable performance impact on modern hardware

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