Defender for Endpoint vs. Intune: Who Actually Manages the Device?

The first version of this post told you to offboard a device from Defender for Endpoint and then enroll it in Intune. I've since watched people follow that advice and turn off EDR on perfectly healthy machines for no reason, so let's fix it.

Short version: you don't move a device from Defender to Intune. They do different jobs, and a healthy device is usually in both.

Two different relationships

Onboarding to Microsoft Defender for Endpoint (MDE) installs or switches on the Defender sensor and connects it to your tenant. That gives you detection and response, device timelines, vulnerability data, and actions like isolating a machine. You see all of it in the Defender portal at security.microsoft.com. (The old securitycenter.windows.com address is long gone.)

Enrolling in Intune makes the device MDM-managed. Intune pushes configuration, apps, update policy and compliance rules, and you work with it at intune.microsoft.com.

Neither one replaces the other. A typical well-run Windows fleet is Intune-enrolled, and Intune deploys the MDE onboarding through an Endpoint detection and response policy. EDR keeps doing EDR. Intune keeps doing management.

Where the confusion comes from: security settings management

There's a feature that blurs the line, and it's the reason this question comes up at all.

MDE security settings management lets Intune's endpoint security policies (antivirus, firewall, attack surface reduction, EDR) reach devices that aren't enrolled in Intune. The Defender sensor picks the policy up itself. To make that work, the device gets an Entra ID device object created for it, and it shows up in the Intune device list with Managed by: MDE.

It's useful for servers, domain machines you haven't gotten to yet, and anything you can't or won't enroll. But it's a narrow slice of management. You get security policies. You don't get apps, configuration profiles, update rings, or remote wipe.

So when somebody says "this device is managed by Defender and I want it in Intune," what they almost always mean is: it's getting security settings through MDE, and they want full MDM.

Who owns the device, then?

Look at the Managed by column in Intune (Devices > All devices). You'll typically see one of:

Managed by	What it means
Intune	Enrolled in MDM. Intune owns configuration and security policy.
MDE	Not enrolled. Endpoint security policies arrive through the Defender sensor.
ConfigMgr	Managed through Configuration Manager tenant attach or co-management.

Note

Only one channel delivers endpoint security policy at a time, and MDM wins. Once the device enrolls in Intune, it stops taking policy through MDE security settings management and Intune takes over. You don't have to flip anything in the Defender portal for that handoff, and you definitely don't have to offboard the sensor.

When offboarding is the right call

There are real reasons to offboard from MDE:

• The device is being decommissioned or handed to another organization.
• You're moving it to a different tenant.
• You're replacing Defender with another EDR product.

In those cases you run the offboarding package from the Defender portal (Settings > Endpoints > Offboarding), or deploy it through Intune or Group Policy. Offboarding stops the sensor from reporting. It doesn't delete the device record; that ages out on its own.

"I want Intune to manage it" isn't on that list.

What I'd actually do

Check the Managed by value, confirm how the device is joined (dsregcmd /status on the machine tells you), and enroll it in Intune the normal way. Leave Defender alone.

Tip

Make sure the endpoint security policies that were reaching it through MDE are also assigned to a group the enrolled device will land in, so you don't open a gap during the switch.

If you want that as a step-by-step, I wrote a separate checklist for moving a device from MDE security settings management to Intune.