The protection-engine article argued which of these settings are dials rather than switches and where each should land. This pins them. Most are a single deliberate choice made once, and they are gathered here as values with the reason attached. Two need more than a value. One is the sample-submission setting, where the instinct that feels like caution quietly weakens the engine. The other is a single setting that buys the highest-value hardening in the whole build and, by Microsoft’s own documentation, collides with the attack-surface rules in the next build. That collision is real, it is current, and it is the reason these two sheets have to be read together.
Where the settings live now
The antivirus configuration is spread across a few profiles on the Windows platform: the Microsoft Defender Antivirus profile, a dedicated exclusions profile, the Windows Security experience profile, and the update-controls profile. Since Microsoft moved these to the settings-catalog format in 2022, the console no longer presents the friendly, sentence-long setting names people remember, and the authority for what a setting is actually called and what its values mean is the Defender configuration service provider, not the old profile. This matters for a build sheet because the deprecated profile still floats around with names like turn on cloud-delivered protection, and matching an old name to a new setting is how you end up pinning the wrong thing. Where the values below name a setting, they name the current one.
The cloud engine
The core of modern antivirus is the cloud, and the settings that govern it are the ones most worth getting right. Each of the following defaults to a reasonable value, but several default to a value you should pin explicitly rather than inherit, because an unpinned setting is one a local change can move.
| Setting | Value | Why |
|---|---|---|
| Cloud protection | Enabled, pinned | Defaults to on, but pin it. Block at First Sight, tamper protection, attack surface reduction, and detection-and-response in block mode all depend on it. |
| Cloud block level | High | A false-positive dial, not a maximum. High is the balanced posture. The tiers above it block on thinner evidence and generate help-desk tickets in exchange for marginal coverage. |
| Cloud extended timeout | 50 seconds | Adds to the ten-second base, giving the cloud enough time to render a verdict on an unfamiliar file rather than releasing it early. |
| Sample submission | Send safe samples (the default) or send all | Block at First Sight is satisfied by the default. Setting it to do not send is the one value that silently breaks the feature. Sending all broadens coverage on script and phishing payloads; weigh it against your data-handling posture rather than treating either as mandatory. |
| Real-time, behavior, and on-access protection | Enabled, pinned | All default to on. Pin them so a local administrator cannot quietly turn the engine off. |
| Potentially unwanted application protection | Block (audit first on a brownfield estate) | Blocks adware and bundleware that is not quite malware. On an estate with unknown software, run it in audit first and read what it would have caught before you enforce. |
The sample-submission row deserves the extra sentence it gets, because it is where a privacy instinct does security harm. Block at First Sight, the capability that holds a never-before-seen file while the cloud decides, depends on samples being submitted. The default sends what Microsoft classifies as safe samples and keeps the feature working. The only setting that breaks it is do not send, which people reach for thinking they are tightening something. They are not. They are turning off the part of the engine that catches the file nothing has seen before.
The exclusion list, and the lock that protects it
Exclusions are expressed through three settings, for excluded paths, extensions, and processes, and they live in both the antivirus profile and the dedicated exclusions profile. Their values merge: a device applies the superset of every exclusion that any applicable policy defines, which makes a separate, tightly-governed exclusions profile a sound way to keep that superset visible and reviewed rather than scattered. The reason to govern the exclusion list so carefully is that it is a list of blessed blind spots, and it is one of the first things a capable attacker edits. Which is why the highest-value hardening in this entire build is not a detection setting at all. It is locking the exclusion list so that even a local administrator cannot add to it.
Tamper protection, set through the Windows Security experience profile and on by default tenant-wide, protects the engine’s core toggles from being switched off. Extending that protection to the exclusion list itself is a separate step with specific conditions, all of which must hold: the Defender platform version must be at least 4.18.2211.5, the device must be managed by Intune alone or by Configuration Manager alone through the Defender sensor, the exclusions must be managed by that same channel, and the setting named disable local admin merge must be set to true so that locally-added exclusions no longer merge into the managed list. When those conditions are met, the exclusion list becomes tamper-protected, which you can confirm on the device by reading the features registry key, where a value of one on the exclusions entry means the lock is active. This is the setting most tenants never turn on, and it closes a door that is standing open almost everywhere.
One setting, two builds
Here is the collision, stated plainly, because it is the kind of thing you find out about after it has already changed your posture. Disable local admin merge set to true is a documented prerequisite for the tamper-protected exclusion list above. It is also, per a separate and equally current Microsoft page, the setting that causes attack-surface-reduction per-rule exclusions to stop applying. That page does not carve out centrally-managed exclusions; it names Intune and the security-settings channel among the tools whose per-rule and local attack-surface exclusions no longer apply once the merge setting is true. Both statements are live, and neither is qualified in a way that dissolves the tension. On the same device you cannot, by the documentation as written, hold both a tamper-protected antivirus exclusion list and functioning per-rule attack-surface exclusions.
So this is a decision, not a default, and it is made per population. Where the antivirus exclusion lock matters most, a high-value server tier, a population an attacker would target the exclusion list on, set disable local admin merge to true and design the attack-surface rules on that population so they do not depend on per-rule exclusions, which in practice means completing the audit-to-block tuning of those rules before the lock goes on and keeping in block only the rules that need no exclusion. Where per-rule attack-surface exclusions are load-bearing, leave the merge setting off and accept that the exclusion list is not tamper-locked on that population. What you should not do is pin the merge setting on a whole estate because one build sheet told you to, and discover weeks later that attack-surface exclusions you were relying on silently stopped applying. Because the two Microsoft pages contradict each other rather than resolve, verify the current behavior in your own tenant before you commit either posture across a population, and treat this as one of the settings that has to be lab-confirmed rather than read. The attack-surface half of this decision is the next build.
Remediation and retention
Two smaller settings finish the antivirus posture. The default action taken on a detected threat is set per severity level, and the defensible pin is to quarantine at every severity rather than leaving a lower band on a weaker action, which also has the benefit that ignore and none cannot even be selected once tamper protection is on, so a hardened device forecloses the sloppy choice for you. And the retention period for cleaned malware defaults to zero, which reads like a sensible default and is not: zero means indefinite. Set it to a real window, sixty to ninety days, so that quarantined artifacts age out on a schedule instead of accumulating forever on every endpoint.
Proving the engine
The device tells you its real state through one cmdlet, and it is the ground truth when the portal and the policy reports disagree.
Get-MpComputerStatus | Select-Object AMRunningMode, RealTimeProtectionEnabled, IsTamperProtected, AntivirusSignatureLastUpdatedThe running mode is the single most important field. On a device where Defender is your active engine it reads as normal; where a third-party antivirus has pushed it aside it reads as passive, and in passive mode the whole attack-surface layer is off no matter how carefully you authored it. Tamper protection and real-time protection should both read as enabled, and the signature timestamp should be recent. For the exclusion lock specifically, confirm the features registry value discussed above reads as protected. And to prove cloud protection and Block at First Sight are genuinely working rather than merely configured, Microsoft hosts a harmless test file that a correctly configured engine blocks on download; use the current cloud-protection demonstration page for the exact file and procedure rather than an older link, because the test artifacts have moved. The check you are making is concrete: the engine is active, its exclusion list is locked, and it blocks a cloud-verdict file end to end.
Where this goes next
The engine is tuned, and one decision inside it is deliberately left half-made, waiting on the attack-surface build to complete it. That build takes the nineteen rules from the audit-to-block discipline into the specific values, the exclusions that must be surgical, and the merge conflict resolved from the other side. It is where we go next.
Defender XDR
‹ Previous: [D 2.3] Next-Gen Protection and EDR: Tuning the Engine
Next: [D 2.4] Attack Surface Reduction in Practice ›
