Microsoft Intune Endpoint Security and Updates Field Guide

What this guide covers

Intune's Endpoint security node looks fully functional in every state that matters, and that is the problem. You can deploy an antivirus policy, push a BitLocker profile, and onboard devices to Defender for Endpoint, and the admin center will report all of it as configured while noncompliant laptops keep reaching Exchange, encryption never starts, and the Defender connector reads "Enabled" with no device risk signal ever arriving. The gap between "configured" and "enforcing" is where most endpoint security deployments quietly break, and the portal will not tell you which side of that line you are on.

This book is the connected account the documentation scatters across dozens of pages. It explains why endpoint security policies, security baselines, and device configuration profiles collide on the same CSP, why Intune flags a device noncompliant but never blocks it until Conditional Access consumes that signal, and what to check before you trust any of it in production. Every product specific, every license boundary, and every portal path is grounded against current Microsoft Learn and validated in a live Microsoft 365 E5 lab, so the failure modes here are ones I hit and named rather than ones I assumed.

You do not need a production fleet to follow along. A trial tenant and a single test device are enough to reproduce every walkthrough in these chapters.

Chapter map

1. The Endpoint Security Stack, What It Is, Where It Lives, and Why It Matters
2. Licensing, Prerequisites, and Admin Roles
3. Antivirus and the Windows Security Experience
4. Disk Encryption, BitLocker, Personal Data Encryption, and FileVault
5. Firewall Policies and Reusable Settings Groups
6. Attack Surface Reduction, Rules, Device Control, and Exploit Protection
7. Endpoint Detection and Response and Account Protection
8. Security Baselines, Windows, Edge, and Defender for Endpoint
9. Intune and Microsoft Defender for Endpoint Integration
10. Security Copilot in Intune
11. Windows Update Management, Rings, Feature Updates, Quality Updates, and Drivers
12. Windows Autopatch, Mobile Update Management, and Delivery Optimization
13. Before You Go to Production, A Working Admin's Checklist

Appendices: PowerShell and Graph Quick Reference; Build a Lab Tenant; Production Readiness Checklist.

Who it is for

This is for Intune and endpoint security administrators who already run the Endpoint security node and want the moving parts connected rather than listed, for IT pros ramping onto endpoint hardening who need one coherent reference instead of forty Learn tabs, and for MD-102 Endpoint Administrator candidates who want the Protect devices domain understood well enough that a baseline-conflict question is obvious rather than memorized.

See where you are

7 questions from this guide's territory (3 easy, 4 medium), with the explanation after each. Nothing is stored and nothing is sent anywhere.

The rest of Microsoft Intune Field Guides

One product per book, a lab appendix in every one, and a companion page like this one for each.

• 
  Field guide

  Microsoft Intune Windows Autopilot and Deployment Field Guide

  Autopilot never images a device, and the engineers who learn that on a live tenant lose a rollout to it.

  Kindle$12.99Get it on AmazonCompanion page
• 
  Field guide

  Microsoft Intune Application Management Field Guide

  You add the app, it lands in All Apps, and nothing installs.

  Kindle$12.99Get it on AmazonCompanion page
• 
  Field guide

  Microsoft Intune Device Management and Enrollment Field Guide

  Intune deployments fail green, not red: nothing enrolls, every device passes by default, and the admin center reads healthy the whole time.

  Kindle$12.99Get it on AmazonCompanion page

The hard set (5 questions)

The hardest MD-102 questions this guide publishes, none of them repeated from the placement quiz above: the answer first, why every other option is wrong, and the Microsoft Learn page behind it. The practice book for this exam holds the full bank.

Three separate Intune Antivirus (endpoint security) policies each define a different set of Microsoft Defender Antivirus file path exclusions, and all three are assigned to the same device. What is the resulting behavior on that device?

Correct answer: A. The exclusions are combined into a single superset, and all exclusions from the three policies apply.

Defender Antivirus exclusion settings (Excluded Paths, Excluded Processes, Excluded Extensions) support policy merge, so Intune evaluates all applicable policies and combines their exclusions into a single superset delivered to the device. The most-secure / last-modified / none tiebreakers apply only to settings that do not support policy merge.

Why the other options are wrong:

• B. No policy delivered is the outcome for non-mergeable settings that cannot be resolved, not for mergeable exclusions.
• C. Most secure wins is the resolution for non-merge settings, not for mergeable exclusions.
• D. Last modified wins is a tiebreaker for non-merge settings, not for exclusions that merge into a superset.

Memory hook: Exclusions merge into a superset - paths, processes, extensions.

Microsoft Learn: Antivirus

A Windows device managed by Endpoint Privilege Management receives two elevation rules that both match the same executable: a device-targeted rule with elevation type Automatic, and a user-targeted rule with elevation type Deny. When the signed-in user launches the file, what happens?

Correct answer: A. The user-targeted Deny rule wins and the file is blocked from running elevated.

When multiple elevation rules match one application, EPM resolves them so that rules with elevation type Deny always take precedence, and rules deployed to a user take precedence over rules deployed to a device. Both factors point to the Deny rule here, so the elevation is denied.

Why the other options are wrong:

• B. Device rules do not win; user rules take precedence over device rules, and Deny outranks Automatic regardless.
• C. A Deny rule blocks elevation; it does not silently auto-elevate the file.
• D. Reverting to default client behavior is how EPM handles conflicting elevation settings policies, not two rules matching one app.

Memory hook: Deny always wins; user beats device.

Microsoft Learn: Deployment planning

You are building a Conditional Access "Filter for devices" rule that must also apply to devices which were never registered in Microsoft Entra ID (for example, personal, unmanaged machines). Which statement correctly describes how Entra evaluates the filter and how you should write the rule so unregistered devices are included?

Correct answer: C. Entra evaluates filters using device authentication; for unregistered devices all device properties are null, so use a negative operator (for example device.extensionAttribute1 -ne "SAW") so the configured rule still applies.

Microsoft Entra uses device authentication to evaluate filter rules. A device that is unregistered does not exist in the directory, so all of its device properties are treated as null. A positive operator only matches devices that exist and match, so the recommended way to target unregistered devices is a negative operator - the configured filter rule then applies to them.

Why the other options are wrong:

• A. Unregistered devices are not in the directory and have no trustType at all; Workplace denotes Microsoft Entra registered devices.
• B. Filters can target unregistered devices via negative operators; Device state is deprecated and should not be reintroduced.
• D. Entra evaluates device identity from the directory via device authentication, not by reading a TPM; positive operators match only existing directory objects.

Memory hook: Unregistered = null properties; negative operators still bite, positive operators miss.

Microsoft Learn: Concept condition filters for devices

You manage Microsoft Defender Antivirus exclusions exclusively through Intune and want those exclusions to also be protected by tamper protection so a local administrator can't remove them. Besides meeting the minimum Defender platform version and onboarding to Defender for Endpoint, which additional setting must you configure on the devices?

Correct answer: A. Set DisableLocalAdminMerge to true (enabled).

For antivirus exclusions to be tamper-protected, exclusions must be managed in Intune (or Configuration Manager) only, the device must run a supported Defender platform, and DisableLocalAdminMerge must be enabled so local exclusion lists don't merge with the org-managed policy.

Why the other options are wrong:

• B. Tamper protection scope controls which devices receive tamper protection, not whether exclusions are protected from tampering.
• C. AllowLocalPolicyMerge is the opposite intent; allowing local merges defeats exclusion tamper protection.
• D. LSA protection guards credentials in the LSASS process; it has nothing to do with tamper-protecting antivirus exclusions.

Memory hook: Protect exclusions: kill the merge - DisableLocalAdminMerge = true.

Microsoft Learn: Manage tamper protection Intune

Microsoft Entra registered devices (workplace-joined) are present in a tenant alongside Microsoft Entra joined and hybrid joined devices. An administrator wants to use Intune Feature Update policies, Quality Update policies, and Driver Update policies to manage all Windows devices. Which device join type is NOT supported by these update policy types that use the Windows Autopatch backend?

Correct answer: D. Microsoft Entra registered (workplace-joined) devices

Feature Update policies, Quality Update policies, and Driver Update policies in Intune are orchestrated by Windows Autopatch. Microsoft's documentation explicitly states that Microsoft Entra registered devices (workplace-joined, also known as WPJ) are not supported for any policy type that uses the Windows Autopatch backend. For these devices, update management is limited to Windows Update client policies and Update ring policies only.

Why the other options are wrong:

• A. Devices enrolled via Windows Autopilot user-driven mode are typically Microsoft Entra joined or hybrid joined. The join type, not the enrollment method, determines Autopatch eligibility.
• B. Microsoft Entra hybrid joined devices meet the prerequisites for Windows Autopatch-based update policies and are supported for all three update policy types.
• C. Microsoft Entra joined devices are fully supported for Feature Update, Quality Update, and Driver Update policies through the Windows Autopatch backend.

Memory hook: WPJ (registered only, no join) = no Autopatch policies. Joined devices (Entra or hybrid) = full update policy support.

Microsoft Learn: Windows update for business configure