The attack-surface article argued the family and sent you to the Intune guide for the audit-to-block ladder itself. This build pins the rules to values, resolves the merge conflict from the attack-surface side, and wires the web-protection substrate that most designs leave half-connected. The whole family lives in one profile, and its power and its traps both come from the same place: these rules block real attacker behavior, and a handful of them block behavior that legitimate software also relies on, which is why some go straight to block and most earn an audit period first.
The profile and the modes
The rules are authored on the Windows platform in the Attack Surface Reduction Rules profile, which is also the only attack-surface profile that travels through the security-settings channel, so an unenrolled population gets the rules but not the other members of the family. Each rule takes one of four working states: block, audit, warn, or disabled, with a fifth option that leaves it not configured. Audit is where every rule that touches ordinary software should start, because it records what a rule would have blocked without blocking it, and warn adds a user-dismissible prompt on top of block. That ladder, audit to warn to block, is exactly what the Intune guide teaches, so this build assumes it and spends its attention on the values and the exceptions.
The three to block today, and the five that cannot warn
Three rules are Microsoft’s standard-protection group and go straight to block on essentially any estate without an audit period, because they target behavior no legitimate software depends on: the rule blocking abuse of vulnerable signed drivers, the one blocking credential theft from the local security authority, and the one blocking persistence through Windows Management Instrumentation subscription. Their identifiers begin 56a863a9, 9e6c4e1f, and e6db77e5, and Microsoft says plainly that the audit volume on the credential-theft rule is safe to skip. The other sixteen rules earn the full audit period.
The ladder has a gap worth planning around before you build it, and it is larger through Intune than the general documentation suggests. Two rules have no warn mode at all, only audit and block: credential theft and the Office process-injection rule. Through Intune specifically, three more cannot be set to warn, the rule for obfuscated scripts, the Windows Management Instrumentation persistence rule, and the advanced ransomware rule, even though Group Policy can warn on them. So on an Intune or security-settings build, five rules cannot ease through a warn stage and must move from audit straight to block on the evidence. Plan those five as a decision, not a gradient, and do not design a rollout that assumes every rule can be warned first.
For the sixteen audit-first rules, the discipline is the one the Intune guide sets out: audit for about thirty days, which is Microsoft’s stated window rather than the two-to-four weeks people often shorten it to, read the detections, and then flip to block starting with the rules that triggered least. Three rules also depend on cloud-delivered protection being on to function, including the prevalence-and-age rule and the advanced ransomware rule, which ties this build back to the antivirus one: if cloud protection is off, those rules are not enforcing regardless of the mode you set.
Exclusions, and the merge conflict from this side
When an audit period surfaces a legitimate application a rule wants to block, the exclusion you reach for is the per-rule exclusion, which becomes available on each rule once it is set to anything other than not configured. It exempts a path from the single rule that flagged it while every other rule stays at full strength. The blunt alternative, a global attack-surface exclusion, applies to all rules at once, so a single over-broad path added to quiet one false positive silently weakens the entire set. Reach for per-rule exclusions by default and treat the global list as something you almost never touch.
This is also where the conflict named in the antivirus build lands from the other side. Setting disable local admin merge to true, the prerequisite for locking the antivirus exclusion list, is documented on Microsoft’s own attack-surface page as the thing that makes these per-rule exclusions stop applying, with Intune and the security-settings channel named among the affected tools. The two pages do not reconcile, so the resolution is the one the antivirus build set out and it holds identically here: decide per population. Where you need per-rule attack-surface exclusions, do not enable the merge lock on that population. Where you enable the merge lock for the antivirus exclusion list, finish tuning the attack-surface rules so the population running the lock keeps in block only the rules that need no exclusion. And because the documentation contradicts itself rather than settling, confirm the live behavior in your own tenant before you commit either posture, rather than trusting either page alone.
Network protection, the hidden substrate
Network protection is not an attack-surface rule, but it is the substrate several other controls stand on, and its home in Intune is the antivirus profile rather than the attack-surface one, which is the first thing that trips people. It has its own three states, disabled, audit, and block, and the state that matters is block, because custom network indicators and web content filtering only enforce on non-Edge traffic when network protection is set to block. In audit it observes and reports but stops nothing. Turn it to block, confirm the device also has real-time protection, behavior monitoring, and cloud protection on, since network protection depends on all three, and you have laid the foundation the next two sections build on.
Web content filtering
Web content filtering rides that substrate, and it is enabled in two places. First the feature is switched on under the Defender advanced features, then the category policies are authored under the endpoint rules, where each policy names its blocked categories and its device-group scope. The categories are coarse, five parent groups rather than a granular list, and the scope is by device group only, not by user. Two behaviors belong in any design that uses it: changes take up to two hours to propagate, so it is not a control you test in real time, and the blocking granularity depends on the browser exactly as the concept article described, with Edge blocking through SmartScreen and everything else falling to network protection at the domain level. For that domain-level enforcement to see encrypted traffic, the QUIC protocol and encrypted client hello have to be disabled in the browsers, which is a policy decision to make deliberately rather than a box to tick.
Controlled folder access
Controlled folder access lives inside the attack-surface profile rather than beside it, and it carries the honest caveat from the concept article: it is the family member most often switched on with high hopes and quietly abandoned, because ordinary applications write to protected folders constantly and its visibility is poor. Build it the way it survives contact, in audit first, and read what it would have blocked through the block and audit events it writes before you consider enforcing on any population. For a narrow, well-understood set of machines it can be made to work. Sold to the whole fleet as a set-and-forget control, it generates noise and gets turned off.
Proving it
Two views tell you the rules are real. Centrally, the attack-surface report under the Defender endpoint reports shows detections, per-device configuration, and a place to add exclusions from what it caught, which is the console you live in during the audit period. On the device, the applied rules and their modes read straight out of the Defender preference cmdlet.
(Get-MpPreference).AttackSurfaceReductionRules_Ids
(Get-MpPreference).AttackSurfaceReductionRules_ActionsThe two arrays line up rule for rule, with each action reading as off, block, audit, or warn, so a device that claims to be enforcing your standard-protection trio shows those three identifiers set to block and nothing important sitting at audit that you meant to enforce. The Windows event log records rule activity as it happens, a block and an audit event under the Defender operational log, and advanced hunting queries the same signal at scale by filtering device events whose action type begins with the attack-surface prefix. The check that matters before you widen: your three standard rules are in block, your five no-warn rules have moved deliberately rather than been forgotten in audit, and network protection reads as block so the web controls beneath it are actually enforcing.
Where this goes next
The engine is tuned and the surface is reduced, which means every device in scope is genuinely hardened. The last build turns that hardening into an access decision, wiring the connector, the compliance policy, and the conditional access gate so a device’s own risk verdict governs what it can reach, carefully enough that the gate protects the estate instead of locking it out. That is the final build in the block.
Defender XDR
‹ Previous: [D 2.4] Attack Surface Reduction in Practice
Next: [D 2.5] Device Risk, Inventory, and the Compliance Loop ›
