Attack surface reduction rules not applying: what to check

Attack surface reduction rules not applying is rarely an Intune delivery problem. The policy reports success, the rule GUIDs land on the device, and nothing is ever blocked, because attack surface reduction is a Microsoft Defender Antivirus feature and Defender was not the engine doing the work. This page walks the requirement chain in the order it fails, shows how to read the real rule state on the device rather than in the console, and names the conflict behaviour that quietly drops a setting configured by two policies at once.

If several endpoint security policies are failing on the same devices, work the layers in the Intune troubleshooting index first and come back once you have proved the device is checking in. Nothing below applies to a device that is not talking to the service.

I have not run this across a production fleet. My tenant is a lab with no enrolled devices, so what follows is the documented dependency chain, verified against Microsoft Learn on 19 October 2026, and the order in which it tends to bite.

Why attack surface reduction rules not applying is usually a Defender problem

The most useful fact about these rules is that they do not belong to Intune. Intune writes the configuration. Microsoft Defender Antivirus enforces it. The ASR rules overview lists four requirements, and all four have to hold at the same time:

• Microsoft Defender Antivirus must be enabled and in Active mode. The documentation names the disqualifying states outright: Passive, Passive Mode with Endpoint Detection and Response (EDR) in Block Mode, Limited periodic scanning, and Off.
• Microsoft Defender Antivirus must be the primary antivirus app on the device.
• Real-time protection must be on.
• Cloud-delivered protection, which the same page also calls the Microsoft Advanced Protection Service, is described as critical to rule functionality, and the environment must allow connections to the Defender Antivirus cloud service.

Read the first two together and the common cause appears. Install a third party antivirus product and Defender drops to passive mode. Passive mode still reports health, still scans on demand, and still looks present in the console. It does not run attack surface reduction. Every rule you deployed is sitting on the device as a value nothing reads, and Intune cannot see that, so the policy assignment stays green.

EDR in block mode is the state that catches security teams rather than desktop teams, because it sounds like more protection rather than less. It is in the disqualifying list all the same. So is Limited periodic scanning, which is the mode Defender falls into on a device where another product owns real-time scanning.

Read the real rule state on the device, not in the console

Before changing any policy, find out what the device actually has. The ASR troubleshooting guide gives a one line check that pairs each rule GUID with the mode it is running in.

1# Lists every ASR rule GUID present on the device and the mode it is in.
2# Microsoft documents the action values as 2 = Audit mode, 1 = Block mode.
3$p = Get-MpPreference;0..([math]::Min($p.AttackSurfaceReductionRules_Ids.Count,$p.AttackSurfaceReductionRules_Actions.Count)-1) | % {[pscustomobject]@{Id=$p.AttackSurfaceReductionRules_Ids[$_];Action=$p.AttackSurfaceReductionRules_Actions[$_]}} | Format-Table -AutoSize

An empty result means nothing arrived. A result full of rules while nothing is ever blocked means the Defender requirements above are not met. That one distinction saves most of the investigation, and it is the check almost no third party guide opens with.

For the source of each setting rather than its value, the same guide points at the Effective settings tab on the device page in the Microsoft Defender portal, which reports each rule’s effective value and which policy set it. That is the answer to the question practitioners keep asking in public forums: not what the rule is, but who set it.

On the device itself the evidence is in Applications and Services Logs, then Microsoft, then Windows, then Windows Defender, then Operational. Four event IDs matter:

5007 is the one to filter on when a rule will not stay put. It records the change, not the intent, so a run of 5007 entries with no corresponding policy edit means something else on the device is writing Defender configuration. If you need the whole picture off the machine, MpCmdRun.exe -GetFiles writes MpSupportFiles.cab to C:\ProgramData\Microsoft\Windows Defender\Support, and MPRegistry.txt inside it holds the Defender configuration as it stood at collection time. That is a different and more complete artefact than the Intune side, where Collect diagnostics leaves gaps worth knowing about.

Disabled and Not configured are not the same thing

This is the detail that produces conflicts nobody can trace. The overview documents five modes with numeric codes, and two of them look identical from the admin centre:

So the two ways of turning a rule off are not interchangeable. Setting a rule to Disabled in one profile while a baseline sets it to Block creates a conflict. Leaving it Not configured in that profile does not. If you have inherited a tenant where someone built an ASR profile by explicitly disabling the rules they did not want, that profile is a conflict generator, and the fix is to clear those settings rather than to argue with the baseline.

Warn mode changed, and most guides have not caught up

Warn mode blocks the action and offers the user an Unblock option. The published guidance for years was that the user clicks through and the bypass lasts 24 hours. The overview now carries an important notice that administrator approval is required to use the Unblock option, a change introduced in Defender platform version 4.18.26060, and it adds that Unblock is intended for temporary suppression only and is not a durable exclusion mechanism.

If your rollout plan assumed users could self-serve past a warning while you collected telemetry, that plan needs rereading. The other Warn mode constraints are older and still catch people:

• Warn mode needs Windows 10 version 1809 or later. On an unsupported version a Warn rule behaves as Block and the bypass is simply absent.
• It needs Defender platform 4.18.2008.9 or later and engine 1.1.17400.5 or later.
• It is not available in Microsoft Configuration Manager at all, which matters while you are still co-managed.
• Two rules do not support it: Block credential stealing from the Windows local security authority subsystem, and Block Office applications from injecting code into other processes.

Set one of those two rules to Warn and you have not configured a warning. You have configured something the platform cannot deliver.

Where two policies cancel a rule out

Intune evaluates ASR rule settings from three places, and the Intune attack surface reduction policy documentation names them: the older Endpoint protection device configuration profile under Microsoft Defender Exploit Guard, the Endpoint security attack surface reduction policy, and the Microsoft Defender for Endpoint security baseline.

The documented merge behaviour is per setting. Settings that do not conflict are merged into a superset; settings that do conflict are not added to it. Only the conflicting settings are held back. That is better than the old behaviour, where a single conflicting setting invalidated both profiles, but it produces a worse symptom: nine rules apply, one does not, and the console does not lead you to which policy pair caused it. The Effective settings tab is the shortcut.

The Defender for Endpoint baseline is the usual second source, because assigning it is a one click decision that sets ASR rules you may not have read. That mechanism is the same one described in where the second security baseline profile comes from, and the resolution is the same: decide which object owns the setting, and make the other one silent rather than contradictory.

One honest caveat about the documentation itself. On the Intune page as it reads today, the merge behaviour section describes per setting merging for attack surface reduction rules, while a later section headed policy merge for settings lists only Device control as a profile that supports policy merge. Those two statements do not agree. I would treat the merge behaviour section as current and verify on a pilot device rather than rely on either, because the cost of being wrong is a rule you believe is enforced and is not.

The failure modes

Policy shows Not Applicable. For the rule Block credential stealing from the Windows local security authority subsystem, this is expected rather than broken. The attack surface reduction FAQ states that when Local Security Authority protection is enabled the rule is redundant, provides no extra protection, and is classified as not applicable in Defender for Endpoint management settings. Do not chase it.

Rules deployed, nothing in the report. The rules themselves ship with Microsoft Defender Antivirus in all current editions of Windows and need no licence to function. Centralised management and reporting is the licensed part, and the attack surface reduction rules report requires Microsoft Defender for Endpoint Plan 2 or Microsoft Defender for Business. An unlicensed tenant gets enforcement with no visibility, which reads exactly like a rule that is not working.

Exclusions ignored. Two separate limits. Per rule exclusions are supported only by Group Policy and by endpoint security policies in Intune, so a rule configured elsewhere gets global exclusions or none. And the FAQ is explicit that not all ASR rules honour Microsoft Defender Antivirus exclusions, so an existing antivirus exclusion is not evidence that a path is excluded from a rule. In the Intune profile, ASR Only Per Rule Exclusions defaults to Not configured.

Rules applied to the wrong devices. ASR policy targets Windows only, and Defender must be primary. Mixed estates need the assignment narrowed rather than the policy loosened, which is a filter problem more than a group problem: see what breaks when you swap groups for filters.

Rule GUID typed in by hand. Where rules came from Group Policy, the troubleshooting guide says to check for extra characters such as quotation marks or spaces in the rule GUID value. A GUID with a stray space is not an invalid rule, it is an absent one.

What I would do differently

Prove the engine before you blame the policy. One Get-MpPreference run and one look at Defender’s mode answers more than an hour of reassignment, and it is the step people skip because the Intune console is the thing in front of them.

Then pick one owner. Attack surface reduction rules set from three places with per setting merging will eventually produce a rule that silently does not apply, and no amount of care in each individual profile prevents it. Put the rules in the endpoint security attack surface reduction policy, leave them Not configured everywhere else, and never use Disabled to mean not wanted.

Finally, treat Audit as the default state for anything new rather than a formality. Microsoft’s own guidance is that roughly 30 days in Audit mode gives a usable baseline for a rule’s impact, and that rule exclusions are preferable to turning a rule off or moving it back to Audit later. With administrator approval now required for the Warn mode bypass, the audit period is the only cheap place left to discover which of your line of business applications the rule was going to break. The same ordering discipline applies to the adjacent endpoint policies, which is why Intune firewall rules fail quietly for structurally similar reasons.

Last verified: 19 October 2026.