Attack surface reduction rules are one of the most effective protections in Microsoft Defender, and one of the most often switched off after a bad first week. The rules block the behaviors attackers rely on, like Office spawning PowerShell or scripts downloading payloads. Turn them all to block on day one and something in finance will break. Run them in audit first, read the data, then enforce, and you get the protection without the outage.
This guide walks through how I deploy attack surface reduction rules with Intune for small and mid-sized businesses: which rules can go straight to block, how to run the audit, how to read the results, and how to move to enforcement safely.
What attack surface reduction rules actually do
Attack surface reduction (ASR) rules are behavior controls built into Microsoft Defender Antivirus. Instead of looking for a known bad file, they block risky actions. A few examples:
Block all Office applications from creating child processes.
Block Office applications from injecting code into other processes.
Block executable content from email client and webmail.
Block execution of potentially obfuscated scripts.
Block credential stealing from the Windows local security authority subsystem (lsass.exe).
Block Win32 API calls from Office macros.
Most phishing-driven attacks follow a predictable chain: a document opens, a macro or script runs, a child process downloads something, and credentials are stolen. ASR rules break that chain at several points.
Each rule has a mode: Not configured, Audit, Warn, Block or Disabled. Audit logs what would have been blocked without stopping anything. Warn shows the user a message they can bypass. Block stops the action.
ASR rules need Microsoft Defender Antivirus as the active antivirus. They work with Business Premium and Defender for Endpoint, and Microsoft notes that the full reporting experience is best with E5-level licensing such as Microsoft 365 E5 or Defender for Endpoint Plan 2.
The rules you can block from day one
Microsoft groups three rules as standard protection rules that it recommends enabling in block mode without extensive testing:
Rule
Why it is low risk
Watch out for
Block abuse of exploited vulnerable signed drivers
Legitimate software rarely needs known vulnerable drivers.
Old hardware utilities.
Block credential stealing from lsass.exe
Normal apps do not read LSASS memory.
Redundant if LSA protection and Credential Guard are on.
Block persistence through WMI event subscription
Rarely used by business apps.
Configuration Manager relies on WMI, so audit first if you run it.
For a cloud-only Intune shop with no Configuration Manager client, I put these three in block straight away. Everything else goes to audit.
Step 1: Plan rings and an app inventory
Before you create a policy, decide who goes first. A simple ring model works well:
Ring 0: IT staff and a few tech-friendly users.
Ring 1: One representative person from each department, including finance and anyone who lives in Excel macros.
Ring 2: Everyone else.
At the same time, list your line-of-business apps, especially anything with macros, add-ins, or scripts. Accounting add-ins, document management plugins and old reporting tools are the usual suspects. That list tells you where to look when audit events appear.
Choose Windows as the platform and Attack Surface Reduction Rules as the profile. Set the three standard protection rules to Block and every other rule to Audit. Assign the policy to all Windows devices. Audit mode does not affect users, so there is no reason to limit it to a pilot.
Use one ASR policy per device where you can. Multiple policies that set the same rule to different values create conflicts, and conflicting settings are not applied.
Step 3: Read the audit data
Leave audit running for at least two weeks, longer if you have month-end processes that only run once. Then review the events:
Defender portal report. In the Microsoft Defender portal, the attack surface reduction rules report shows detections by rule, file and device.
Advanced hunting. If you have Defender for Endpoint Plan 2 or Microsoft 365 E5, query the DeviceEvents table where ActionType starts with Asr to see every audited event with the process and file involved.
Local event log. On a single device, look under Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational for event ID 1122 (audit) and 1121 (block).
For each rule, sort the hits into three buckets:
No hits. Move the rule to block.
Hits from legitimate business tools. Create a targeted exclusion for that file or folder, then move to block.
Hits from things nobody recognizes. Investigate. This is often old software that should be removed, and occasionally something worse.
Step 4: Exclusions, done carefully
Exclusions are where ASR deployments go wrong. A broad exclusion like an entire user profile folder defeats the purpose. Keep them tight:
Exclude a specific executable path, not a whole drive or profile.
Prefer per-rule exclusions over global ASR exclusions, so an exception for one rule does not weaken the others.
Record the owner and reason for each exclusion and review the list quarterly.
If a vendor says to exclude everything, ask them which rule fires and why.
Step 5: Enforce in rings, with Warn as a stepping stone
Move rules to block ring by ring. For rules that might catch a rare but legitimate action, Warn mode is a useful middle step on supported Windows versions. The user sees a message and can choose to continue, and you get the event data. After a few weeks of warn with no complaints, switch to block.
My usual order of enforcement after the standard protection rules:
Block executable content from email client and webmail.
Block JavaScript or VBScript from launching downloaded executable content.
Block execution of potentially obfuscated scripts.
Block Office applications from creating executable content and from injecting code.
Block all Office applications from creating child processes.
Block Win32 API calls from Office macros.
Block process creations originating from PSExec and WMI commands, last, because admin tooling often trips it.
Keep a short rollback plan: if a rule breaks something critical, set that one rule back to audit for the affected group while you build the exclusion. Never disable the whole policy.
How ASR fits with the rest of your stack
ASR rules are strongest alongside the other Defender layers: cloud-delivered protection, network protection, tamper protection and EDR. If you have not onboarded devices to Defender for Endpoint yet, start there, since ASR reporting depends on it. Our Defender for Endpoint service covers onboarding and tuning, and the endpoint security baseline puts ASR in context with the rest of a hardened Windows build. If you would rather hand the ongoing tuning to someone else, look at our managed security service.
How long should attack surface reduction rules stay in audit mode?
At least two weeks, and long enough to cover monthly processes like payroll or month-end reporting. The goal is to see every normal business activity at least once before you block.
Do attack surface reduction rules work with Microsoft 365 Business Premium?
Yes. Business Premium includes Microsoft Defender for Business and Intune, so you can deploy and enforce ASR rules. Some advanced reporting, such as advanced hunting, depends on your Defender plan.
Will ASR rules slow down devices?
In normal use, no. They are behavior checks inside Defender Antivirus. The impact users notice comes from blocked actions, which is why the audit phase matters.
Not sure which ASR rules are active in your tenant, or whether they are still stuck in audit? Book a free Microsoft 365 security assessment and we will show you where your endpoint protection stands.
Attack surface reduction rules are one of the most effective protections in Microsoft Defender, and one of the most often switched off after a bad first week. The rules block the behaviors attackers rely on, like Office spawning PowerShell or scripts downloading payloads. Turn them all to block on day one and something in finance will break. Run them in audit first, read the data, then enforce, and you get the protection without the outage.
This guide walks through how I deploy attack surface reduction rules with Intune for small and mid-sized businesses: which rules can go straight to block, how to run the audit, how to read the results, and how to move to enforcement safely.
What attack surface reduction rules actually do
Attack surface reduction (ASR) rules are behavior controls built into Microsoft Defender Antivirus. Instead of looking for a known bad file, they block risky actions. A few examples:
Most phishing-driven attacks follow a predictable chain: a document opens, a macro or script runs, a child process downloads something, and credentials are stolen. ASR rules break that chain at several points.
Each rule has a mode: Not configured, Audit, Warn, Block or Disabled. Audit logs what would have been blocked without stopping anything. Warn shows the user a message they can bypass. Block stops the action.
ASR rules need Microsoft Defender Antivirus as the active antivirus. They work with Business Premium and Defender for Endpoint, and Microsoft notes that the full reporting experience is best with E5-level licensing such as Microsoft 365 E5 or Defender for Endpoint Plan 2.
The rules you can block from day one
Microsoft groups three rules as standard protection rules that it recommends enabling in block mode without extensive testing:
For a cloud-only Intune shop with no Configuration Manager client, I put these three in block straight away. Everything else goes to audit.
Step 1: Plan rings and an app inventory
Before you create a policy, decide who goes first. A simple ring model works well:
At the same time, list your line-of-business apps, especially anything with macros, add-ins, or scripts. Accounting add-ins, document management plugins and old reporting tools are the usual suspects. That list tells you where to look when audit events appear.
Step 2: Deploy the rules in audit mode
In the Intune admin center go to:
Endpoint security > Attack surface reduction > Create PolicyChoose Windows as the platform and Attack Surface Reduction Rules as the profile. Set the three standard protection rules to Block and every other rule to Audit. Assign the policy to all Windows devices. Audit mode does not affect users, so there is no reason to limit it to a pilot.
Use one ASR policy per device where you can. Multiple policies that set the same rule to different values create conflicts, and conflicting settings are not applied.
Step 3: Read the audit data
Leave audit running for at least two weeks, longer if you have month-end processes that only run once. Then review the events:
DeviceEventstable whereActionTypestarts withAsrto see every audited event with the process and file involved.Applications and Services Logs > Microsoft > Windows > Windows Defender > Operationalfor event ID 1122 (audit) and 1121 (block).For each rule, sort the hits into three buckets:
Step 4: Exclusions, done carefully
Exclusions are where ASR deployments go wrong. A broad exclusion like an entire user profile folder defeats the purpose. Keep them tight:
Step 5: Enforce in rings, with Warn as a stepping stone
Move rules to block ring by ring. For rules that might catch a rare but legitimate action, Warn mode is a useful middle step on supported Windows versions. The user sees a message and can choose to continue, and you get the event data. After a few weeks of warn with no complaints, switch to block.
My usual order of enforcement after the standard protection rules:
Keep a short rollback plan: if a rule breaks something critical, set that one rule back to audit for the affected group while you build the exclusion. Never disable the whole policy.
How ASR fits with the rest of your stack
ASR rules are strongest alongside the other Defender layers: cloud-delivered protection, network protection, tamper protection and EDR. If you have not onboarded devices to Defender for Endpoint yet, start there, since ASR reporting depends on it. Our Defender for Endpoint service covers onboarding and tuning, and the endpoint security baseline puts ASR in context with the rest of a hardened Windows build. If you would rather hand the ongoing tuning to someone else, look at our managed security service.
Microsoft’s own testing guidance is worth reading alongside this: Test your attack surface reduction rules deployment.
Frequently asked questions
How long should attack surface reduction rules stay in audit mode?
At least two weeks, and long enough to cover monthly processes like payroll or month-end reporting. The goal is to see every normal business activity at least once before you block.
Do attack surface reduction rules work with Microsoft 365 Business Premium?
Yes. Business Premium includes Microsoft Defender for Business and Intune, so you can deploy and enforce ASR rules. Some advanced reporting, such as advanced hunting, depends on your Defender plan.
Will ASR rules slow down devices?
In normal use, no. They are behavior checks inside Defender Antivirus. The impact users notice comes from blocked actions, which is why the audit phase matters.
Not sure which ASR rules are active in your tenant, or whether they are still stuck in audit? Book a free Microsoft 365 security assessment and we will show you where your endpoint protection stands.