Eighteen rules that block the behaviour attackers rely on, and three you can turn on almost immediately.
Attack surface reduction rules stop Office spawning child processes, scripts launching downloaded executables, and code reading credentials out of memory. Microsoft groups three of them as standard protection rules. The other fifteen need an audit-mode programme first, because in a real estate some of them will block something you need.
- 18 rulesThree standard protection, fifteen others
- Audit firstThen warn, then block
- Any Windows editionThe rules are a Defender Antivirus feature
- Central reportingComes from Defender for Endpoint
Eight things worth understanding before you enable anything.
Three standard protection rules, and fifteen others
Microsoft separates the published set into standard protection rules and other rules. The three standard ones block abuse of exploited vulnerable signed drivers, block credential stealing from the Windows local security authority subsystem, and block persistence through WMI event subscription. That grouping is the single most useful piece of guidance on the page, because it tells you where to start without a discovery exercise.
The Office rules are the ones that bite
Blocking all Office applications from creating child processes, blocking Office from creating executable content, blocking Office injecting code into other processes, blocking Office communication applications creating child processes, and blocking Win32 API calls from Office macros. Microsoft notes some legitimate line of business applications generate child processes for benign purposes, spawning a command prompt or using PowerShell to configure registry settings. In a UAE estate with an old ERP front end, that is not hypothetical.
Alerts depend on your cloud protection level, which surprises people
For three rules covering Adobe Reader child processes, executable content from email and webmail, and JavaScript or VBScript launching downloaded executables, Microsoft states EDR alerts are generated only when the cloud protection level on the device is High plus or Zero tolerance, and user notification pop-ups only when it is High, High plus or Zero tolerance. Enable those rules at a lower level and they still block, but the reporting you expected does not appear.
The LSASS rule may not apply to you at all
Microsoft states that if you have enabled Local Security Authority protection, which it recommends alongside Credential Guard, this rule is not required, does not provide extra protection because the rule and LSA protection work similarly, and is classified as not applicable in Defender for Endpoint management settings in the Microsoft Defender portal. Organisations chase that rule for weeks without noticing it has already been superseded on their own devices.
Several rules do nothing without cloud-delivered protection
Blocking executable files that do not meet a prevalence, age or trusted list criterion, and using advanced protection against ransomware, both carry the same instruction: to use the rule you must enable cloud-delivered protection. Blocking execution of potentially obfuscated scripts depends on the antimalware scan interface and cloud protection. Turning the rule on while cloud protection is off produces a configuration that reports as enabled and protects nothing.
Two rules have no warn mode
Most rules support not configured, audit, block and warn, where warn lets a user bypass the block. Microsoft flags two exceptions in the same footnote: blocking credential stealing from the local security authority subsystem, and blocking Office applications from injecting code into other processes. For those two the deployment path is audit then block, with no intermediate step where a user can unblock themselves.
Not every rule reaches every device the same way
Microsoft publishes a deployment matrix across Intune, Configuration Manager, the MDM configuration service provider and centralised Group Policy, and several rules are marked as unavailable through Configuration Manager. It also notes the Microsoft Defender portal uses the same endpoint security policies as Intune, so it supports the same rules shown in the Intune column. Estates running two management planes hit this constantly.
Servers are a separate conversation
Windows Server 2016 and Windows Server 2012 R2 support requires onboarding through the modern unified solution package, and Microsoft lists four rules that are not supported when deployed through Intune to those two operating systems using that solution. The webshell creation rule applies to Exchange servers only. Assuming server coverage matches workstation coverage is a common and quiet mistake.
Rules enabled, alerts never arrive, and nobody notices for a year.
Three of the eighteen rules have a documented dependency on the cloud protection level, and the default level in most tenants is not high enough to satisfy it.
- For the Adobe Reader child process rule, the executable content from email and webmail rule, and the JavaScript or VBScript downloaded executable rule, Microsoft states EDR alerts are generated only when the cloud protection level on the device is High plus or Zero tolerance.
- User notification pop-ups on those same three rules are generated only when the level is High, High plus or Zero tolerance, so the user sees nothing either.
- The rules still block. The configuration reports as compliant. What is missing is every signal that would tell you the block happened, which means nobody investigates the email that was carrying an executable.
- The fix is a policy decision about cloud protection level, made deliberately and with an understanding of the false positive trade at higher levels, rather than a silent default nobody chose.
Four things that stop an ASR rollout being reverted in week three.
We check prerequisites before we enable a single rule
Cloud-delivered protection state, cloud protection level, LSA protection, Credential Guard and the antimalware scan interface. Several rules quietly do nothing without one of these, and one rule is classified as not applicable when LSA protection is on. Establishing that first prevents both a false sense of coverage and weeks of work on a rule that was never going to apply.
We audit on the awkward machines, not the easy ones
A pilot ring of standard office laptops tells you almost nothing. The findings live on the finance workstation with the twenty year old Excel add-in, the engineering machine that compiles unsigned binaries, and the reception kiosk running something nobody can name. Audit those and the block-mode surprises largely disappear.
We treat exclusions as debt, with an owner and a date
Every exclusion is a documented hole in a control. Microsoft notes several rules have limited exclusion support anyway, so the honest answer is often to fix or replace the application rather than carve an exception. Where an exclusion is genuinely justified it gets a reason, an owner and a review date, so the list does not silently grow until the rules protect nothing.
We make sure the blocks are actually visible
A rule that blocks silently is a control that nobody learns from. Getting the cloud protection level right so the three dependent rules generate alerts, and making sure those alerts reach a queue somebody works, is what converts attack surface reduction from a compliance checkbox into a source of genuine detection.
Four phases, and nobody goes straight to block on eighteen rules.
- 01Week 1
Prerequisites and the three standard rules
Confirm cloud-delivered protection is enabled, since several rules do nothing without it. Decide the cloud protection level deliberately, because three rules only alert at High plus or Zero tolerance. Check whether LSA protection and Credential Guard are already deployed, which makes the credential stealing rule not applicable. Then enable the three standard protection rules, taking Microsoft at its word that the credential rule can skip audit and start on a small device group.
- Cloud-delivered protection verified on every in-scope device
- Cloud protection level chosen, not inherited
- LSA protection and Credential Guard status established
- Standard protection rules rolled to a pilot ring
- 02Weeks 2 to 4
Everything else in audit mode
The remaining fifteen rules go to audit across a representative device population, deliberately including the awkward machines: the finance workstation with the ancient add-in, the engineering laptop that compiles binaries, the reception kiosk. Audit mode records what would have been blocked without blocking it, which is the only honest way to find out what your Office estate actually does.
- Representative rings rather than a convenient sample
- Office rules watched most closely, they generate the most findings
- Configuration Manager estates get extra care on the two WMI rules
- Advanced hunting used to attribute events to applications, not just counts
- 03Weeks 5 to 6
Exclusions, and only where they are justified
Each audit finding gets a decision: block anyway because the behaviour is unnecessary, exclude with a documented reason, or fix the application. Microsoft flags that several rules have limited exclusion support, so the exclusion route is not always available and the fix route becomes the answer. This phase is where an ASR programme either stays honest or turns into a list of holes.
- Every exclusion carries an owner, a reason and a review date
- Limited-exclusion rules identified before promises are made
- Application owners engaged where the fix is in their software
- Anything with no owner defaults to block, not to exclude
- 04Weeks 7 onward
Promote to block, then keep the discipline
Rules move from audit to block in rings, with warn mode used as an intermediate step where the rule supports it. The two rules with no warn mode go straight from audit to block. After that it becomes an operational rhythm: new applications get tested against the rule set, exclusions get reviewed rather than accumulating, and rule state is reported alongside the rest of the endpoint posture.
- Ring-based promotion with a defined rollback
- Warn mode where supported, direct block where not
- Exclusions reviewed on a schedule, not left permanently
- Rule state reported as a posture metric, not a project artefact
Six UAE situations where the rules earn their place quickly.
A finance function that lives in email attachments
Invoices, statements and remittance advice arriving all day, from senders who are genuinely external. Blocking executable content from email client and webmail stops the executables, scripts and archives that Microsoft lists, and blocking Office communication applications from creating child processes closes the Outlook route. Both are high value where the business genuinely cannot stop opening attachments.
A group with an inherited line of business application
The Office child process rules are the ones that break things, and an estate with an old front end that shells out to a command prompt will find out immediately. That is exactly why audit mode exists. Knowing which of your applications does this, before block mode, is the difference between a controlled fix and an emergency rollback.
An operation where USB is still part of daily work
Blocking untrusted and unsigned processes running from USB is the relevant rule, and Microsoft is precise about what it does. It does not prevent files being copied from the drive to disk, it prevents the copied files running from disk. For plants and yards where removable media moves between machines that never touch the corporate network, that distinction shapes the whole control.
A professional services firm worried about ransomware
Advanced protection against ransomware uses client and cloud heuristics to judge whether a file resembles ransomware, and Microsoft is explicit that it also blocks files that do not yet have a positive reputation rather than only files with a bad one. That is a deliberately cautious posture, and it needs cloud-delivered protection enabled to work at all.
A healthcare estate with clinical software nobody can change
Clinical applications are frequently unsigned, low prevalence and impossible to modify. The rule blocking executables that do not meet a prevalence, age or trusted list criterion is the one to approach carefully here, with a long audit period and a clear list of what must be permitted before anything moves to block.
A school or university with shared and lab devices
Shared machines see more script activity, more removable media and more unmanaged software than any corporate fleet. Blocking obfuscated scripts, blocking JavaScript or VBScript launching downloaded executables, and blocking copied or impersonated system tools all pay for themselves quickly, provided the antimalware scan interface and cloud protection prerequisites are actually in place.
How organisations actually run attack surface reduction.
| Feature | Managed ASR programme | Enabled once, never reviewed | Antivirus only |
|---|---|---|---|
Standard protection rules in block mode | Yes | Usually | No |
Remaining rules assessed in audit first | Yes | Rarely | Not applicable |
Cloud protection level chosen deliberately | Yes | No | No |
Alert dependency understood | Yes | No | Not applicable |
Exclusions documented and reviewed | Yes | No | Not applicable |
Server rules handled separately | Yes | No | No |
Warn mode used where supported | Yes | Rarely | Not applicable |
Rule drift detected | Yes | No | Not applicable |
New applications tested against the rules | Yes | No | Not applicable |
Blocks investigated rather than ignored | Yes | Sometimes | No |
What each rule blocks, and what it will break if you rush it.
| Rule | What it blocks | Deployment note | |
|---|---|---|---|
| Block abuse of exploited vulnerable signed drivers | Applications saving vulnerable signed drivers to the machine | Standard protection. It does not prevent loading drivers already present, so it is a forward-looking control | |
| Block credential stealing from the local security authority subsystem | Access to LSASS process memory, not the processes themselves | Standard protection, but not applicable if LSA protection is on. High audit volume, no warn mode | |
| Block persistence through WMI event subscription | Malware using WMI event subscriptions to survive reboots | Standard protection, but test heavily if you run Configuration Manager, whose client relies on WMI | |
| Block all Office applications from creating child processes | Word, Excel, PowerPoint, OneNote and Access spawning processes | Enforced only if Office is installed under Program Files. The most common source of line of business breakage | |
| Block Office applications from creating executable content | Office writing executable components to disk for persistence | Unaffected by Office install location. Limited exclusion support | |
| Block Office applications from injecting code into other processes | Code injection from Word, Excel, OneNote and PowerPoint | No warn mode. Requires an Office restart. Microsoft names BeyondTrust Privilege Guard and Heimdal security as incompatible | |
| Block Office communication application from creating child processes | Outlook spawning processes, including rules and forms exploits | Enforced only if Office is under Program Files. Limited exclusion support | |
| Block Win32 API calls from Office macros | Visual Basic for Applications calling Win32 APIs | Most organisations never need this even when they use macros. Depends on the antimalware scan interface | |
| Block executable content from email client and webmail | Executables, scripts and archives propagating from mail | Alerts only at High plus or Zero tolerance cloud protection. Applies to Outlook and popular webmail | |
| Block JavaScript or VBScript from launching downloaded executable content | Script downloaders fetching and running further payloads | Alerts only at High plus or Zero tolerance. Not supported on Server 2012 R2 or 2016 through Intune | |
| Block execution of potentially obfuscated scripts | Scripts with suspicious obfuscation properties, PowerShell included | Requires cloud-delivered protection and the antimalware scan interface. Legitimate packers cause noise | |
| Block executable files unless they meet prevalence, age or trusted list criteria | Unknown and low-prevalence executables | Requires cloud-delivered protection. Painful in engineering estates that compile their own binaries | |
| Block process creations originating from PSExec and WMI commands | Remote execution through PsExec and WMI | If you use Configuration Manager, Microsoft says do not enable this through other deployment methods | |
| Block Adobe Reader from creating child processes | Reader spawning processes after a document exploit | Alerts only at High plus or Zero tolerance. Limited exclusion support | |
| Block untrusted and unsigned processes that run from USB | Unsigned executables running from removable media | It does not block copying from the USB drive, it blocks the copied file running from disk | |
| Block use of copied or impersonated system tools | Duplicated or imposter copies of Windows system binaries | Low breakage in most estates, and a genuinely good catch for living off the land technique | |
| Block rebooting machine in Safe Mode | Commands such as bcdedit and bootcfg forcing a Safe Mode restart | Safe Mode remains manually accessible from the Windows Recovery Environment, so this is not a lockout | |
| Use advanced protection against ransomware | Files that resemble ransomware by client and cloud heuristics | Requires cloud-delivered protection. It also blocks files that do not yet have a positive reputation |
Five steps, and the audit period is not negotiable.
- 1
Establish the prerequisites and the current state
Cloud-delivered protection, cloud protection level, LSA protection, Credential Guard, antimalware scan interface, Office install location, and whether Configuration Manager is in the picture. We also record which rules are already configured, since most estates have a partial legacy configuration nobody documented.
- 2
Enable the three standard protection rules
Block abuse of exploited vulnerable signed drivers, block credential stealing from the local security authority subsystem where it applies, and block persistence through WMI event subscription with extra care in Configuration Manager estates. These carry the lowest breakage risk and the highest immediate value.
- 3
Run the remaining fifteen in audit
Across a representative population that deliberately includes the awkward machines, for long enough to cover a full business cycle including month end. Findings are attributed to applications rather than counted, because a count tells you nothing about whether the behaviour is legitimate.
- 4
Decide each finding, then promote in rings
Block anyway, exclude with a documented reason and review date, or fix the application. Then promotion ring by ring, using warn mode where the rule supports it, and going straight to block on the two rules that do not. Rollback defined before promotion rather than improvised during it.
- 5
Hand over as an operational control
Rule state reported alongside the rest of the endpoint posture, blocks reaching a queue somebody works, exclusions reviewed on a schedule, and new application onboarding including an ASR check. Without that last part the configuration decays quietly over about eighteen months.
What organisations ask about attack surface reduction rules.
Fifteen checks that prevent a reverted rollout.
Prerequisites
- Is cloud-delivered protection enabled everywhere?Three rules explicitly require it.
- What is your cloud protection level?Three rules only alert at High plus or Zero tolerance.
- Is LSA protection already on?It makes the credential stealing rule not applicable.
- Is Credential Guard deployed?Microsoft recommends it alongside LSA protection.
- Is the antimalware scan interface functioning?Two script rules depend on it.
Estate reality
- Is Office installed under Program Files?Two rules are enforced only if it is.
- Do you run Configuration Manager?Its client relies heavily on WMI.
- Any BeyondTrust Privilege Guard or Heimdal?Named incompatible with the Office injection rule.
- Any Quest Dirsync Password Sync?Microsoft documents an issue with the LSASS rule.
- Are Server 2012 R2 or 2016 machines in scope?They need modern unified solution onboarding.
Operations
- Who reviews audit-mode findings weekly?Unreviewed audit data is just storage.
- How does a user report a block?Warn mode changes what they see, where supported.
- Who approves an exclusion?And who reviews it six months later.
- Are rule states reported to anyone?Otherwise drift goes unnoticed.
- What is the rollback if a ring breaks?Decided before promotion, not during an incident.
The pages around this one.
Defender for Endpoint
The product that supplies central management, reporting and alerting for the rules.
Intune security baselines
Where rule configuration often lands, and how baseline drift is detected.
Defender Vulnerability Management
The weaknesses the rules make harder to reach, prioritised for remediation.
Find out whether your rules are blocking anything, and whether anyone would know.
Most estates we look at have a partial configuration nobody documented, at least one rule that cannot generate alerts at the current cloud protection level, and an exclusion list that has never been reviewed. All three are quick to establish and worth knowing.
Related Services
Explore more solutions that work great with this service
Defender for Endpoint
Business, Plan 1 or Plan 2, and what each actually gives you
Security Baselines
Why deploying one does not make you CIS compliant
Defender Vulnerability Management
Certificates, browser extensions and firmware, not just patching
Defender XDR
Eleven signal sources, one incident, and containment without a human
Ransomware Protection
Defender XDR and Sentinel-driven ransomware defense
Endpoint Security
Defender for Endpoint and Intune managed
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own
Microsoft Secure Score
Why part of your score is unreachable, and which points matter