Tamper protection and Intune: why a Defender setting won't change, and how to fix it

Symptoms to confirm

• An Intune antivirus policy reports success, but Get-MpPreference still shows the old value for a protected setting.
• Set-MpPreference, a script or Group Policy appears to change a setting, and Event ID 5013 appears in the Microsoft-Windows-Windows Defender/Operational log.
• The Windows Security app shows the Tamper Protection toggle greyed out, or doesn't show it at all on some server versions.
• Intune reports tamper protection as Not applicable for a device.
• Exclusions you expected to be protected can still be edited locally, or the exclusion list looks empty on the device.
• Tampering alerts appear in the Defender portal after a legitimate maintenance script runs.

Likely causes

Four channels can manage it, with a strict precedence: a policy from Intune or Configuration Manager wins over the tenant-wide portal setting, and either wins over the local Windows Security app.

• When tamper protection is on, these settings are locked to their secure values: virus and threat protection, real-time protection, behavior monitoring, antivirus protection including IOAV, cloud protection, security intelligence updates, automatic remediation of threats, Windows Security notifications, archive scanning, and (under the conditions covered below) exclusions.

• Intune management has its own requirements: the device must be onboarded to Defender for Endpoint (otherwise Intune shows Not applicable), it must be managed by Intune alone (co-managed devices aren't supported for this feature), it needs Windows 10 1709 or later with Defender platform 4.18.1906.3 or later, Intune and Defender must share the same Microsoft Entra tenant, and DisableLocalAdminMerge should be set to true.

Note: Microsoft is previewing controlled configuration, which extends tamper-protection-style enforcement to the whole Defender Antivirus configuration and makes Intune or Defender for Endpoint policy the only source of truth. Where the preview is available, the Intune setting is renamed Controlled Configuration (Device) with the values Off, Tamper Protection (On) and Controlled Configuration (On). The rename alone changes nothing: Tamper Protection (On) behaves as before, and Not configured does not mean Off. The new mode needs platform 4.18.26060.3004 or later and isn't supported for co-managed devices.

Checklist

1. 1

   Find out what is controlling tamper protection on the device

   powershell

   Get-MpComputerStatus |
       Select-Object IsTamperProtected, TamperProtectionSource,
                     RealTimeProtectionEnabled, AMProductVersion

   IsTamperProtected True means it's active; TamperProtectionSource tells you which channel set it. If the source isn't the one you expected, you've found the real problem: a portal toggle or an unexpected policy, not a broken Intune policy.

2. 2

   If the Intune setting won't apply

   • In the Defender portal, confirm the device is onboarded and its sensor is Active. Not onboarded means Not applicable in Intune.
   • In Intune, open Endpoint security › All devices and check Managed by. A co-managed device (MDM/ConfigMgr Agent) isn't supported for Intune-managed tamper protection; use tenant attach for it instead.
   • Check the policy's per-setting status for conflicts. Two Windows Security Experience profiles that disagree, or a profile plus a security baseline, produce a conflict.
   • Confirm AMProductVersion meets the minimum platform version and that cloud-delivered protection is on; the portal-managed path depends on it.
   • Sync the device and allow normal policy latency before judging.
3. 3

   If you need to change a protected setting for a test

   Don't fight tamper protection with scripts; use troubleshooting mode. On the device page in the Defender portal, choose Turn on troubleshooting mode. While it's active, run:

   powershell

   Set-MpPreference -DisableTamperProtection $true
   # make and test your change, for example:
   Set-MpPreference -DisableRealtimeMonitoring $true

4. 4

   If exclusions aren't protected, or look empty

   Exclusion protection has extra conditions: platform 4.18.2211.5 or later, DisableLocalAdminMerge enabled, exclusions managed centrally, and the device managed only by Intune or only by Configuration Manager with the Defender for Endpoint sensor enabled. Check these registry values (read only, don't change them):

   Value	Location	Meaning
   ManagedDefenderProductType = 6	HKLM\SOFTWARE\Microsoft\Windows Defender	Managed only by Intune: requirement met
   ManagedDefenderProductType = 7 and EnrollmentStatus = 4	Same key, plus HKLM\SOFTWARE\Microsoft\SenseCM	Managed by Configuration Manager: requirement met
   ManagedDefenderProductType = 7 and EnrollmentStatus = 3	As above	Co-managed: exclusions aren't protected
   TPExclusions = 1	HKLM\SOFTWARE\Microsoft\Windows Defender\Features	Exclusions are tamper protected (0 means they aren't)

Verify

• Get-MpComputerStatus shows IsTamperProtected True and the expected TamperProtectionSource.
• The Windows Security app shows the toggle on and locked (except on Windows Server 2012 R2, 2016 and 2019 and older Windows 10 builds, where it isn't displayed).
• Intune's policy report shows Succeeded for Tamper protection (device).
• A test change with Set-MpPreference outside troubleshooting mode produces Event ID 5013 and no change.
• Advanced hunting shows your maintenance window as tampering attempts, which is exactly what you want to see for anything that isn't your policy:

DeviceEvents
| where Timestamp > ago(7d)
| where ActionType == "TamperingAttempt"
| project Timestamp, DeviceName, InitiatingProcessFileName,
          InitiatingProcessAccountName, AdditionalFields
| order by Timestamp desc

Key takeaways

• Pick one channel. Intune policy beats the portal toggle, so if you use Intune, make it the single source and keep the tenant-wide toggle as the safety net for devices Intune doesn't manage.
• Deploy DisableLocalAdminMerge and centrally managed exclusions so the exclusion lists get protected too.
• Expect "succeeded but not applied" whenever anything other than your policy touches a protected setting; Event 5013 is the tell.
• Defender Vulnerability Management flags devices where tamper protection is off; search the recommendations for tamper.
• Watch for the controlled configuration rename in your Windows Security Experience profiles so a preview change doesn't surprise your pilot ring.