In most tenants I review, Defender tamper protection has stopped being optional. I treat it as a baseline requirement. When Microsoft Defender for Endpoint and Defender Antivirus are in use, I want to be sure that neither local admins nor attackers with elevated rights can just switch off real-time protection or cloud scanning, or slip in exclusions of their own. In environments without tamper protection, I still come across attacks that began with antivirus being quietly disabled, which leaves the way clear for ransomware and other threats.

Defender tamper protection locks core antivirus settings against local changes

This is exactly the scenario tamper protection is built to prevent. Once it's on, local admins and attackers can no longer disable the core Defender Antivirus features, no matter whether they try through the registry, PowerShell, Group Policy or the GUI. Real-time protection, cloud protection, IOAV and, if configured correctly, exclusions are all locked. Changes have to come from central tools instead, meaning Intune endpoint security policies or the Microsoft Defender portal. Microsoft's tamper protection documentation explains the details well.

One misconception comes up a lot. Tamper protection doesn't replace proper admin rights management or good detection. It's an additional layer, and an important one. In real incidents and in red-team tests I've seen "turn off Defender" as the attacker's first step more than once. Without tamper protection, that step is far too easy.

Tamper protection can be enabled tenant-wide or per device group

The simplest option is to turn tamper protection on for every managed device in the tenant. In the Defender portal, go to Settings → Endpoints → Advanced features and enable tamper protection for the whole organization. This works in hybrid setups as well as cloud-only ones. If you want finer control, use Intune instead: under Endpoint security → Antivirus → Create policy → Windows Security experience, configure tamper protection and assign the policy to device groups. Microsoft's guide to managing it with Intune walks through this step by step.

Exclusions are a special case you need to pay attention to. They're only protected on Intune-managed devices where "DisableLocalAdminMerge" is set in the AV policy. On every other device, a local admin can still add custom exclusions, and attackers like to abuse exactly that. I find this gap in audits far more often than I'd like.

# PowerShell: Check tamper protection status locally
Get-MpComputerStatus | Select-Object IsTamperProtected

You can run this in any local PowerShell window, as a standard user or as admin, to see whether tamper protection is currently on. It works on Windows 10/11 endpoints running Defender.

Troubleshooting mode allows controlled changes on single devices

Sometimes I have a legitimate reason to change Defender settings on a device, for example during an urgent troubleshooting case. For that, there's troubleshooting mode. From the Defender portal you can put a device into a temporary state in which tamper protection is relaxed for a fixed time window. Every change is logged, so it stays a controlled and short-lived exception. The troubleshooting mode documentation describes how to turn it on and monitor it. I only use it when there's no other way, and I always keep track of which devices are in this mode.

Pro tip: Once the issue is fixed, check that tamper protection is actually back on. "Get-MpComputerStatus" on the device or the device inventory in the Defender portal gives you a quick answer.

The same few pitfalls show up in almost every audit

These are the problems I run into most often:

  • Tamper protection is on tenant-wide, but exclusions aren't covered (the Intune configuration is missing)
  • Devices aren't managed by Intune, so exclusions can still be set locally
  • Old GPOs or scripts keep trying to set Defender settings (they fail silently but cause confusion)
  • Troubleshooting mode was turned on and then forgotten
  • Nobody monitors the status centrally, so problems go unnoticed

If your devices are managed partly on-prem and partly from the cloud, check regularly that tamper protection, device status and exclusion management are consistent. If something looks off, compare your Intune and Defender device inventories.

Disabling Defender is still an attacker's favorite move

The reason I push tamper protection so hard comes from breach investigations and simulation exercises. Defense evasion is nearly always the opening move. As soon as attackers have local admin rights, they often go straight for disabling Defender or crippling it with exclusions. Without tamper protection, they rarely have to work hard for it. Legacy GPOs or scripts that still try to change settings only add to the confusion. My recommendation is to turn tamper protection on wherever you can and to automate the status monitoring.

The flowchart below shows how Defender tamper protection interacts with central management and troubleshooting mode:

flowchart TD
    User["Local admin"] -->|"Attempts change"| Defender["Defender settings"]
    Defender -->|"Tamper protection on?"| Check["Active: change blocked"]
    Defender -->|"Troubleshooting mode on?"| TempChange["Temporary change allowed"]
    TempChange -->|"After expiry: protection on"| Check
    Check -->|"Status monitoring"| Portal["Defender portal/Intune"]

Figure: Tamper protection blocks local changes and only allows temporary exceptions through troubleshooting mode.

Tamper protection belongs on every device in 2024

I can't think of a good reason to leave Defender tamper protection turned off in 2024. If you run Windows 10/11 with Defender Antivirus and use Intune, the prerequisites are already in place, and local tampering is a real risk. Leaving it off means accepting that risk for nothing. Set aside some time to review your environment and close whatever gaps you find. For more on privileged access and secure device management, have a look at Windows LAPS Intune: Local admin secrets under control or Endpoint Privilege Management: removing local admin rights.