A channel now points at the device, and the question becomes what it should carry. The protection engine is where most of the real posture lives, and it is also where the defaults deserve the most scrutiny, because a few of them are dials rather than switches and one of them, left where a third-party product put it, quietly turns your best endpoint into your weakest. This is not a settings tour. It is the handful of decisions inside the antivirus and detection engine that actually change the outcome, and the reasoning for where each one should land.
Cloud protection is the engine, not an add-on
The single most consequential antivirus setting is cloud-delivered protection, and the name has changed enough times that people lose track of what it is. The old MAPS and SpyNet labels are retired; this is now simply cloud-delivered protection, and it is the difference between an engine that reasons only from local signatures and one that queries Microsoft’s live intelligence in real time. Sitting on top of it is Block at First Sight, the capability that holds a never-before-seen file for a few seconds while the cloud renders a verdict, and Block at First Sight depends entirely on sample submission. Set sample submission to “do not send” and you have not tightened anything, you have silently disabled the feature that catches the novel file. The submission options run from send safe samples, which is the default, through send all samples, to do not send. Microsoft recommends send all, and for phishing and script-based payloads that recommendation is well founded, because those are exactly the files the local engine has never seen. The instinct to send less in the name of privacy is the instinct that leaves the newest threats to walk in unexamined.
The cloud protection level is a dial, not a maximum
Near cloud protection sits a setting that reads like an invitation to turn everything to eleven, and doing so is a mistake. The cloud protection level, offered in Intune as not configured, high, high plus, and zero tolerance, is a false-positive dial. It governs how aggressively the cloud blocks on thin evidence, and each step up trades a little more of your users’ productivity for a little more suspicion. Zero tolerance blocks all unknown executables, which sounds like security and behaves like a help desk incident. The defensible posture for almost every estate is the default level paired with an extended cloud block timeout, moving the window the client will wait for a verdict up from its ten-second default toward the sixty-second ceiling. That combination gives the cloud enough time to decide without punishing every unfamiliar but legitimate binary your business runs. Reserve the aggressive levels for a genuinely high-assurance population, and even then, watch what they cost before you widen them.
Passive mode is a decision, not an accident
The most expensive misunderstanding in this whole area is passive mode, because it usually happens to you rather than being chosen. On a Windows client, the moment a non-Microsoft antivirus registers itself and the device is onboarded to Defender, Defender antivirus steps back into passive mode automatically. In passive mode it will still run a scan you ask for and still feed detection and response, but it stops doing real-time protection, and with it go network protection, attack surface reduction, and custom indicators. Those capabilities are not degraded in passive mode, they are simply off. Servers behave differently and do not enter passive automatically, which is its own trap in the opposite direction, because a server can end up with two active engines fighting unless you set it deliberately. The architectural point is the same in both directions: whether Defender is your active engine is a decision with real security consequences, and the defensible default, wherever your licensing and your third-party contracts allow it, is to run Defender antivirus active and let the whole protection stack come with it.
EDR, and the reconciliation people trip on
Endpoint detection and response is the Plan 2 half of the engine, the assume-breach layer that watches behavior in near real time, turns alerts into incidents, and feeds the automatic attack disruption that the suite anchor described. It is not an auditing tool, and it is worth saying so plainly, because it throttles repeated events by design and will not serve as a complete event log. When you are running a third-party antivirus and Defender has dropped to passive, there is a backstop worth knowing: endpoint detection and response in block mode lets the detection engine remediate malicious artifacts the passive antivirus saw but did not act on. This is where a genuine documentation contradiction confuses people, so here is the reconciliation. The compatibility table says cloud-delivered protection does not run in passive mode, and that is true of the antivirus engine forming its own verdicts. Detection and response in block mode still requires the cloud protection setting to be enabled, because it is the detection component, not the passive antivirus, acting on the cloud’s verdict. The two statements describe different components, and both are correct. The takeaway is unchanged: block mode is a post-breach safety net for a passive posture, not a substitute for running the antivirus active in the first place.
Automation you most likely already have
Automated investigation and remediation is the part of Plan 2 that does the work you would otherwise do by hand at two in the morning, triaging an alert, walking the artifacts, and remediating the files, processes, and tasks that turn out to be malicious. The setting that governs how far it goes on its own is the automation level, and there is a good chance yours is already where it should be. Tenants created since the middle of 2020 default to full automation, which lets the platform remediate without waiting for a human to approve each step. Older tenants default to semi-automatic and are often left there out of an abundance of caution that has long since stopped being warranted. Unless you have a specific reason to keep a hand on every remediation, full automation is the modern posture, and confirming your tenant is actually set to it is five minutes well spent, because the difference is whether the platform contains a fast-moving incident while you sleep or waits politely for you to wake up.
Tamper protection, and the lock most tenants never set
Tamper protection stops an attacker who has gained a foothold from simply switching your defenses off, and it is on by default now through built-in protection, guarding real-time protection, cloud protection, behavior monitoring, and signature updates from being disabled locally. That much you likely already have. What most tenants never turn on is the part that earns its place in a design paper: with tamper protection managed through Intune or Configuration Manager, you can extend the lock to the antivirus exclusion list itself. The exclusion list is one of the first things a capable attacker edits, because an exclusion is a blessed blind spot, and on most endpoints it is completely unprotected. Locking it, which requires a recent platform version and disabling local admin merge, closes a door that is standing open in the large majority of environments. It is worth noting what cannot do this: Group Policy cannot manage tamper protection at all, which is one more quiet force pushing serious hardening toward Intune and the security settings channel. Confirm the state on a device with Get-MpComputerStatus and its IsTamperProtected value, and if you need to make a legitimate change, do it through time-boxed troubleshooting mode rather than by weakening the control. Of everything in this article, the locked exclusion list is the highest-value setting that almost nobody has enabled.
What the engine does not cover
Tuned properly, the engine prevents, detects, remediates, and resists being switched off. What it does not do by itself is shrink the ground an attacker gets to stand on in the first place. That is the job of attack surface reduction, a family the Intune guide already introduces as staged enforcement and which this series takes considerably further, into the current rule set, the exclusions that should be surgical rather than blunt, and the web-protection split that decides what actually gets blocked outside the browser. That is where we go next.
Defender XDR
‹ Previous: [D 2.2.1] Security Settings Management: The Build
Next: [D 2.3.1] The Antivirus Policy, Setting by Setting ›
