Microsoft MD-102: Endpoint Security and Microsoft Defender — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #md-102 #certification #exam-prep #study-guide

Part of the Microsoft Endpoint Administrator Associate MD-102 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Endpoint security on Windows with Microsoft Intune centers on Microsoft Defender technologies that work together: Defender Antivirus for malware prevention, Defender Firewall for host-based network control, Attack Surface Reduction (ASR) rules and Controlled Folder Access to stop common exploit and ransomware techniques, and Microsoft Defender for Endpoint (MDE) for enterprise threat detection and response. Intune provides policy authoring, assignment, and reporting for these capabilities, plus native controls for BitLocker disk encryption and Windows Hello for Business (WHfB) to protect data and identities. This section explains how to configure these layers end to end, with precise guidance for onboarding, policy design, and operational best practices.

Microsoft Defender Antivirus, Attack Surface Reduction, and Controlled Folder Access

Defender Antivirus is the baseline antimalware engine. In Intune, use Endpoint security > Antivirus (for Windows 10 and later) to configure:

Real-time protection: Keep real-time protection, behavior monitoring, and cloud-delivered protection enabled. Cloud protection with automatic sample submission increases detection speed and coverage. Use the MAPS/Cloud Protection level setting to “High” for the fastest block decisions.
Exclusions: Add only targeted exclusions after validating a false positive or demonstrable performance impact. Supported exclusion types are file/folder paths, file extensions, and processes. Prefer process-level exclusions for trusted updaters to prevent bypassing detections on dropped payloads. Avoid broad extensions (for example, excluding .log recursively) and network shares unless absolutely necessary; audit first, then narrow the scope.
Scan schedules: Configure a daily quick scan during off-peak hours and a weekly full scan. Enable “Catch-up scans” to run missed scans. Limit scan CPU load if needed and enable scanning of archive and email files consistent with performance capacity. Quick scans should complement, not replace, full scans.

Attack Surface Reduction rules prevent common attacker actions even if malware is unknown:

Modes: Each rule supports Block, Audit, or Not configured. Start in Audit to discover legitimate hits, review events in Microsoft Defender XDR (Advanced Hunting: DeviceEvents with ActionType “Asr” or “AsrExecution”), then move select rules to Block. Some rules also support Warn; when available, use Warn temporarily to reduce disruption while moving to Block.
Core rules to prioritize: Block Office creating child processes, block Office from injecting into other processes, block executable content from email/webmail, block credential stealing from LSASS, block process creations originating from PSExec/WMI, and block persistence via WMI event subscription.
Exclusions: Use ASR-only exclusions where necessary (file, folder, or process). Do not rely on Defender AV exclusions for ASR; configure rule-specific or ASR-wide exclusions in the Intune Attack surface reduction policy. Keep exclusions narrow and review them regularly.

Controlled Folder Access (CFA) mitigates ransomware by restricting untrusted process writes to protected folders:

States: Off, Audit, or Block (Enabled). Use Audit to baseline, then switch to Block when noise is under control.
Protected folders: System libraries (Documents, Pictures, Desktop, etc.) are protected by default; add line-of-business data paths. Avoid protecting high-churn temp or cache folders to minimize false positives.
Allowed apps: Define allowed apps explicitly by full path for trusted updaters and line-of-business applications that legitimately write to protected folders. Keep this list minimal; prefer publisher consistency in app packaging to avoid path drift.
Monitoring: Review CFA blocks in Defender portal and Intune reports to fine-tune the allow list.

Microsoft Defender Firewall: Profiles and Rules

Defender Firewall is a stateful host firewall with three profiles—Domain, Private, and Public—selected by network location awareness:

Profiles: Domain applies when the device authenticates to a domain controller; Private is for trusted, user-designated networks; Public is the default for untrusted networks. Keep all three profiles enabled and configured; devices roam.
Baseline posture: Block inbound by default. Allow only required inbound services via explicit rules (by program, service, port/protocol, and interface type). Outbound can be allow-by-default with targeted block rules, or move toward allow-listing outbound for high-security segments.
Intune policy: Use Endpoint security > Firewall to configure profile-level settings (on/off, inbound/outbound default, logging, stealth mode, notifications) and to deploy inbound/outbound rules. Disable local rule merging where you must enforce a strict policy; otherwise enable merging to allow troubleshooting tools during transition phases.
Rule hygiene: Anchor rules by program file path or service SID instead of raw ports when possible. Scope rules to specific remote IPs/subnets, and disable edge traversal unless required. Use separate rules per profile for least privilege. Log dropped packets and successful connections to aid incident response and tuning.

Microsoft Defender for Endpoint onboarding and EDR integration with Intune

Onboarding Windows 10/11 devices to MDE is streamlined with Intune:

Connector: In Intune admin center, enable the Microsoft Defender for Endpoint connector. This integration allows compliance based on device risk, exposes security tasks, and enables security settings management.
Policy: Create Endpoint security > Endpoint detection and response (EDR) policy for Windows 10 and later. Enable the sensor, set telemetry/sample submission as required, and assign to Azure AD device groups. This onboard action registers the device with MDE and begins telemetry streaming to Defender XDR.
EDR in block mode: Enable EDR in block mode via Endpoint security > Antivirus for devices that use a non-Microsoft primary AV (or even with Defender active to harden post-breach). Block mode stops malicious artifacts discovered by EDR even after initial compromise.
Integration points:
- Compliance and Conditional Access: Create a device compliance policy that requires an MDE device risk level of “Clear or Low.” Pair with Conditional Access to block at-risk devices from cloud resources.
- Attack surface policies: Configure ASR, Network Protection, and CFA from Intune under Endpoint security > Attack surface reduction. If you use MDE Security settings management, ensure precedence and avoid conflicting policies.
- Response: From Defender XDR, initiate live response, isolation, investigation, and remediation. Intune and MDE share device identity for coordinated actions such as quarantine release and policy verification.

For macOS, deploy Microsoft Defender for Endpoint using Intune configuration profiles and app deployment (PKG installation), then apply Defender settings via preference profiles or the MDE settings catalog. For Linux and mobile platforms, follow platform-specific onboarding scripts or app-based enrollment, managed by Intune where supported.

Disk and Identity Protections: BitLocker and Windows Hello for Business

BitLocker with Intune protects data at rest without user friction:

Silent enablement: Use Endpoint security > Disk encryption > BitLocker. Require OS drive encryption with TPM-only startup to avoid pre-boot prompts, set XTS-AES (128 or 256) per your standard, hide third‑party encryption warnings, and enable silent encryption for fixed data drives if required. Devices must meet hardware/firmware prerequisites (TPM, modern BIOS/UEFI). Assign to Azure AD–joined devices early in lifecycle (for example, via Autopilot) so encryption starts immediately.
Key escrow: Configure backup of recovery keys to Azure AD. Verify escrow by checking the device object in Entra ID (Azure AD) or the user’s “My Account” portal for self-service key retrieval. Use Intune remote action “Rotate BitLocker keys” after key disclosure or suspected compromise. For removable drives, enforce BitLocker To Go with recovery password policies.
Operations: Monitor encryption and compliance posture in Intune reports. Avoid enabling pre-boot PIN for silent scenarios; if a startup PIN is required by policy, communicate and stage user interaction during enrollment.

Windows Hello for Business replaces passwords with asymmetric keys or certificates bound to the device, backed by PIN or biometrics:

Deployment control: Configure tenant-wide enablement under Windows enrollment > Windows Hello for Business and fine-grained settings via a device configuration profile (Identity protection) or security baseline. Enforce use of biometrics where hardware supports it and require TPM.
Trust models:
- Cloud Kerberos trust: Recommended for hybrid scenarios needing on-premises Kerberos SSO without PKI. It uses Azure AD as the trust anchor to issue Kerberos tickets for on-prem resources. Requires supported Windows versions and domain controllers configured for Azure AD Kerberos. Minimal infrastructure, fastest rollout.
- Certificate trust: Uses user or device authentication certificates from an enterprise CA (on-prem AD CS or cloud-issued) to enable SSO. Requires PKI and certificate deployment (typically via Intune SCEP/PKCS) and is preferred when smart card equivalence and certificate-based access controls are mandatory.
PIN complexity: Configure minimum/maximum length, history, expiration, and enhanced complexity (alphanumeric and special characters). Unlike passwords, the WHfB PIN is local to the device and backed by TPM anti-hammering, so shorter PINs can remain resilient; still meet organizational policy and regulatory requirements.

Practical Problem Scenario

Starbucks must harden 15,000 Windows 11 endpoints across stores and corporate offices against ransomware, enable passwordless sign-in, and gain enterprise-grade detection and response while minimizing user disruption during rollout.

Connect Intune to Microsoft Defender for Endpoint

Action: In Intune, enable the Microsoft Defender for Endpoint connector and turn on device risk integration.
Why: Establishes unified device identity, allows compliance based on MDE risk, and enables security settings management, reducing configuration sprawl.

Onboard devices to MDE with an EDR policy

Action: Create Endpoint security > Endpoint detection and response policy, enable the sensor, sample sharing, and set high telemetry frequency for pilot groups, then broad assignment.
Why: Starts telemetry and advanced detection quickly without packaging scripts; aligns with Intune role-based assignment.

Establish antivirus baselines and EDR in block mode

Action: Create Endpoint security > Antivirus policy with real-time protection, cloud protection High, daily quick/weekly full scans, targeted exclusions, and enable EDR in block mode.
Why: Defender AV and EDR cooperate to prevent and contain threats; cloud protection accelerates zero-day blocks; exclusions remain minimal to prevent coverage gaps.

Implement Attack Surface Reduction and Controlled Folder Access

Action: Deploy Attack surface reduction policy in Audit for two weeks (key ASR rules and CFA Audit), review hits in Defender XDR, then switch critical rules and CFA to Block while adding precise ASR and CFA allow entries as needed.
Why: Audit-first reduces business disruption; Block mode closes common ransomware and living‑off‑the‑land techniques that evade traditional AV.

Lock down host firewall with profile-aware rules

Action: Use Endpoint security > Firewall to enable all profiles, block inbound by default, deploy role-based inbound rules (program/service-scoped), restrict outbound for payment systems, and disable local rule merge for high-risk groups.
Why: Reduces lateral movement and narrows attack paths across public Wi‑Fi and in-store networks; prevents local overrides where risk is highest.

Enable silent BitLocker with Azure AD key escrow

Action: Deploy Endpoint security > Disk encryption with TPM-only OS drive encryption, XTS-AES 256, silent fixed drive encryption, and mandatory Azure AD key backup; add a helpdesk runbook to rotate keys from Intune after retrieval.
Why: Achieves at-rest protection without user prompts; ensures recoverability and supports self-service key access for field staff.

Roll out Windows Hello for Business (cloud Kerberos trust)

Action: Enable WHfB tenant-wide, configure Identity protection profile for PIN complexity and biometrics, and deploy Cloud Kerberos trust for hybrid SSO; reserve certificate trust only for teams requiring smart card equivalence.
Why: Eliminates passwords at scale, delivers seamless SSO to on-prem resources without PKI complexity, and meets compliance for sensitive roles when certificate trust is required.

Enforce access with Conditional Access based on device risk

Action: Create a compliance policy requiring MDE device risk “Clear or Low,” and a Conditional Access policy enforcing that requirement for Microsoft 365 and payment back-end portals.
Why: Automatically contains compromised or at-risk devices, aligning security posture with access to critical services.

Operationalize with reporting and response

Action: Use Intune device compliance and encryption reports, Defender XDR alerts, and Advanced Hunting for ASR/CFA telemetry; define playbooks for isolation, investigation, and remediation.
Why: Maintains continuous visibility and rapid response, closing the loop between prevention, detection, and governance.

← Application Management and Deployment · All domains · Identity →

Practice these questions → · Timed practice on ExamRoll.io →