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

Tamper protection is the Defender feature that stops anyone, including a local admin or a piece of ransomware, from switching off real-time protection. It's also the feature most often blamed when an Intune antivirus setting refuses to apply, or when a change made with PowerShell seems to succeed and then quietly doesn't. In this post I'll cover what it protects, the ways it's managed, how to see what is actually controlling it on a device, and how to fix the usual "the setting won't apply" complaints.

Symptoms#

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

Why it happens#

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. Attempts to change them through the registry are blocked, and changes from any management tool, including Group Policy, can look successful while being silently rejected. The protection keeps working even when Defender Antivirus runs in passive mode.

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.

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.

How to fix it#

1. Find out what is controlling tamper protection on the device#

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. If the Intune setting won't apply#

1. In the Defender portal, confirm the device is onboarded and its sensor is Active. Not onboarded means Not applicable in Intune.
2. 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.
3. 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.
4. Confirm AMProductVersion meets the minimum platform version and that cloud-delivered protection is on; the portal-managed path depends on it.
5. Sync the device and allow normal policy latency before judging.

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. It can take up to 15 minutes to start, lasts four hours, is limited to eight hours per device per 24 hours, and the device must be online. While it's active, run:

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

When troubleshooting mode expires, every policy-managed setting reverts. For a permanent change, change the policy or exclude the device from the tamper protection assignment instead.

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

If Get-MpPreference shows no exclusions at all, that's usually not tamper protection but the antivirus policy option that hides exclusions from local admins; check the policy before assuming the exclusions were lost. New exclusion policy from Intune or Configuration Manager still applies while exclusions are protected; you don't need to disable anything.

Verify the fix#

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

References#

• Tamper protection overview
• Configure tamper protection for Microsoft Defender Antivirus on Windows
• Troubleshoot problems with tamper protection