How to Configure Attack Surface Reduction Rules in Microsoft Intune

Configuring Attack Surface Reduction (ASR) rules is one of the most effective ways to reduce your organization's exposure to common attack techniques—but only if those rules are properly deployed and maintained. This guide provides step-by-step instructions for setting up ASR rules through Microsoft Intune, from initial prerequisites through ongoing monitoring.

Quick answer

Setting up Attack Surface Reduction (ASR) rules in Microsoft Intune takes five steps: 

1. Verify prerequisites → 
2. Create an ASR policy → 
3. Configure rule modes (start with Audit) → 
4. Assign to a pilot group → 
5. Verify via Event Viewer and the Defender portal

This guide walks through each step in detail, plus how to monitor your ASR policies alongside other security controls using Prelude.

What are Attack Surface Reduction (ASR) rules?

Attack Surface Reduction rules are part of Microsoft Defender for Endpoint that help prevent the behaviors malware typically uses to compromise Windows devices. Think of them as guardrails that block risky actions like Office macros launching executables, scripts downloading files from email, or processes attempting to steal credentials from LSASS.

Each ASR rule can operate in one of four modes:

Microsoft maintains a complete reference of all ASR rule names and GUIDs—you'll need these specific GUID values when configuring rules via PowerShell, Group Policy, or MDM providers outside of Intune.

Prerequisites and support matrix

Before configuring ASR rules in Intune, verify that your devices and environment meet the necessary requirements. Platform support varies depending on your management approach and operating system version.

Supported platforms and management paths

ASR policies through Intune Endpoint Security support Windows 10 and Windows 11 devices. Windows Server (2016, 2019, 2022, and later) is supported when managed via Security Management for Microsoft Defender for Endpoint.

Defender Antivirus requirements

ASR rules require Microsoft Defender Antivirus as the primary antivirus in Active mode with real-time protection enabled. Some rules also require cloud-delivered protection and connectivity to Microsoft cloud services. Third-party antivirus solutions will prevent ASR enforcement.

Warn mode requirements and limitations

Warn mode is available on Windows 10/11 and Windows Server 1809+ with minimum Defender platform version 4.18.2008.9 and engine version 1.1.17400.5. When enabled, users see a notification and can bypass the block for 24 hours.

{{asr-callout-1="/internal/component-library"}}

How to create an ASR Policy in Intune

With prerequisites confirmed, you're ready to build your first ASR policy. The process involves creating the policy, configuring individual rule modes, setting exclusions, and assigning to device groups.

1. Create a new ASR policy

1. Navigate to Intune admin center → Endpoint security → Attack surface reduction
2. Click Create Policy
3. Select Platform: Windows 10, Windows 11, and Windows Server
4. Select Profile: Attack surface reduction rules
5. Name your policy descriptively (e.g., "ASR Rules - Pilot Group - Audit Mode")

This is the supported path for ASR configuration. Legacy Endpoint protection profiles have been superseded by this newer profile type.

2. Configure rule modes

Start conservatively: Enable all rules in Audit mode for your pilot group. This captures what would be blocked without disrupting users. After 1-2 weeks of audit data, you can selectively move low-noise rules to Block mode.

Here's a practical approach for common rules:

3. Configure exclusions (global vs per-rule)

Global exclusions apply to all ASR rules on a device through the "Attack Surface Reduction Only Exclusions" setting. Use these sparingly—they create broad security gaps.

Per-rule exclusions scope to specific rules via "ASR Only Per Rule Exclusions." When you set a rule to anything other than "Not configured," Intune presents the per-rule exclusion option. This is preferred because it maintains protection from other rules.

Input format tips:

• Use full file paths: C:\Program Files\App\tool.exe
• Folder paths work: C:\CustomApps\
• Environment variables are supported: %ProgramFiles%\Tool\
• Check Intune's UI for delimiter conventions (typically semicolons for multiple entries)

{{asr-callout-2="/internal/component-library"}}

4. Assign and deploy

{{asr-callout-3="/internal/component-library"}}

Recommended deployment rings:

• Ring 1 (Pilot): 10-50 champion devices, all rules in Audit mode
• Ring 2 (Expanded): Broader group, low-noise rules in Block mode
• Ring 3 (Production): Enterprise-wide, most rules in Block with targeted exclusions

Allow 1-2 weeks between ring expansions to gather data and refine configurations.

5. Verification and monitoring

After deploying ASR policies, verify they're working as intended:

Via Microsoft Defender portal:

• Navigate to Reports → Attack surface reduction rules
• Review the Detections tab for audit/block events
• Check the Configuration tab for per-device rule status

Via PowerShell (on individual devices):

Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions

Via Event Viewer:

• Open Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational
• Filter for Event ID 1121 (Block mode), 1122 (Audit mode), and 5007 (settings changed)

Via Prelude:

• Within the Monitor dashboard open Endpoint Management → Microsoft Intune → Policy Configurations
• Review each policy group by devices and associated recommendation

Best-practice recommendations

• Start with Audit everywhere. Don't skip this step, even for "obvious" rules. Your environment has unique line-of-business applications that might trigger unexpected blocks.
• Maintain a centralized exclusion register. Document every exclusion with owner, business justification, scope, and quarterly review dates. Exclusions are security debt—treat them accordingly.
• Communicate with end users. If you're using Warn mode, prepare users for toast notifications explaining the 24-hour bypass option. A simple email explaining "what this means and why it matters" prevents help desk calls.
• Keep Defender updated. Ensure Defender platform and engine versions stay current. Validate that cloud-delivered protection is enabled via Get-MpComputerStatus PowerShell cmdlet.

Monitoring ASR rules with Prelude

Configuring ASR rules correctly is half the battle. Maintaining that configuration as your environment changes is the other half.

Prelude provides continuous visibility into your Intune device compliance policies, including ASR rules. The platform surfaces:

• Which devices have Intune policies applied and which specific ASR rule groups are active
• Policy settings and recommendations for each rule (e.g., "Block executable content from email client is set to Warn, but should be Block on high-risk devices")‍
• Coverage gaps where ASR policies should be deployed but aren't

This constant monitoring sits alongside other critical controls like EDR deployment, antivirus status, and conditional access policies. Instead of manually auditing ASR configurations across your estate, Prelude gives you a unified view of whether your device compliance policies are up-to-date, properly configured, and deployed to expected devices.

When ASR rules drift from your intended configuration—whether through policy conflicts, dynamic group changes, or manual modifications—you see it immediately alongside the rest of your security control posture.

FAQs

Do ASR rules require Microsoft Defender Antivirus as primary?

Yes. Defender AV must be in Active mode with real-time protection enabled. Third-party AV solutions cause Defender to disable itself, preventing ASR enforcement.

How long does Warn mode bypass last?

24 hours per event. After the bypass expires, users must approve the action again if it's still being blocked.

Which rules don't support Warn in Intune?

Three rules: 

1. JavaScript/VBScript downloaded executable launch,
2. WMI event subscription persistence, and 
3. Advanced ransomware protection.

Can multiple ASR policies target the same device?

Yes. Nonconflicting settings merge into a superset. Settings that conflict are withheld, which can appear as "not applied" in reporting. Consolidate conflicting settings into a single policy when possible.

How do I validate ASR rules are working on a device quickly?

Run Get-MpPreference in PowerShell or check Event Viewer for Event IDs 1121/1122. Both methods confirm active rules and their modes. Additionally, Prelude Monitor provides visibility into currently deployed policies, their included rules, impacted devices, and their associated users.

Can I manage ASR on Windows Server?

Yes, when the server is managed via Security Management for Microsoft Defender for Endpoint. Note that some rules have platform limitations (e.g., Block Webshell creation applies only to Exchange role on Server 2016).