The security settings management article argued what this channel is and the one rule that governs it: an Intune-enrolled device ignores it, so it exists to configure the machines Intune deliberately does not manage. This is the build. It is short, because the channel has few moving parts, but two of them are switches in different consoles that both have to be on, and the thing you are verifying at the end is not the same enrollment you verify anywhere else. A device can be onboarded, and Intune-managed, and still not enrolled into this channel, and knowing how to tell is most of the job.
The two switches
The channel turns on from both sides of the Intune-to-Defender connection, and neither side alone does anything. In the Defender portal, under Settings, Endpoints, Configuration Management, you set the enforcement scope, and it is set per platform rather than globally. Each platform can be enabled for all devices or for tagged devices only, and the labels on those switches are shown in Microsoft’s documentation mainly through screenshots, so confirm the exact wording in your tenant. What matters is the choice: begin with tagged devices, not all. Turning the channel on for every applicable device at once enrolls your entire unmanaged estate into a new configuration path in a single step, which is precisely the blast radius a pilot exists to avoid.
On the Intune side, under Endpoint security and Microsoft Defender for Endpoint, you enable the setting that allows Defender for Endpoint to enforce endpoint security configurations. Both switches must be on for a single policy to travel. If either is off, policy sits authored and assigned and simply never reaches the device, with no error that points at the cause. Domain controllers are a special case worth naming before you enable anything: their enablement is separate and depends on the Windows Server switch being on first, and firewall policies are not supported on them at all.
The tag that scopes it
When you scope enforcement to tagged devices, the tag is a specific string, MDE-Management, and a device is in scope only when it satisfies both conditions at once: its platform switch is on and it carries the tag. That intersection is the pilot control. You apply the tag the same four ways you apply any device tag, through the portal, a registry value, an Intune custom setting, or a dynamic asset rule, and the same discipline from the onboarding build applies here, one tagging authority per class of device. The dynamic asset rule path is the most convenient because it tags by attribute rather than by hand, but it is still in public preview, so treat it as a preview feature in a production rollout rather than a settled mechanism. One consequence to hold in mind: every device the channel enrolls gets a synthetic identity in Entra, and those count against your Entra device quota like any other object.
Authoring on the right platform
Policies for this channel must be authored on the platform named Windows. The Windows 10 and later platform is explicitly unsupported here, and a policy built on it will look correct and never apply, which is the single most common way a security-settings rollout stalls. The channel also carries only a subset of what Intune can express, and the subset is worth knowing before you design around it.
| Flows through the channel | Does not |
|---|---|
| Microsoft Defender Antivirus, its exclusions, and the Windows Security experience | Device Control (works only for Intune-managed devices) |
| Attack Surface Reduction Rules | Any other Attack Surface Reduction profile |
| Endpoint detection and response | Disk encryption |
| Firewall and firewall rules (not on domain controllers) | User-targeted assignment of any kind |
Two properties of the channel shape how you assign policy. Assignment filters are silently ignored, and targeting is to device objects only, never to users. So the clean way to drive it is a dynamic device group whose membership rule keys on the management type the channel stamps on its devices, which lets the group populate itself as machines enroll. Note that the Windows client and Windows Server populations split on the device operating-system attribute, and the rule that selects Windows deliberately excludes servers, so plan the client and server groups separately rather than expecting one rule to catch both.
What the channel creates, and what it needs
A device the channel manages gains a synthetic Entra identity and shows, in the Defender inventory, as managed by Defender rather than by Intune. The old prerequisite that such devices be hybrid-joined has been dropped, which widens where the channel can reach. What it still requires is a real Defender for Endpoint user license: a tenant holding only Defender for Servers does not qualify, even though servers are exactly the population you would most want to reach this way, and that gap catches people precisely where they expect help. Intune licensing is not required. The channel also has hard exclusions that no configuration works around: Server Core installations of 2016 and earlier, non-persistent VDI, Azure Virtual Desktop, and 32-bit clients are unsupported, and a device running PowerShell in Constrained Language Mode will not enroll. None of these are dealbreakers for the populations the channel serves, but each is a promise you should not make before checking it.
Proving enrollment
This is the part that separates a working channel from one that looks fine and does nothing. Enrollment into security settings management is its own state, distinct from sensor onboarding and distinct from Intune MDM enrollment, and it has its own status on the device, in the registry under the SenseCM key.
reg query "HKLM\SOFTWARE\Microsoft\SenseCM" /v EnrollmentStatusA successfully enrolled device reports a status that reflects active management. When it does not, the code is diagnostic, and a handful of values account for most of what you will see.
| EnrollmentStatus | What it means | What to check |
|---|---|---|
| 2 | Never enrolled | The device is not in scope: platform switch off, tag missing, or the intersection unmet. |
| 4 | Configuration Manager owns it | Turn off the Manage Security settings using Configuration Manager toggle so this channel can take over. |
| 8 or 44 | The Intune enforcement toggle is off | Enable the Intune-side switch; both sides have to be on. |
| 13, 14, 20, 24, 25 | Connectivity | The device cannot reach the enrollment endpoint; check egress and proxy. |
| 15, 16, 17 | Service connection point or tenant mismatch | An on-premises SCP or tenant-ID problem; verify the AD-side configuration. |
| 36, 37, 38, 40, 41, 43 | Directory sync, DNS, clock, or dual control plane | Entra Connect health, name resolution, time skew, or a device claimed by two control planes. |
Above the device, both consoles report on the policy itself. Intune shows per-policy and per-setting status through its reporting, and the Defender portal exposes the same policy across a set of tabs that name which settings applied and which devices received them. On the device, the applied antivirus and attack-surface settings are readable directly through the Defender preference cmdlet, which is the ground truth when the reports and the registry disagree. Two operational facts finish the picture. The channel checks in every ninety minutes, and initial enrollment can take up to a day, so a device that just came into scope is not broken because it has not reported yet. And when you cannot wait for the cycle, the Defender device page carries a policy sync action for devices this channel manages, which pulls policy in about ten minutes. There is no instant push on assignment, so do not design a test that assumes one.
Where this goes next
With onboarding done and this channel standing, every device in the estate now has both a sensor and a configuration path, whether or not Intune manages it. What neither build has touched yet is the content those channels carry. The antivirus and detection engine has a set of values that reward being chosen deliberately, and one setting in particular that has to be reconciled against the attack-surface rules before either is safe to pin. Tuning that engine is the next build.
Defender XDR
‹ Previous: [D 2.2] Security Settings Management: Configuring MDE Without Enrollment
Next: [D 2.3] Next-Gen Protection and EDR: Tuning the Engine ›
