Microsoft has quietly expanded the reach of its cloud-based endpoint security management. IT administrators can now apply Intune endpoint security policies directly to devices that are onboarded to Microsoft Defender for Endpoint – even when those devices are not enrolled in Intune and have no other mobile device management (MDM) relationship with the service. The change, which began rolling out broadly this month, eliminates a long-standing barrier for organizations that wanted to unify security configuration without fully committing every endpoint to Intune enrollment.

What just changed

Until now, Intune’s endpoint security policies – a set of configurations covering antivirus, disk encryption, firewall, attack surface reduction, and more – required devices to be enrolled in Intune. That meant either a classic full MDM enrollment or co-management with Configuration Manager. Defender for Endpoint could be onboarded to devices independently, but its own security management features were limited to the Windows Security app experience and a handful of settings.

The new capability, quietly documented in recent updates to Microsoft’s Intune guidance, changes the equation. Administrators can now target a subset of endpoint security profiles to devices based solely on their Defender for Endpoint registration. In practice, this means a device that has been onboarded to Defender – via a script, Group Policy, or other method – becomes a valid target for policies like Microsoft Defender Antivirus exclusions, Windows Firewall rules, and Attack Surface Reduction (ASR) rules in Intune, even though the device never shows up in the Intune device inventory as a managed device.

Microsoft describes this as an extension of the “Defender for Endpoint security settings management” feature. When an admin creates a security policy in the Microsoft Intune admin center and assigns it to a group, they can now designate the management authority as “Microsoft Defender for Endpoint” rather than “Intune.” Any device in that group that is not managed by Intune but is onboarded to Defender will then pull down the policy and enforce it. Note that this is not a full MDM takeover; only the specific security policies flow through. Separate device compliance, application deployment, and configuration profiles remain exclusive to Intune-enrolled devices.

What it means for you

For the growing number of organizations that live in a hybrid identity world, this is a practical win. Let’s break down the impact.

For IT administrators
The most immediate benefit is simplifying the security stack for devices that have historically been difficult to manage. Examples include:
- Servers (on-premises or in other clouds): Many organizations onboard servers to Defender for Endpoint but never enroll them in Intune because of management overhead or policy constraints. Now those servers can receive consistent antivirus exclusions and firewall rules without a full MDM enrollment.
- Contractor-owned or BYOD PCs: A contractor’s laptop that accesses corporate resources through Entra ID and is onboarded to Defender can now be forced to comply with a baseline set of attack surface reduction rules, without the user having to enroll their personal device in an MDM.
- Proof-of-concept and test environments: Security teams can pilot new Defender configurations on a handful of devices without standing up a complete Intune enrollment process.

Importantly, the policies applied through this channel take precedence over any local Group Policy settings when there’s a conflict, because they come from the cloud. This behaves like the “MDM wins over GP” conflict resolution model. Administrators should carefully audit existing Group Policy objects to avoid unexpected behavior.

For security decision-makers
The change supports the broader “shift left” in securing endpoints: get baseline protections in place before full device management is even considered. It also closes a gap that previously forced teams to maintain duplicate policy sets – one in Group Policy (or local script) for unenrolled servers and another in Intune for enrolled workstations. Now a single cloud policy can govern both, simplifying audits and change control.

For end users
There will be no visible change. The policies apply silently in the background. Users might notice that certain actions are blocked (e.g., a new ASR rule preventing macro execution in Office) where they weren’t before, but the experience is otherwise unchanged.

For developers and power users
If your organization embraces this, you may soon see security settings arriving on your development VM even if it was never “managed” in the traditional sense. That’s a good thing for reducing the attack surface, but be aware that some test or lab configurations might suddenly be locked down. Communicate with your security team before they flip the switch.

How we got here

The journey to this point has been a multi-year convergence of two Microsoft security pillars. Defender for Endpoint, originally released as Windows Defender ATP, has grown from a simple antivirus management add-on into a full XDR platform with its own security management channel. In parallel, Intune evolved from a basic MDM into a unified endpoint management solution that spans mobile, desktop, and IoT. The collision was inevitable.

In 2021, Microsoft introduced “security management for Microsoft Defender for Endpoint” in public preview, allowing a minimal set of antivirus and firewall policies to be deployed to Defender-only devices. But that feature was tied to a specific license (Microsoft 365 E5 Security) and could only manage devices running Windows 10 or later that had a specific version of the Defender agent. It also required enabling an Intune connector and configuring Entra Joined or Hybrid Joined state – a high bar for many brownfield environments.

Over the following two years, Microsoft gradually expanded the scope: more policy types, support for Windows Server, integration with the Intune admin center UI. The latest iteration removes the requirement for the device to be Hybrid Joined. A pure Entra Registered device (common in BYOD or contractor scenarios) that is onboarded to Defender can now receive the policies, provided the user has an appropriate license assigned.

This evolution mirrors the industry’s broader move away from perimeter-based device management. Zero Trust principles demand that every endpoint, regardless of enrollment status, adhere to security baselines. By decoupling security policy enforcement from full device management, Microsoft is responding to that demand without forcing organizations into a binary all-or-nothing Intune enrollment decision.

What to do now

If this capability is relevant to your organization, you’ll need to take a few deliberate steps. The configuration is not turned on by default.

1. Verify licensing
Your tenant must have one of the following licenses for each user of a targeted device:
- Microsoft 365 E5 or Microsoft 365 E5 Security
- Microsoft Defender for Endpoint Plan 2 standalone
- An equivalent education or government SKU that includes the Defender for Endpoint P2 entitlement

Licenses must be assigned to the users; device-based licensing is not supported for this feature.

2. Enable the Defender for Endpoint connector in Intune
In the Microsoft Intune admin center, navigate to Endpoint security > Microsoft Defender for Endpoint and set the connection status to “On.” This step enables the policy flow. If you already use Defender for Endpoint with Intune (for example, to enforce compliance based on threat levels), this connector is already live – no additional action needed.

3. Create a policy with the correct management authority
When creating any supported endpoint security profile – say, Antivirus or Firewall – you’ll now see a setting called “Manage (ConfigMgr)” or, for cloud-native assignments, a dropdown to choose the management authority. Select “Microsoft Defender for Endpoint” instead of “Intune.” (The exact UI label may vary slightly between tenants as the rollout continues.) Assign the policy to an Entra ID security group that contains the devices or users you want to target. Remember: the group can include devices that are not Intune-managed; they just need to be onboarded to Defender.

4. Test on a small set
Before deploying broadly, assign the policy to a pilot group of mixed devices – some Intune-managed, some Defender-only. Confirm that settings apply correctly on both. Use the “Devices managed by MDE” node under Reports > Endpoint security to monitor policy assignment. Check the local device logs under \Microsoft\Windows\Defender\ for evidence of applied policies.

5. Clean up legacy Group Policy conflicts
If your domain-joined devices currently receive antivirus or firewall settings through Group Policy, those settings will conflict with the cloud-delivered ones. Plan to either migrate those policies to Intune or document an explicit precedence rule. In most cases, the cloud policy will win, but inconsistent enforcement can lead to support tickets.

Watch for limitations. Not every endpoint security policy type is available for Defender-only management. As of this writing, supported profiles include Antivirus, Firewall, Attack Surface Reduction, and Endpoint Detection and Response (EDR) settings. Disk encryption (BitLocker) and Account Protection policies still require full Intune enrollment. Additionally, policy reporting for Defender-only devices shows a subset of information compared to fully managed devices; you won’t see detailed per-setting status for all policies.

Outlook

This move signals Microsoft’s intent to make security settings management a first-class citizen independent of device enrollment. Expect the list of supported policy types to expand over the coming months, potentially covering all endpoint security profiles. The long-term vision likely involves full parity between the Defender and Intune management channels, blurring the line between enrolled and merely onboarded devices.

More interestingly, this could be a stepping stone toward a future where Group Policy for security settings is gradually deprecated in favor of cloud-based baselines. Microsoft has already hinted at a “cloud-first, AI-powered” endpoint management strategy. For organizations still relying on on-premises Active Directory and Group Policy, now is the time to start experimenting with these cloud tools – even for servers – so you’re not caught off guard when the next chapter of Windows management arrives.