The awkward question the last article ended on has a precise answer. Security Settings Management is how you configure a device that is onboarded to Defender but not enrolled in Intune. It reaches the machines your design deliberately left outside Intune, the servers, the co-managed estate mid-migration, the boxes a third-party tool owns, and it delivers antivirus, endpoint detection and response, firewall, and attack surface reduction to them from the same Intune policies you use everywhere else. It is genuinely useful, and it is also the channel most often misread, because everything about it hangs on one precedence rule people tend to skip past.
The rule that governs everything else
An Intune-enrolled device ignores Security Settings Management completely. The documentation is blunt about it: a device managed by Intune does not process policies delivered through the security settings management channel. Enrollment wins, every time, and the channel only acts on the population that is not enrolled. This is the fact to internalize before anything else, because it dictates what the feature is for. It is not a second lever on a machine Intune already manages, and it is not a way to supplement or override enrolled-device policy. It is a lever for a different set of machines entirely. Miss this and you will spend an afternoon watching a correctly authored policy refuse to land on an enrolled device, when the truth is it was never going to. Same policy store, same portal, but the channel reaches only the devices Intune has left alone.
Two switches, both required
The channel does not turn on from one place. It needs enabling on both sides of the connection. In the Defender portal, under configuration management, you set the enforcement scope, and you set it per platform, either for all devices or scoped to devices carrying the MDE-Management tag. In Intune, you switch on the setting that allows Defender for Endpoint to enforce endpoint security configurations. Both must be on for a single policy to travel. The tag-scoped option is the one worth reaching for first, because it turns enforcement into something you can pilot: tag a small subset, prove the channel behaves, then widen, rather than enrolling your entire unenrolled estate into a new management path in a single afternoon. Treat the enforcement scope the way you would treat any assignment with real blast radius, because that is what it is.
What it will carry, and what it will not
On Windows the channel carries antivirus, including exclusions and the Windows Security experience, attack surface reduction rules, endpoint detection and response, and firewall with its rules. That is most of what you would want to push to a hardened but unenrolled machine. What it does not carry is Device Control, which appears in the portal but only functions for devices Intune actually manages, so do not design a removable-storage posture around delivering it through this channel. There is also a quieter trap that produces silent failures: policies bound for this channel must be authored as “Windows” platform profiles, not the “Windows 10 and later” profiles you use for enrolled devices. The two look nearly identical in the console, and the wrong one simply will not apply. This is exactly the sort of detail that turns a clean rollout into an afternoon of wondering why nothing landed.
The licensing gate that catches server-only tenants
The channel requires a genuine Defender for Endpoint user license. It does not require an Intune license, which is rather the point of the whole feature. But the exclusion catches people exactly where they expect help: a tenant that holds only Defender for Servers does not qualify, even though servers are precisely the population you would most want to reach this way. The licensing spine from the suite anchor reasserts itself here. Server coverage bought through Defender for Servers gets you the sensor and the protection on that server, but it does not unlock this configuration channel on its own. If Security Settings Management is central to how you plan to manage an unenrolled fleet, confirm the user licensing underneath it before you build the design on top of it.
The shape of what it creates
When a device is managed this way it gains a synthetic identity in Entra, its management type reads as MicrosoftSense, and it is shown as managed by Defender rather than by Intune, so it is at least legible in the inventory. But the mechanics underneath are coarser than the Intune experience, and the design has to account for that. Targeting is by device group only, and assignment filters are ignored, so the precise, attribute-based targeting you may lean on elsewhere is not available here. Devices check in every ninety minutes rather than continuously, with an on-demand policy sync available from the Defender portal when you cannot wait for the cycle. And the channel does not support non-persistent VDI or Azure Virtual Desktop, 32-bit clients, or older Server Core installations, and it will not behave under PowerShell Constrained Language Mode. None of these are dealbreakers for the populations the channel is meant to serve, but each is a constraint you want to know before you promise someone coverage it cannot deliver.
Where it belongs, and where it does not
The channel belongs on the deliberately unenrolled. Servers you manage centrally without putting them into Intune. A co-managed estate partway through a migration where some machines are not yet enrolled. Devices a third-party mobile-device-management tool owns, where you still want Microsoft’s security configuration underneath. In each of those the channel does something no other path does cleanly. Where it does not belong is as a way to double-manage enrolled devices, which the precedence rule forbids anyway, or on a population already owned by another channel. If Configuration Manager manages a box, turn off its management of security settings before this channel touches the same machine, or you have deliberately rebuilt the two-owners conflict the last article warned against. The rule does not change because the channel is new. One channel per population, chosen on purpose, still holds.
Where this leaves us
Between onboarding and this channel, every device in the estate now has a path in and a path to configuration, whether or not it is enrolled in Intune. What we have not yet looked at is what the configuration actually does once it arrives. Antivirus, endpoint detection and response, and the protection engine underneath them have settings that reward being understood rather than accepted at their defaults, and a few that quietly downgrade your posture if you leave them where a third-party tool put them. That engine is where we go next.
Defender XDR
‹ Previous: [D 2.1.1] Onboarding Defender for Endpoint: The Build
Next: [D 2.2.1] Security Settings Management: The Build ›
