Managing Defender settings on devices not enrolled in Intune: security settings management explained

Not every device that runs Defender for Endpoint can enrol in Intune: domain-joined servers, Linux boxes, workstations still owned by Configuration Manager. Security settings management closes that gap by letting the Defender for Endpoint sensor itself fetch and enforce Intune endpoint security policies. In this post I'll explain how the feature works, switch it on in both portals, deploy a policy, and cover the pitfalls that generate most of the confusion: devices in two places, duplicate Entra objects and conflicting Group Policy.

How it works#

When a supported device onboards to Defender for Endpoint, the sensor checks whether the device already has an Intune (MDM) enrollment. If it doesn't, and the device falls inside the enforcement scope you configure, the device enrols with Intune through the Defender for Endpoint channel instead. Intune still needs a Microsoft Entra device object to target policy at, so:

• A device that is already fully registered (for example Microsoft Entra hybrid joined) uses its existing registration.
• A device that isn't gets a synthetic device identity in Microsoft Entra ID. Since June 2023 this replaced the old hybrid join prerequisite that caused so many enrollment errors. If the device later completes a full registration, the synthetic one is removed and management carries on.

From then on the device checks in with Intune every 90 minutes, Defender for Endpoint enforces whatever it receives, and status flows back to both the Microsoft Intune admin center and the Microsoft Defender portal. One important rule: a device that is enrolled in Intune does not process security settings management policy; it gets the same policy types through normal MDM. The policies are the same objects either way, so one antivirus policy can cover both populations.

Supported profiles vary by platform:

Windows support covers Windows 10 and 11 Professional and Enterprise (with the required cumulative updates), Windows Server 2012 R2 and 2016 running the modern unified agent, Windows Server 2019, 2022 and 2025, and domain controllers if you enable them separately. Not supported: Server Core 2016 and earlier, non-persistent VDI and Azure Virtual Desktop, and 32-bit Windows. macOS and Linux need recent agent builds (101.23052.0004 and 101.23052.0009 respectively, or later).

Prerequisites#

• A Defender for Endpoint licence (a standalone or suite subscription; Defender for Servers through Defender for Cloud alone isn't enough). The licence also unlocks the Endpoint security node in Intune, so you don't need an Intune licence for these devices.
• Security Administrator (or the Defender permission Manage security settings in Security Center with visibility of all device groups) for the Defender portal, and the Intune Endpoint Security Manager role for the Intune side.
• Network access from devices to *.dm.microsoft.com for enrollment, check-in and reporting.
• PowerShell not locked to Constrained Language Mode; the feature doesn't work on devices where it is.

Step-by-step#

1. Set the enforcement scope in the Defender portal#

Go to Settings › Endpoints › Configuration management › Enforcement scope. Turn on each platform you want to manage (Windows client, Windows Server, Linux, macOS), and for a pilot choose On tagged devices, then tag your test devices with MDE-Management. Switching a platform to all devices later enrols every in-scope device automatically. On the same page, decide whether Configuration Manager stays authoritative for its clients (the Manage security settings using Configuration Manager toggle) and whether domain controllers are included.

2. Allow it in Intune#

In the Microsoft Intune admin center, open Endpoint security › Microsoft Defender for Endpoint and set Allow Microsoft Defender for Endpoint to enforce Endpoint Security Configurations to On. This is separate from the connector toggle that shares risk scores with compliance.

3. Confirm devices enrolled#

Most devices enrol within minutes, but allow up to 24 hours. In the Defender device inventory the Managed by column should read MDE and the device page should show MDE Enrollment status: Success. In Intune, Devices › All devices lists the same devices with Managed by showing Microsoft Defender for Endpoint.

4. Build device groups#

Target policies at Microsoft Entra device groups, not users, since user targeting isn't supported for these devices. Microsoft recommends dynamic groups on the platform attribute deviceOSType (values Windows, Windows Server, macOS, Linux) so a device keeps its policy if it later enrols in Intune. If you need a group of only Defender-managed devices, use managementType equal to MicrosoftSense. The old MDEManaged and MDEJoined system labels were retired in September 2023, so update any rules still using them.

5. Create and assign the policy#

From Intune: Endpoint security, pick the policy type, Create policy, choose the Windows, macOS or Linux platform (profiles for the Windows 10 and later platform aren't supported here), configure settings and assign the device group. From the Defender portal: Endpoints › Configuration management › Endpoint security policies › Create new policy; it's the same wizard with Defender permissions instead of Intune ones, minus scope tags and assignment filters.

Verify#

Devices check in every 90 minutes; to hurry one along, open the device in the Defender inventory, select More actions › Policy sync, and expect the policy within about 10 minutes. Then check three places:

• Intune: open the policy under Endpoint security and use View report and Per setting status to see success, error and conflict counts, including which other policy manages a conflicting setting.
• Defender portal: the policy page under Endpoint security policies shows applied devices, assigned groups and per-setting status; the device page has a Security policies tab under configuration management.
• On a Windows device: Get-MpPreference shows the Defender Antivirus values that actually landed.

Get-MpPreference | Select-Object DisableRealtimeMonitoring, CloudBlockLevel, PUAProtection,
    ScanScheduleDay, SignatureUpdateInterval

Tips and gotchas#

• Device shows in both portals. That's expected: an enrolled device appears in Defender, Intune and Entra. What matters is the Managed by value. If it says Intune, the device is MDM-enrolled and ignores this channel.
• Duplicate Entra objects. A synthetic registration counts as one device object against Entra quotas. When a device later hybrid joins or Entra joins, the synthetic object is removed automatically; if you see lingering duplicates, check whether the device's full registration actually completed (dsregcmd /status).
• Group Policy and Configuration Manager conflicts. Manage each setting from one channel. Turn the Configuration Manager toggle off if Intune policy should win, and consider the Controlled Configuration (Device) setting in the Windows Security experience profile: set to Controlled Configuration (On), Intune-delivered settings take exclusive precedence over Group Policy and Configuration Manager.
• Assignment filters are ignored for Defender-managed devices, even if you add them. Use group membership instead.
• Some settings aren't supported through this channel, including the EDR Expedite telemetry reporting frequency, AllowIntrusionPreventionSystem and AllowLocalPolicyMerge. Firewall policies aren't supported on domain controllers.
• Removing a device from Devices › All devices in Intune or from the configuration management scope in Defender propagates to the other service, and existing Defender settings stay on the device after it leaves scope.

References#

• Use Intune to manage Microsoft Defender settings on devices that aren't enrolled with Intune
• Manage endpoint security policies in Microsoft Defender for Endpoint