Attack Surface Reduction rules: the complete reference and deployment guide

Attack Surface Reduction rules are one of the highest-value security controls in the Microsoft Endpoint stack, and one of the most ignored. They ship with Microsoft Defender Antivirus, they block the techniques we see in real incidents (malicious Office child processes, LSASS credential dumping, script-based downloaders), and most organisations we assess have them either off or stuck in audit mode.

If you hold Microsoft 365 Business Premium, E3, E5 or the Defender Suite, you already own this capability. There is no extra licence to buy for the protection itself, though your tier changes how you manage and monitor it, covered below. This page is the reference table we wish existed when we started deploying ASR at scale, plus the deployment guidance Microsoft's documentation stops short of: which rules you can turn on today, which ones break things, and how to check before you commit.

Last reviewed: July 2026 against Microsoft's ASR rules reference. Microsoft adds rules over time, so we review this page periodically.

What ASR rules are

Each ASR rule targets a specific risky behaviour rather than a specific piece of malware. Blocking Office from spawning child processes stops a whole class of macro-based initial access, regardless of which payload the attacker uses. That behavioural approach is why ASR holds up well against new tooling that signature-based detection misses.

Every rule runs in one of four modes: Off (0), Block (1), Audit (2) or Warn (6). Audit logs what the rule would have blocked without blocking it, which makes it the safe starting point for anything you have not tested. Warn blocks but lets the user bypass, and a handful of rules do not support it.

ASR rules require Microsoft Defender Antivirus running in active mode. If a third-party AV product is primary and Defender is in passive mode, ASR rules do not apply. This catches out more environments than you would expect, and mid-migration fleets are the usual offenders.

What licence you need

The protection itself is close to free. ASR rules are a Defender Antivirus feature, so they enforce on any Windows edition running Defender AV in active mode, and you can configure them locally with PowerShell or Group Policy on any of those devices. What your licence tier changes is the management, reporting and hunting layer on top:

Microsoft 365 Business Premium includes Defender for Business, which gives you central ASR configuration and the attack surface reduction rules report in the Defender portal. Advanced hunting is not included at this tier, so you review audit data through the portal report rather than KQL.

Microsoft 365 E3 includes Defender for Endpoint Plan 1, which covers ASR configuration and reporting. As with Business Premium, advanced hunting sits above this tier.

Microsoft 365 E5 includes Defender for Endpoint Plan 2, which adds advanced hunting, EDR alerting on ASR events and custom detections. This is the tier the KQL further down assumes.

Microsoft Defender Suite is the current name for what used to be the Microsoft 365 E5 Security add-on. It layers the full E5 security stack, including Defender for Endpoint Plan 2, on top of an E3 licence, and it is the path we recommend most often for organisations that want E5-grade security without the rest of E5. A Business Premium variant exists too, the Defender Suite for Business Premium, which brings the same Plan 2 capability to smaller organisations. One quirk to know: Defender for Business does not support mixed licensing, so a tenant holding both defaults to the Defender for Business experience until you switch it over.

The short version: everyone already owns the blocking. E5 and Defender Suite customers get the fleet-wide hunting that makes the audit review below faster, and everyone else gets the same outcome through the portal report.

The reference table

Nineteen rules exist as of this review. Microsoft splits them into standard protection rules, which it recommends enabling for everyone, and the rest, which need testing first per its deployment guide. Everything except Intune and Configuration Manager identifies rules by GUID, so if you are working in Group Policy, PowerShell or a custom OMA-URI, this table is the mapping you need.

Standard protection rules

Other ASR rules

Three rules depend on cloud-delivered protection being enabled: Block executable files from running unless they meet a prevalence, Block execution of potentially obfuscated scripts, and Use advanced protection against ransomware. If cloud protection is off, those rules sit idle regardless of mode.

Which rules to enable first

The three standard protection rules go straight to Block in almost every environment. Microsoft designed them to run without an audit phase, and across the tenants we manage they generate close to zero legitimate business impact. The LSASS rule deserves one caveat: it produces a large volume of audit events, and nearly all of them are noise from processes making unnecessary calls to LSASS. Do not let a noisy audit log talk you out of enabling it, because the blocks it generates are working as intended.

The remaining rules need an audit period. In our experience across MDR customers, these are the ones that bite:

Block process creations originating from PSExec and WMI commands. The single most disruptive rule for IT teams. Any RMM tooling, deployment scripts or remote administration built on PsExec or WMI process creation stops working. If you manage endpoints with Configuration Manager, do not enable this rule at all through other deployment methods, because the ConfigMgr client itself relies on WMI.

Block all Office applications from creating child processes. Line-of-business Office add-ins are the usual casualty. Finance and payroll integrations that shell out from Excel show up in audit data within days.

Block executable files from running unless they meet a prevalence, age, or trusted list criterion. In-house applications and freshly compiled tools trip this because they have no reputation in Microsoft's cloud. Software development teams feel this one first.

Block Win32 API calls from Office macros. Entire businesses run on macro-heavy workbooks, and some of those macros call Win32 APIs for legitimate reasons. Older line-of-business templates, actuarial models and warehouse tooling all show up here. A week of audit events shows whether your organisation is one of them.

Audit for two to four weeks of normal business activity, including a month-end cycle if your finance systems touch Office automation, then review the data and move rules to Block in batches.

Reviewing audit data before you commit

Event IDs 1121 (blocked) and 1122 (audited) land in the Microsoft-Windows-Windows Defender/Operational log on each device. Business Premium and E3 customers get the fleet-wide picture from the attack surface reduction rules report in the Defender portal. With Defender for Endpoint Plan 2, advanced hunting does the same job with more control, and this is the query we run for pre-deployment reviews:

DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr" and ActionType endswith "Audited"
| summarize Hits = count(), Devices = dcount(DeviceId) by ActionType, FileName, FolderPath
| order by Hits desc

Anything with high hit counts across many devices is either a business process you need to exclude or handle, or a problem you are about to be glad you found. Investigate before flipping the rule, and keep the query running after go-live with Blocked in place of Audited to catch anything the audit window missed.

Exclusions: where your management tooling matters

Exclusions are where ASR deployments succeed or fail, and where your choice of management plane makes a real difference.

Intune supports per-rule exclusions in the Attack Surface Reduction policy. Once a rule is set to Audit, Block or Warn, you can scope an exclusion to that rule alone. Your finance team's Excel add-in gets excluded from the Office child process rule while every other rule still applies to it in full, which is how exclusions should work.

Group Policy environments have a rougher time. The per-rule exclusion setting only exists in newer ADMX templates, so organisations running an older central store are limited to the global ASR exclusion list, where an excluded path is excluded from every rule at once. One noisy line-of-business app ends up with a blanket exemption from your entire ASR posture. We see this trade-off in real environments often enough that it factors into our recommendation: if devices are co-managed or Entra-joined, move ASR configuration to Intune and get the per-rule granularity, and if you are stuck on Group Policy, update your ADMX central store before building exclusions.

Two further wrinkles apply everywhere. Several rules have limited exclusion support regardless of how you deploy them, including the LSASS rule and PSExec/WMI rule, so test exclusions rather than assuming they work. And exclusions should name full paths or files, never broad directories a standard user can write to, because a writable excluded folder is where an attacker will stage their tools.

Why ASR ends up switched off

When we assess an environment with ASR disabled, we find one of three stories. An audit phase kicked off years ago and never got reviewed. Someone assumed ASR needed E5 when it works on any Windows edition running Defender Antivirus, with Defender for Endpoint adding the reporting and hunting on top. Or one rule broke one application and the whole lot got turned off, when an exclusion or setting that single rule back to Audit would have done the job.

All three are fixable. The audit data can be re-run, the licensing concern is a non-issue, and one problem rule is no reason to give up the other eighteen.

The behaviours these rules block are the same ones we see in real incidents: macros spawning shells, scripts pulling down second-stage payloads, credential theft from LSASS, lateral movement over WMI. The standard protection rules take an afternoon to enable. The rest takes about a month of measured rollout. Either way, it is a fraction of the cost of the incident they prevent.

If you want a hand getting ASR out of audit mode and into block, or a broader review of your Defender configuration, get in touch.