Microsoft Defender Tamper Protection: How to Prevent Attackers from Disabling Your Endpoint Security
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Disabling Windows Defender is step one in the playbook of every commodity ransomware family and many advanced threat groups. The commands are well-documented and take seconds: Set-MpPreference -DisableRealtimeMonitoring $true, or a registry write to HKLM\SOFTWARE\Policies\Microsoft\Windows Defender. Without Tamper Protection, any process running with local admin rights can execute these commands successfully. With Tamper Protection enforced via Intune, those commands are blocked and logged. Deploying Tamper Protection is a one-hour task that eliminates this attack vector.
Enable via Intune for Managed Devices
For Intune-managed Windows 10/11 devices: In the Intune admin center (intune.microsoft.com), navigate to Endpoint Security > Antivirus > Create Policy. Platform: Windows 10/11 and later. Profile: Windows Security Experience. In the settings, find 'Tamper Protection' and set to 'Enabled'. Assign the policy to All Devices or a specific device group. Tamper Protection with Intune creates a management binding: Defender settings can only be changed from Intune, not from local admin commands. This is the most robust form of Tamper Protection -- even a Domain Admin cannot disable real-time protection on a Tamper Protected, Intune-managed device by running Set-MpPreference locally. Alternatively, use Endpoint Security > Antivirus > Windows Defender Antivirus policy and configure 'Turn on tamper protection' in the settings catalog. Check the device's Windows Security Center after policy application: Windows Security > Virus and Threat Protection > Manage Settings should show Tamper Protection toggle as ON and grayed out (non-clickable by local users).
Enable via Defender for Endpoint Portal (MDE Tenants)
For organizations with Microsoft Defender for Endpoint (MDE) P1 or P2 licenses, Tamper Protection can be enabled tenant-wide from the Defender portal: security.microsoft.com > Settings > Endpoints > Advanced Features > Tamper Protection = On. This enables Tamper Protection on all MDE-onboarded devices simultaneously. The MDE-level setting applies the same protections as Intune but is managed from the Defender portal rather than Intune. If you use both Intune and MDE, the Intune policy takes precedence for Intune-enrolled devices. For devices enrolled in MDE but not Intune (e.g., servers onboarded via the MDE onboarding package), the MDE tenant setting is the management plane. The Defender portal also provides reporting: Settings > Endpoints > Device Configuration > Tamper Protection report shows which devices have it enabled and which do not.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Handle Third-Party Security Tool Conflicts
The most common Tamper Protection deployment issue is a conflict with a third-party security product (SIEM agent, endpoint management tool, vulnerability scanner, or another AV product) that legitimately needs to modify Defender settings. Tamper Protection blocks these modifications and the third-party tool stops working or reports errors. Resolution: the third-party vendor should use the officially supported configuration management path (Intune or MDE API) rather than direct registry or PowerShell modification. Most major security vendors have updated their products to use supported management APIs that are compatible with Tamper Protection. If the vendor requires a local registry write: contact the vendor and request an update. Temporarily: exclude the specific machines running the conflicting tool from the Tamper Protection policy while working with the vendor, and document the exception. Never disable Tamper Protection globally because one tool has a conflict -- scope the exclusion minimally.
Verify Protection Status and Monitor for Tamper Attempts
Verify Tamper Protection is active on devices: Get-MpComputerStatus | Select-Object IsTamperProtected. A value of True confirms it is active. On the Intune device page: Devices > select device > Device Configuration > confirm the policy is applied and succeeded. Monitor for tamper attempts: Windows Defender logs blocked tamper attempts in the Microsoft-Windows-Windows Defender/Operational event log as Event ID 5013 (Tamper attempt detected and blocked). Forward Event ID 5013 to your SIEM and alert on any occurrence -- a tamper attempt is evidence of malicious activity. Common Event ID 5013 causes: automated scripts that modify Defender settings as part of software deployment (update the scripts to use Intune APIs), third-party security tools (work with vendor), or actual malware attempting to disable protection (investigate immediately).
Tamper Protection and Group Policy Compatibility
Tamper Protection has a known interaction with Group Policy: if Defender settings are configured via GPO (Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus), those GPO settings conflict with Tamper Protection in some scenarios. Specifically, GPO settings that disable Defender features are blocked by Tamper Protection, but Tamper Protection does not prevent enabling features via GPO. The recommended configuration: manage Defender settings via Intune (not GPO) on Intune-enrolled devices. If you have both GPO and Intune managing Defender settings on the same device, the behavior can be unpredictable. Audit for GPO settings that conflict with Tamper Protection: any GPO setting that sets DisableRealtimeMonitoring, DisableBehaviorMonitoring, or DisableIOAVProtection to 1 will conflict. Remove those GPO settings from any machine managed via Intune and rely on Intune as the single source of Defender configuration.
The bottom line
Tamper Protection is a one-policy deployment that eliminates one of the most commonly abused attacker capabilities: disabling the endpoint security agent before deploying ransomware or credential theft tools. Deploy via Intune to all managed endpoints, monitor Event ID 5013 for tamper attempts, and resolve any third-party tool conflicts through the vendor's supported management API. The investment is an hour of configuration work; the payoff is a Defender agent that cannot be disabled by any process on the endpoint.
Frequently asked questions
Can an attacker bypass Tamper Protection with a kernel-level exploit?
Tamper Protection operates at the user mode and management plane level -- it blocks registry writes, PowerShell cmdlets, and local API calls. A kernel-level exploit (ring 0 code execution) can potentially bypass Tamper Protection by directly modifying Defender driver state. This is a significantly higher bar than the standard 'run a PowerShell command as admin' attacks that Tamper Protection is designed to block. Kernel exploits require a specific Windows kernel vulnerability and a corresponding exploit payload -- commodity ransomware and most threat actors operate at user mode. Tamper Protection is highly effective against the threats it is designed for.
Does Tamper Protection prevent changing Defender exclusions?
Yes. With Tamper Protection enabled, adding Defender exclusions via Set-MpPreference -ExclusionPath or via the Windows Security GUI is blocked. Exclusions can only be added through the management plane (Intune policy or MDE Security Settings Management). This is an important ransomware defense: some ransomware operators add Defender exclusions for their payload directories before executing. With Tamper Protection, this technique fails.
What happens if I need to disable Defender temporarily on a managed device?
Temporary Defender changes (for troubleshooting, application testing, or legitimate maintenance) must be made through the Intune policy or MDE portal. In Intune: modify the Tamper Protection policy setting, apply it, make the change, then revert. In MDE: use the per-device management options in the Defender portal. There is no supported path to temporarily disable Tamper Protection from the local device. This is by design -- the inability to disable locally is what makes it effective against attackers who have local admin access.
Is Tamper Protection available on Windows Server?
Yes, Tamper Protection is available on Windows Server 2019 and later when the server is onboarded to Microsoft Defender for Endpoint. It is not available on Windows Server 2016 or earlier. For servers managed without MDE (standalone Defender), Tamper Protection is available in the Windows Security Center on Server 2019 and Server 2022 but requires MDE onboarding for the management-plane binding that provides the strongest protection. Server Tamper Protection is particularly important for servers that are high-value ransomware targets (backup servers, file servers, domain controllers).
How does Tamper Protection interact with third-party security tools that also modify Defender settings?
Third-party security tools (EDR platforms, vulnerability scanners, SIEM agents) that modify Defender settings via Set-MpPreference or registry writes are blocked when Tamper Protection is enabled. Vendors that are aware of this provide a supported API path: they use the Defender security management APIs or Windows Security Center APIs rather than direct registry/PowerShell manipulation. Check with your security vendors before enabling Tamper Protection -- most major vendors (CrowdStrike, SentinelOne, Carbon Black) have long had compatibility. Vendors that do not have a compatible path will need to update their integration method. Event ID 5013 in the Microsoft-Windows-Windows Defender/Operational log records which process attempted a blocked configuration change.
How do I verify that Tamper Protection is actually enforced on all endpoints and detect endpoints where it has been bypassed?
Verification starts with Intune: the Devices > Monitor > Antivirus agent status report shows Tamper Protection status per device. For endpoints not enrolled in Intune, use Microsoft Defender for Endpoint's device inventory (security.microsoft.com > Assets > Devices) and filter on Tamper Protection status using the Advanced Hunting query: DeviceTvmSecureConfigurationAssessment | where ConfigurationId == 'scid-2010' | where IsApplicable == 1 | where IsCompliant == 0. In the registry on a local device, HKLM:\SOFTWARE\Microsoft\Windows Defender\Features\TamperProtection should be 5 (enabled via Intune) or 1 (enabled locally). Values of 0 or 4 indicate disabled. A value of 5 set by Intune cannot be changed locally, confirming management-enforced protection. For bypass detection, monitor Microsoft Defender for Endpoint alerts for the 'Tamper Protection bypass' alert type, and review Event ID 5013 in the Microsoft-Windows-Windows Defender/Operational log for blocked tamper attempts -- a burst of 5013 events followed by Tamper Protection becoming disabled on a device indicates an active bypass attempt.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.