Attack surface reduction is a family, not a feature, and it is the part of the protection stack that shrinks the ground an attacker gets to stand on. The Intune guide already taught the discipline of rolling these rules out, moving from audit to warn to block without breaking the business, and that ladder is its own article. This one goes underneath the ladder, into the current rule set, the rules you can safely turn on today, the exclusions that should be surgical rather than blunt, and the web-protection split that quietly decides what actually gets blocked once traffic leaves the browser.
Where the license line actually sits
The first thing to correct is a common assumption that the interesting hardening lives in Plan 2. It does not. The attack surface reduction family, the rules themselves, controlled folder access, network protection, web protection, the firewall, exploit protection, and device control, is enforced by Defender antivirus and is available from Plan 1 upward. What Plan 2 adds is the detection, correlation, and reporting around it, not the enforcement. This matters for design because it means an E3 tenant already holds a genuinely capable hardening layer, and the reason it so often goes unused is not licensing but nerve. The rules have a reputation for breaking things, which is exactly why the staged approach exists, and why the goal here is to be precise about which rules are safe now and which earn their audit period.
The three you can turn on today
Of the current set of nineteen rules, three are Microsoft’s standard-protection group and are safe to set to block across essentially any estate without an audit period, because they target behavior no legitimate software relies on. The first blocks abuse of vulnerable signed drivers, the mechanism behind a whole class of bring-your-own-driver attacks. The second blocks credential theft from the local security authority subsystem, the process attackers scrape for passwords. The third blocks persistence created through Windows Management Instrumentation event subscription, a favorite quiet foothold. These three are the floor, and there is little reason to run them in audit first. The remaining sixteen are the ones that deserve the full audit-to-block treatment, because they touch the ordinary behavior of Office, scripts, and line-of-business tools in ways that vary from estate to estate. Worth flagging before you plan the rollout: two rules, the credential-theft rule and the one blocking Office process injection, have no warn mode at all, only audit and block. That breaks the clean audit-to-warn-to-block ladder for exactly those two, so plan to move them from audit straight to block on evidence rather than easing through a warn stage that does not exist.
LSASS, and the claim to ignore
The credential-theft rule attracts more confusion than any other, partly because of a recurring story that Microsoft has quietly flipped it to block by default on its own. Set that story aside. The current documentation makes no such claim, and the version of it that circulated years ago was walked back. What the documentation does say points to a better design anyway. The credential-theft rule is a fallback, not the primary control. The primary control is LSA protection paired with Credential Guard, the platform features that wall off the credential store at a lower level, and where those are enabled the attack surface rule reports as not applicable because the stronger control has already made it redundant. So the correct posture is not to chase a rumored default. It is to enable the platform protections, treat the attack surface rule as the backstop for the machines that cannot run them, and stop waiting for a default that is not coming.
Exclusions should be surgical
Every audit period surfaces something legitimate that a rule wants to block, and the instinct is to add an exclusion. The instinct is fine; the blunt version of it is not. A global attack-surface-reduction exclusion applies to every rule at once, which means one over-broad path added to quiet a single false positive silently weakens all nineteen. Per-rule exclusions exist precisely to avoid this, letting you exempt a path from the one rule that flagged it while the rest stay at full strength, and they are the exclusion you should reach for by default. They are configured through Intune or Group Policy, not through the security settings channel, which is one more reason the enrolled estate is the easier place to run a tight attack-surface posture. And remember the hard dependency underneath all of it: every one of these rules requires Defender antivirus to be active with real-time protection on. A device that has slipped into passive mode is not enforcing a single attack surface rule, no matter how carefully you authored them, which ties this whole family back to the active-versus-passive decision from the previous article.
The traps worth knowing before you block
A few rules have specific, well-known ways of biting, and knowing them ahead of time is the difference between a controlled rollout and an outage. The rules covering Windows Management Instrumentation and process creation from PSExec can break Configuration Manager clients, because the management agent legitimately uses the very mechanisms those rules police, so audit them carefully anywhere ConfigMgr still operates. The Office process-injection rule requires an Office restart to take effect and is known to conflict with some privilege-management and security agents that inject by design. The aggressive ransomware-protection rule tends to false-positive on low-prevalence line-of-business applications, the bespoke tools that no reputation system has ever seen. And several server-scoped rules are simply not supported through Intune on Server 2012 R2 and 2016, so a policy that looks applied may not be enforcing there at all. None of these are reasons to avoid the rules. They are reasons to keep the audit period honest and to read the device configuration report rather than trusting that a green policy means a protected machine.
Controlled folder access, and honest expectations
Controlled folder access belongs to this family and deserves a candid word, because it is the member most often switched on with high hopes and quietly abandoned. It works as an allowlist protecting designated folders from unauthorized processes, and its intent, blunting ransomware’s ability to encrypt user data, is sound. The friction is real, though. It generates a high volume of false positives because ordinary applications write to protected locations constantly, PowerShell is never trusted automatically, and its visibility is poor, with no dedicated alert queue and events surfacing only in the timeline and logs. That combination makes it the least-deployed control in the family in practice. It can be made to work for a narrow, well-understood population, but it is not a set-and-forget control, and it should not be sold internally as one.
Web protection, and the split nobody explains
The part of this family the series can genuinely own is the web-protection architecture, because it is where Microsoft’s documentation is scattered and the real behavior surprises people. There are two enforcement engines, and which one acts depends on the browser. In Microsoft Edge, SmartScreen does the blocking, and it can block at the full URL path, the specific malicious page rather than the whole site. Everywhere else, in other browsers and in non-browser processes, enforcement falls to network protection, which operates at the level of domains and IP addresses only. Full-path URL blocking is an Edge capability, full stop, so a custom indicator naming a specific path behaves differently depending on where the traffic originates. Underneath both sits network protection as the substrate, and this is the detail that catches designs out: web content filtering and custom network indicators only enforce when network protection is set to block, not merely audit. Web content filtering also works at the level of parent categories, carries a couple of hours of propagation latency, and sits below custom indicators in precedence. Get network protection into block mode first, understand that the browser decides the granularity, and the rest of the web-protection story stops being mysterious. And note that this entire layer, like the rest of the family, is available from Plan 1.
From shrinking the surface to judging the device
With the engine tuned and the surface reduced, the endpoint is genuinely hardened. The last question in this block is what to do with the signal all of this produces, because a hardened device also generates a risk verdict, and that verdict can feed compliance and conditional access. Done well it closes the loop between endpoint security and access. Done carelessly it is the fastest way to lock your own users out of everything. That balance is the final article in the block.
Defender XDR
‹ Previous: [D 2.3.1] The Antivirus Policy, Setting by Setting
Next: [D 2.4.1] The Attack Surface Reduction Policy Set ›
