Attack surface reduction rules work best with a staged rollout

In many of the tenants I review, attack surface reduction rules (ASR rules) turn out to be one of the most effective layers of defense in Microsoft Defender, and also one of the most misunderstood. Usually they are either not configured at all or switched on everywhere without much thought about the business impact. The second case tends to end with broken workflows and annoyed users. Getting it right means choosing the right ASR rules, mixing block and audit mode sensibly and, most of all, keeping an eye on what actually happens in your environment.

Some attack surface reduction rules belong in block mode from day one

Microsoft's own guidance is unambiguous about which ASR rules should run in block mode right from the start (Standard Protection). These are the ones I consider most critical:

• Block Office applications from creating child processes
• Block credential stealing from LSASS
• Block executable content from email and webmail
• Block abuse of exploited, vulnerable signed drivers
• Block process creations from PSExec and WMI commands

Each of them targets an attack technique that shows up again and again after initial compromise. Dumping credentials from LSASS and launching payloads through Office macros are still everyday tactics in the incidents I work on. Attackers keep getting through in environments where these controls are missing or only half rolled out.

Intune endpoint security policies handle ASR deployment at scale

With Intune's endpoint security policies, managing ASR rules across many devices is fairly simple. You get per-rule granularity, assignment targets and, importantly, the option to deploy individual rules in audit mode first (deployment guide). In my experience, even Microsoft's "safe" defaults occasionally clash with specialized business applications or IT tools. So for any rule where I'm not sure about the impact, I start in audit mode. Block mode is for rules you understand and have tested in your own environment. You also need clear policy documentation and a change-tracking process for exceptions.

Pro tip: If you run rules in audit mode and analyze the events with KQL or the built-in Defender ASR report, you catch problems early, before users get blocked or business processes stop working.

Audit events show what a rule would block

Whenever I roll out new ASR rules, I go through the audit events carefully. Under Reports, the Defender portal has a dedicated "ASR rules" report that you can filter by rule, action or device. When I need to dig into individual events, I use Advanced Hunting in Defender for Endpoint. This simple KQL query is a good place to start:

DeviceEvents
| where ActionType startswith "Asr"
| project Timestamp, DeviceName, ActionType, FolderPath, FileName, InitiatingProcessFileName, ReportId

It pulls out all ASR-related events, so you can see which apps or scripts a rule would hit before you move it to block mode. For details on how each rule behaves and how to deploy it, Microsoft's documentation is still the best source (rule reference).

Exceptions need to be as precise as possible

Sooner or later you will run into conflicts with legacy apps or IT tools. Each ASR rule can have its own exclusions in Intune, defined per file, per folder or even by file hash. I keep exclusions as narrow as I can, review them regularly and always write down why each one exists. I've seen tenants gut their own protection with broad "C:\Program Files" exceptions. The more precise your exclusions, the stronger your overall security posture.

Full ASR reporting and advanced hunting depend on your licence

This question comes up a lot. Advanced ASR reporting and event hunting require Microsoft Defender for Endpoint P2 or Microsoft 365 E5. Without one of them you can still enable most ASR rules through Defender Antivirus, but you won't get the deep telemetry or the hunting capabilities. If your security team cares about visibility and incident response, the higher license is rarely something you can skip.

I block what I can, audit the rest and revisit later

I push hard for running Microsoft's recommended ASR rules in block mode as early as possible. In practice, though, one configuration for everyone doesn't work, particularly in larger or more varied environments. My process looks like this. I look at existing exceptions and line-of-business apps, start in audit mode to collect real data, and switch to block mode once I'm confident. That's the most reliable way I know to shrink the attack surface without making life hard for users. If you want to see how this connects to other topics, I've written about Copilot for Microsoft 365 tenant readiness and Conditional Access best practices.

Keep in mind that every exclusion is a potential attack vector, so handle them carefully. ASR rules won't solve everything on their own, but in a layered endpoint defense I wouldn't do without them.

Before you move rules to block mode, it helps to understand how the pieces fit together: policy settings, event flow and exceptions. The diagram below shows these ASR interactions:

flowchart TD
    Policy["ASR policy in Intune"] --> Device["Windows device"]
    Device --> AuditEvent["Audit event (Defender for Endpoint)"]
    Device --> BlockAction["Block event (Defender for Endpoint)"]
    AuditEvent --> Report["ASR report portal"]
    BlockAction --> Report
    Policy --> Exception["Exception (file path/hash)"]
    Exception -.-> Device

Figure: How ASR policies, exceptions and reporting interact