How to Deploy Attack Surface Reduction Rules: Audit Mode, Exclusions and Enforcement

Attack surface reduction (ASR) rules block the behaviours most commodity malware and ransomware operators rely on, yet many estates leave them in Audit mode for years because nobody owns the move to Block. The rules themselves are a few GUIDs and a mode value; the hard part is the deployment: proving which line-of-business apps a rule will break, writing exclusions narrow enough not to undo the protection, and moving ring by ring to enforcement with a way back. This guide is the deployment runbook for Microsoft Defender ASR rules: prerequisites, the rule set and its quirks, policy sources and precedence, audit data, exclusions, ring rollout, rollback and measurement. It is written for endpoint engineers and security operations teams running Microsoft Defender for Endpoint, Intune, Configuration Manager or Group Policy. For where ASR fits among other Windows controls, read the Windows Endpoint Hardening Guide first.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Check prerequisites before any rule: ASR rules work only when Microsoft Defender Antivirus is the primary antivirus in active mode with real-time and cloud-delivered protection on.
• Start the three standard protection rules in Block: Microsoft says they can typically go to Block or Warn without testing; audit the rest first.
• Pick one policy source per rule: Intune or Configuration Manager settings overwrite local PowerShell values, and configuring the same rule in Group Policy and MDM creates conflicts.
• Prefer narrow, per-rule exclusions: excluded files run with no further ASR events, so a broad folder exclusion silently removes protection.
• Measure the move to Block: track rules in Block per device, audit-to-block conversion and exclusion count, not just "policy deployed".

Prerequisites and what ASR rules need to work

ASR rules are part of Microsoft Defender Antivirus, so their prerequisites are antivirus prerequisites. Microsoft's ASR overview sets these conditions:

• Active mode: Defender Antivirus must be the primary antivirus. Rules do not run in passive mode, in passive mode with EDR in block mode, in limited periodic scanning, or with the antivirus off. Estates still running another antivirus product must plan that change first.
• Real-time protection: on.
• Cloud-delivered protection: on, and devices must reach the Defender Antivirus cloud service. Microsoft calls it critical to ASR rule functionality, and several rules (obfuscated scripts, the prevalence rule, advanced ransomware protection) state they require it.
• Current components: platform, engine and security intelligence no more than two versions behind the latest, which also reduces false positives.
• Supported systems: centrally managed rules, reporting and alerting cover Windows 10 or later Pro and Enterprise, Windows Server 2012 R2 or later and Azure Local 23H2 or later. ASR rules do not apply to macOS or Linux, even when onboarded to Defender for Endpoint.
• Availability: ASR rules do not require Microsoft 365 E5, but Microsoft recommends E5 or equivalent for the portal report, advanced hunting and device timeline. Without them, build reporting from Windows events collected with Windows Event Forwarding. The deployment guide applies to Defender for Endpoint Plan 1 and Plan 2; advanced hunting is a Plan 2 capability.

Microsoft also records a known issue where ASR on server operating systems can report as compliant without enforcement, so verify servers with test events rather than trusting the configuration report alone.

The rule set and how to sequence it

Rule modes are the same everywhere: 0 Off, 1 Block, 2 Audit, 5 Not configured and 6 Warn. Warn behaves like Block but lets the user select Unblock for 24 hours; since platform version 4.18.26060 that override needs administrator approval. Warn needs Windows 10 1809 or later, is not available through Configuration Manager, and is not supported by the LSASS and Office code injection rules. The table groups the rules by deployment wave, using notes from Microsoft's rule reference.

The LSASS rule is redundant where LSA protection and Credential Guard are already enabled, but it still costs little to keep in Block. Microsoft also notes some ASR rules work poorly with frequently used unsigned, internally developed apps and scripts, so code signing for in-house tools makes waves 3 and 4 much easier.

Choosing a policy source and avoiding conflicts

Decision guidance: choose one management plane per device population and stay with it. Intune-managed estates should use the endpoint security policy, because it carries per-rule exclusions and feeds the portal report. Domain-joined estates without Intune can use Group Policy, but keep MDM out of ASR settings on those devices. Configuration Manager suits co-managed servers, accepting that Warn mode is not available there. Small organisations can run a single Intune policy with two or three device groups as rings; large organisations should create one policy per ring and per exception population, so a rollback touches only the devices affected. Note the PowerShell Set-MpPreference form replaces the whole rule list, while Add-MpPreference changes only the rules named.

Audit mode: collecting the evidence

Microsoft's test phase deploys all non-standard rules in Audit together to ring 1, which changes nothing for users and only logs events. The deployment method does not change the reporting, provided devices are onboarded to Defender for Endpoint. Collect from these sources:

A useful hunting pattern is to filter audited events and summarise by rule, initiating process and folder path, for example DeviceEvents | where ActionType startswith "Asr" and ActionType endswith "Audited" followed by a count by ActionType, InitiatingProcessFileName and FolderPath. Microsoft does not set a fixed audit duration; plan for at least one full business cycle that includes month-end processing, patching and any seasonal applications, and longer for wave 4 rules. Microsoft publishes an asr-events.xml custom view for Event Viewer covering events 1121, 1122, 1129 and 5007.

Exclusions without losing the protection

Microsoft's warning is explicit: excluding files or folders can severely reduce ASR protection, excluded files are allowed to run and no reports or events are recorded for them. Microsoft still recommends an exclusion over turning a rule off or returning it to Audit, because the rest of the estate stays protected. Use the narrowest type that fixes the problem:

• Per-rule exclusion: applies to one rule only. Supported through Intune endpoint security policies, the Defender portal and Group Policy (value format Path1\Proc1>Path2\Proc2 against the rule GUID). This is the default choice.
• Global ASR exclusion: AttackSurfaceReductionOnlyExclusions applies to every ASR rule. Use only for a process that trips several rules for a known reason.
• Indicators: most rules honour file and certificate indicators, which suit signed in-house software better than paths.
• Antivirus exclusions: not honoured by every rule. Microsoft lists seven rules that ignore Defender Antivirus file and folder exclusions, including the LSASS, WMI persistence, Office code injection and PSExec/WMI rules; all rules honour process exclusions.

Path rules: exclude a specific file path in preference to a folder. Wildcards and environment variables are allowed, but do not use user environment variables, wildcards cannot define a drive letter, and nested folders need repeated \*\ segments. Exclusions take effect when the process starts, so a running service keeps triggering until restarted. Exclude only from paths standard users cannot write to; an exclusion for a user-writable folder hands that rule's bypass to anyone who can drop a file there. One more trap: when local admin merge is disabled (Intune Disable Local Admin Merge, the Defender CSP DisableLocalAdminMerge or the matching Group Policy), per-rule and local ASR exclusions do not apply. For exclusion governance across all endpoint controls, use the EDR Tuning and Exclusions Management Guide.

Phased rollout from Audit to Block

1. Plan: pick the first business unit by size, champion availability and use of scripts, macros and shared tools; inventory line-of-business apps; agree who gathers reports, who investigates blocks (security operations) and who owns exclusions (endpoint team). Reuse existing Windows update rings if you have them.
2. Standard protection everywhere: set the three standard protection rules to Block across the estate, subject to the WMI rule caveat for Configuration Manager.
3. Ring 1 audit: all other rules to Audit for the pilot ring. Review the report weekly with champions and draft exclusions.
4. Ring 1 enforce: move rules to Block or Warn one or a few at a time, starting with the rule that has the fewest events, as Microsoft advises. Use Warn where supported to surface disruption before full Block.
5. Ring n+1: for each further ring, repeat Microsoft's sequence: Audit, review, exclusions, Block, review, refine. Move on only when the current ring is stable.
6. Wave 4 last: run the PSExec/WMI, prevalence and ransomware rules in Audit longest, and start them on populations with the least custom software.
7. Roll back by rule and ring: if a rule breaks a critical workflow, add a per-rule exclusion if the cause is clear; otherwise return that rule to Audit for that ring's policy only. Never roll back by switching the whole policy off. Record every rollback with an owner and a date to retry.

Organisations moving from a third-party host intrusion prevention product can, per Microsoft's planning guide, run it alongside ASR rules until rules reach Block, then retire it.

Where identity fits

Several rules exist to protect credentials and admin channels. The LSASS rule targets credential dumping, and the PSExec/WMI rule targets the remote execution paths that stolen administrator and service account credentials are used for. Exclusions for management agents and deployment tools often name processes that run as SYSTEM or under service accounts, so treat each one as a privileged change: record which identity runs the excluded process and review it with the account owner. Pair ASR with unique local administrator passwords (see the Local Administrator Password Solution (LAPS) Guide) so a blocked credential theft attempt is not the only barrier.

Detection and measurement

• Coverage: percentage of supported devices with all standard protection rules in Block (the report's Configuration tab shows this directly).
• Enforcement depth: median number of rules in Block per device, per ring.
• Conversion: rules moved from Audit to Block per quarter; any rule in Audit for more than [180 days] needs a named owner and a plan.
• Exclusion hygiene: count of global and per-rule exclusions, share that point to folders rather than files, and share reviewed in the last [12 months].
• Tamper signals: alert on event 5007 changes to ASR settings outside change windows, and on ASR rules in Off where policy says Block.
• Prevention value: Block events (1121) by rule, triaged by security operations, with high-severity rules (LSASS, Office injection) investigated as possible intrusions.

Common failure patterns

• Permanent Audit: rules deployed in Audit with no exit criteria or owner, so the report fills with events nobody acts on.
• Passive mode surprise: devices where another antivirus is primary report an ASR policy but enforce nothing, because the rules need Defender Antivirus in active mode.
• Folder exclusions: a whole application or temp folder excluded to stop a single false positive, removing that rule's protection and its telemetry for everything in the folder.
• Conflicting sources: the same rules set in Group Policy and Intune, giving devices that flip state or ignore the intended mode.
• Exclusions that never apply: per-rule exclusions created while local admin merge is disabled, or antivirus exclusions relied on for rules that do not honour them.
• Servers trusted on paper: server compliance reported without testing that rules actually fire.

Framework mapping

For the wider execution-control picture, see the App Control for Business (WDAC) guide, which Microsoft's rule reference names as a complement to the vulnerable driver rule, and the Office Macro Blocking Guide.

Practitioner checklist

• Confirm Defender Antivirus is in active mode with real-time and cloud-delivered protection on every target device.
• Choose one policy source per device population and remove ASR settings from the others.
• Set the three standard protection rules to Block estate-wide.
• Run all other rules in Audit for ring 1 with named champions and a feedback channel.
• Collect events from the ASR report, advanced hunting or forwarded 1121, 1122, 1129 and 5007 events.
• Write per-rule, file-level exclusions only for paths standard users cannot write to.
• Move rules to Block one at a time, fewest events first, using Warn where supported.
• Roll back a single rule in a single ring's policy, never the whole policy.
• Test that rules fire on servers rather than trusting the compliance report.
• Report coverage, Audit-to-Block conversion and exclusion counts monthly.

Standards and references

• Microsoft: Attack surface reduction rules overview
• Microsoft: Attack surface reduction rules reference
• Microsoft: Configure attack surface reduction rules and exclusions
• Microsoft: Plan attack surface reduction rules deployment
• Microsoft: Test attack surface reduction rules
• Microsoft: Enable attack surface reduction rules
• Microsoft: Attack surface reduction rules report
• Microsoft: Attack surface reduction Windows events

Related NHI Mgmt Group resources: Windows Endpoint Hardening Guide · Microsoft Defender for Endpoint Guide · Audit Mode vs Enforcement Mode · EDR Tuning and Exclusions Management Guide