Checklist: Moving a Device from MDE Security Settings Management to Intune

You've got a Windows device that shows Managed by: MDE in Intune. It's onboarded to Defender for Endpoint and picks up its antivirus, firewall and ASR settings through security settings management, but it isn't MDM-enrolled. You want it fully in Intune.

The good news is that this is mostly a normal enrollment. The bad news is that there are a couple of ways to accidentally leave the machine with no security policy for an afternoon. Here's the order I work through.

If you're not sure why "managed by MDE" and "enrolled in Intune" are different things, start with the explainer and come back.

1. Confirm what you're starting with

In the Intune admin center (intune.microsoft.com), go to Devices > All devices, find the machine, and check the Managed by column. You want to see MDE. If it says ConfigMgr or Co-managed, you're in a different situation and co-management workloads are what you should be looking at.

In the Defender portal (security.microsoft.com), open the device from the device inventory and confirm the sensor is healthy and reporting. You're keeping this. Don't touch it.

2. Check how the device is joined

On the machine itself:

dsregcmd /status

Look at AzureAdJoined and DomainJoined in the Device State section. The combination tells you which enrollment path to use:

AzureAdJoined	DomainJoined	What it is	Enrollment path
YES	NO	Entra joined	Automatic enrollment should handle it.
YES	YES	Hybrid joined	Enroll via the Group Policy auto-enrollment setting.
NO	YES	Domain joined but not hybrid yet	Fix hybrid join first, or you'll be chasing enrollment errors that are really sync problems.

3. Line up your policy assignments before you enroll

This is the step people skip.

Devices under security settings management often land in policy through dynamic groups built on the system labels MDE applies, something like (device.systemLabels -contains "MDEManaged"). After enrollment the device is MDM-managed, so don't assume it will stay in those groups or that those groups will stay the right target.

Warning

Before you enroll, make sure the endpoint security policies you care about (antivirus, firewall, ASR, EDR) are also assigned to a group the enrolled device will be in: a regular device group, a user group, or a filter-based assignment. Otherwise you get a window where MDE has let go and Intune hasn't picked it up.

While you're there, check that Intune has an EDR policy that onboards devices to Defender. Enrolled devices that are already onboarded stay onboarded, but it's the setting you want for everything that comes after this one.

4. Enroll the device

Pick the path that matches step 2:

• Entra joined: confirm the MDM user scope under Devices > Enrollment > Windows > Automatic Enrollment includes the user, then have them sign in. A device that was joined before auto-enrollment was set up sometimes won't enroll on its own. Leaving and rejoining Entra ID from Settings > Accounts > Access work or school is annoying, but it's the reliable fix.
• Hybrid joined: apply the "Enable automatic MDM enrollment using default Azure AD credentials" Group Policy setting (it still says Azure AD) and give it a reboot or a gpupdate.

Heads up

Make sure the user has an Intune license and isn't blocked by an enrollment restriction, or you'll get an unhelpful error code and a support call.

5. Verify the handoff

Give it a sync or two, then check:

• Managed by now reads Intune.
• The device's Device configuration and endpoint security policy reports show the policies as Succeeded, not Not applicable.
• Compliance reports a real state instead of "Not evaluated."
• Back in the Defender portal, the device is still active and reporting.

What not to do

Don't offboard the Defender sensor. Offboarding stops EDR reporting. It has nothing to do with Intune enrollment. Save it for decommissioning, tenant moves, or replacing Defender with something else.

Don't lean on "Exclude device" in Defender. It hides a device from inventory and vulnerability views. It doesn't offboard anything, and it doesn't change who manages the device.

Don't delete the Entra device object to "clean it up" mid-move. That's how you end up with a device that can't satisfy Conditional Access on Monday morning.