ASR rules are one of the highest-value security controls available in a Microsoft Defender environment. They’re also one of the easiest ways to break legitimate applications if you deploy them without understanding what you’re doing. The staged approach – Audit, then pilot Block, then production Block – isn’t optional.
OIB ships all ASR rules in Audit mode by default. That’s deliberate. This article covers why the staged approach matters, how to read the audit data, and how to decide when a rule is ready to promote to Block.
What ASR rules actually do
Attack Surface Reduction rules target specific behaviors that malware commonly uses – not specific malware signatures, but the techniques. Blocking Office applications from spawning child processes. Blocking executable content from email clients. Blocking credential stealing from LSASS. Blocking scripts from running when they’ve been downloaded from the internet.
The problem is that some of these behaviors also occur in legitimate line-of-business applications. An application that calls a script from a downloaded installer. A custom tool that spawns PowerShell. An older application that interacts with LSASS for authentication purposes. None of these are malware, but some ASR rules in Block mode will stop them cold. That’s why the audit phase exists – to find these collisions before they become production incidents.
The three modes
Each ASR rule can be set to Not Configured, Audit, Warn, or Block. Not Configured leaves the rule off. Audit logs what would have been blocked without actually blocking anything – the rule is fully active for telemetry purposes, users see nothing. Warn blocks the behavior but gives the user a notification with the option to bypass the block for 24 hours. Block enforces the rule without override.
Three rules do not support Warn mode when configured through Intune: Block JavaScript or VBScript from launching downloaded executable content, Block persistence through WMI event subscription, and Use advanced protection against ransomware. If you set any of these to Warn in Intune, they’ll behave as Block. There’s no middle ground for these three – it’s Audit or Block.
Warn mode is useful for rules where you want enforcement with a user escape hatch. But don’t assume all rules support it – three don’t, and they’ll block silently if you configure them as Warn.
The audit phase
Deploy OIB’s ASR policy in Audit mode to your pilot group and leave it there for a minimum of two weeks. Four weeks is better. The goal is to capture enough real usage to surface any LOB application conflicts before you promote rules to Block. A two-week window will miss anything that happens on a monthly cycle – month-end processes, quarterly reports, applications that only run periodically.
If you’re in an environment with ConfigMgr co-management or a ConfigMgr client still present, Microsoft recommends 60 days of audit before promoting ASR rules that interact with CcmExec.exe. The ConfigMgr agent has behaviors that some ASR rules flag as suspicious. Promote too early and you’ll block ConfigMgr operations.
During the audit phase, the data you need lives in the Microsoft Defender portal – not in Intune. Go to Reports → Attack Surface Reduction Rules. The report shows which rules are generating events, how frequently, and on which devices. Look for rules generating high event volumes against the same file paths or processes. High volume against a consistent pattern usually indicates a legitimate application conflict. High volume with no consistent pattern usually indicates the rule is doing its job against genuinely suspicious behavior.
Reading the audit data
The ASR report surfaces the file, process, or behavior that triggered the rule, the rule that was triggered, and the device it happened on. For each high-volume event, ask three questions: Is this a known application? Is it expected behavior for that application? Would blocking it break something users need?
If the answer to all three is yes – known app, expected behavior, blocking would cause a problem – you need an exclusion before promoting that rule. ASR supports per-rule exclusions, which let you exclude specific file paths, processes, or folders from individual rules rather than disabling the rule entirely. Use per-rule exclusions rather than global Defender exclusions – global exclusions turn off protection across all Defender features for the excluded item, which is a much larger surface than you want to open.
If the answer to the first question is no – you don’t recognize the application generating the event – that’s worth investigating before you add an exclusion. Unrecognized processes triggering ASR rules in audit mode may be exactly what ASR is designed to catch.
Promoting rules to Block
Don’t promote all rules to Block simultaneously. Promote them individually or in small groups, starting with rules that generated little or no audit activity. Low-noise rules in audit are low-risk to promote. High-noise rules need exclusions in place before promotion.
The promotion sequence I follow: identify quiet rules from the audit data, add those rules to a separate Block policy assigned to the pilot group alongside the Audit policy, observe for a week, then expand Block to production. Leave the Audit policy in place – it continues to provide telemetry for any rules still in Audit mode and catches new application conflicts as your environment changes.
Some rules are high-value and low-noise in almost every environment – Block credential stealing from LSASS and Block executable content from email clients are examples. Others are more environment-specific – Block Office applications from creating child processes generates significant noise in environments where users work with Office macros or automation tools. Don’t assume a quiet rule in one environment will be quiet in another.
Ongoing management
ASR rules are not set-and-forget. Applications change. New software gets deployed. Users bring in tools that trigger rules that were quiet before. Keep the Defender portal ASR report in your regular monitoring rotation – monthly at minimum, weekly if you’re actively making changes to your application environment.
When new OIB versions ship, check the changelog for ASR rule changes. A rule that ships new or changes behavior in a new OIB version needs to go back through the audit cycle before promoting to Block. The version number in the OIB policy name tells you which policies have been updated – that’s the trigger to review.
Document your exclusions. An exclusion added to fix a problem in 2024 may no longer be necessary in 2026 when the application that required it has been replaced. Undocumented exclusions accumulate and create gaps that nobody can explain. Keep a record of every exclusion: what it covers, why it was added, and when it was last reviewed.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.3.1] BitLocker: Designing Encryption Policy That Works
Next: [5.4] Defender for Endpoint: The Security Layer That Connects Everything ›
