Defender ASR rules: the 16 you actually need, ranked by impact (AU 2026)

Attack Surface Reduction rules are the closest thing Microsoft Defender for Endpoint has to a free policy lever that closes off classes of attack rather than catching specific indicators. They are also the most under-deployed control in Australian mid-market tenants we audit. The default Microsoft recommendation is to enable all 16 production rules in block mode after a two-week audit. In practice, the audit-then-block sequence is what determines whether the rollout sticks or whether the helpdesk ends up turning everything back to audit-only after a week of incidents.

The 16 production rules, ranked by impact

Microsoft's documentation lists the rules in alphabetical order. Frontrow ranks them by the value-to-friction ratio observed in actual AU mid-market rollouts.

1. 1Block credential stealing from the Windows local security authority subsystem (lsass.exe) — highest impact, lowest friction. Block mode from day one.
2. 2Block all Office applications from creating child processes — the macro-as-dropper pattern. Block mode after a 2-week audit; common false positive is legitimate macros launching cmd.exe for legacy reporting.
3. 3Block Office applications from creating executable content — block mode after audit; surfaces older Word + VBA workflows that write executables.
4. 4Block Office applications from injecting code into other processes — block mode safe to roll out broadly; rarely surfaces legitimate use.
5. 5Block Win32 API calls from Office macros — block mode after audit; some shadow Excel + VBA reporting tools rely on Win32 calls.
6. 6Block JavaScript or VBScript from launching downloaded executable content — block mode safe broadly; surfaces some legacy intranet tooling.
7. 7Block executable content from email client and webmail — block mode broadly; Outlook + Teams flows are usually unaffected.
8. 8Block execution of potentially obfuscated scripts — block mode after audit; surfaces some legitimate PowerShell modules that pack their source.
9. 9Block untrusted and unsigned processes that run from USB — block mode broadly if USB control is in scope; otherwise audit.
10. 10Block Adobe Reader from creating child processes — block mode safe; rare legitimate use case.
11. 11Block process creations originating from PSExec and WMI commands — block mode after audit; surfaces IT admin scripts using PSExec for remote management. Pair with a documented break-glass exclusion.
12. 12Block persistence through WMI event subscription — block mode safe broadly.
13. 13Use advanced protection against ransomware — block mode after audit; surfaces some legitimate backup tools that touch many files quickly.
14. 14Block executable files from running unless they meet a prevalence, age or trusted list criterion — audit first, ramp to block at sites with mature application control.
15. 15Block abuse of exploited vulnerable signed drivers — block mode broadly; protects against BYOVD class attacks.
16. 16Block rebooting machine in Safe Mode (preview) — preview rule; audit only for now.

The audit-then-block rollout sequence

The Frontrow rollout pattern, refined across 30+ AU mid-market tenants, is: enable all 16 in audit mode on a 50-user pilot ring for two weeks; review the Defender Advanced Hunting DeviceEvents table for ActionType DeviceEvent and AsrRule for blocks; build per-rule exclusions for documented business processes; promote rules one at a time to block on the pilot ring; then ramp to the rest of the fleet by Conditional Access or Intune device group. The total elapsed time for a 500-user tenant is typically 6 weeks.

The most common AU false positives

• Legacy MYOB and Xero export macros launching cmd.exe (Block Office child processes rule).
• Internal PowerShell modules that pack source code (Block obfuscated scripts rule).
• IT helpdesk scripts using PSExec for remote remediation (Block PSExec/WMI rule) — usually solved with a per-IT-user exclusion plus a separate Just-in-Time admin pattern.
• Backup-agent file touch (Advanced ransomware rule) — usually solved with a signed-process exclusion list.

The reporting story for the board

ASR rules in block mode are observable. Defender Advanced Hunting and the Microsoft 365 Defender portal both show per-rule, per-device, per-time-window block counts. The single most useful board-level metric is the count of credential-theft attempts blocked at lsass.exe over the trailing 90 days. A non-zero count is evidence the control is doing real work. A zero count in a moderately-active tenant is usually evidence the rule is not in block mode at all — investigate before assuming the tenant is unusually quiet.