Windows device management: What MDM can replace and what it cannot

Windows device management has two parallel lineages, and choosing between them is the central decision for any IT team managing Windows 10 or Windows 11 fleets. The legacy lineage uses Active Directory domain join, Group Policy, and Configuration Manager (formerly SCCM). The modern lineage uses Mobile Device Management (MDM) through the native Windows MDM channel, with Microsoft Entra ID for identity and Windows Autopilot for provisioning. This guide explains honestly what the modern MDM channel can replace from the legacy stack, and what it cannot.

First, two clarifications. Windows device management is not the same as Device Manager, the built-in Windows control panel that shows your hardware and drivers. Device Manager manages the components inside one machine. Windows device management, in the enterprise sense used here, is the discipline of managing fleets of Windows machines through policy, provisioning, and security tooling. MDM here also means Mobile Device Management, not Master Data Management, which is an unrelated data-governance category that shares the acronym.

The replacement question matters because moving from the legacy stack to cloud MDM is one of the larger projects an IT team can undertake, and the honest answer is not “MDM replaces everything.” It replaces a great deal, leaves some gaps, and most organizations run both side by side for a period through an approach called co-management. This guide covers all three: what MDM replaces, what it does not, and how the bridge works.

The short answer, before the explanation

Legacy function	Can modern MDM replace it?	Notes
Common security and device policies	Mostly yes	Depends on CSP coverage and OS version
Manual new-device setup	Often yes	Windows Autopilot replaces many standard provisioning workflows
VPN-dependent management	Yes for MDM traffic	Devices receive MDM policy over the internet, no VPN needed for management
Basic app deployment	Yes	Standard apps and packages are increasingly manageable through MDM
Complex app packaging	Not always	Configuration Manager is still stronger for deep dependencies and detection logic
Advanced task sequences and imaging	Not fully	Autopilot is not a full task-sequence replacement
Deep legacy GPO environments	Partly	Requires mapping each GPO to an MDM equivalent
On-prem AD-dependent workloads	No	MDM manages devices, not the full identity and app dependency chain

Windows management terminology, in one place

Term	Meaning
Group Policy	Legacy policy system for Active Directory-joined Windows devices
Configuration Manager	Microsoft’s systems management platform, formerly SCCM
Intune	Microsoft’s cloud endpoint management platform
Windows MDM channel	Native Windows management channel used by every Windows MDM
CSP (Configuration Service Provider)	The interface MDM uses to configure specific Windows settings
Entra ID	Microsoft’s cloud identity platform (formerly Azure AD)
Windows Autopilot	Microsoft provisioning technology for preparing new or reset Windows devices
Co-management	Configuration Manager and Intune managing the same devices by workload
Coexistence	Configuration Manager plus a third-party MDM, with more limitations than co-management

What is Windows device management?

Windows device management is the practice of configuring, securing, and maintaining Windows endpoints across an organization. The capability set is broadly the same regardless of lineage: enforce settings, deploy apps, apply security policy, provision new machines, and report compliance. What differs is the mechanism and where the control plane lives.

The two lineages: domain join vs cloud MDM

The legacy lineage assumes devices are domain-joined to on-premise Active Directory. Group Policy pushes settings to domain-joined machines. Configuration Manager (formerly SCCM) handles app deployment, patching, and imaging. This stack is mature, deep, and built for machines that live on the corporate network.

The modern lineage assumes devices are joined to Microsoft Entra ID (the cloud identity service) and managed through MDM. Policy and apps flow over the internet to devices anywhere, with no requirement to be on the corporate network or connected to a VPN. This stack is built for remote and hybrid work, where machines rarely touch a corporate LAN.

How the Windows MDM channel works (CSPs)

Windows has a built-in MDM client, the same way iOS and Android do. The MDM server communicates with the Windows MDM client through Configuration Service Providers, or CSPs. A CSP is an interface that exposes a specific set of device settings to MDM. When an MDM applies a policy, it does so by writing to the relevant CSP. This native channel is what every Windows MDM uses, whether the MDM is Microsoft Intune or a third-party cross-platform tool. The breadth of what an MDM can configure on Windows is bounded by the CSPs Microsoft exposes.

What MDM can replace on Windows

The modern MDM channel has matured to the point where it replaces most of what the legacy stack did for a large share of organizations, particularly those without heavy legacy infrastructure. The table below summarizes the strength of replacement by area, and the subsections that follow explain each.

Area	Replacement strength	Why
Security baselines	Strong	Common policies map well to MDM and CSPs
OS and browser restrictions	Strong to medium	Depends on the exact setting and OS version
Windows Update policies	Strong	Co-management supports moving Windows Update policies to Intune
New-device provisioning	Strong for standard workflows	Autopilot reduces imaging and manual setup
Remote policy delivery	Strong	MDM works over internet without VPN for management traffic
App deployment	Medium	Standard apps fit better than complex legacy packages
Legacy GPO edge cases	Medium to weak	Some settings may not map cleanly to a CSP
Imaging and task sequences	Weak	Configuration Manager remains stronger for complex pipelines

Group Policy settings

Many common Windows policies can now be delivered through MDM using Configuration Service Providers, especially mainstream security, browser, update, and device-configuration settings. In Intune these are surfaced through the Settings Catalog, which presents available CSPs as configurable policies. For organizations whose Group Policy use is mainstream, MDM covers most of the ground. But deep or highly customized Group Policy environments still need a setting-by-setting migration check, because some advanced or niche settings do not yet have direct CSP equivalents, and parity continues to evolve with each Windows and Intune release.

Manual provisioning

Windows Autopilot does not replace every imaging or task-sequence workflow. It replaces a large share of standard new-device provisioning by turning the OEM-installed Windows image into a business-ready state, then applying policies, apps, and MDM enrollment during setup. A device ships from the vendor directly to the user, and on first boot it enrolls itself, applies policy, and installs apps with no IT hands on the hardware. This is the Windows parallel to automated enrollment on other platforms. For organizations still imaging machines manually or with technician time per device, Autopilot replaces that labor for the standard cases.

On-premise-only access assumptions

The legacy stack assumed devices needed line of sight to a domain controller. MDM plus Entra ID removes that assumption. Devices authenticate and receive policy over the internet, and conditional access ties resource access to device compliance and identity rather than network location. This replaces the perimeter-based model where being on the network implied trust.

VPN-dependent management

Because legacy management assumed the corporate network, managing a remote machine often meant the machine had to connect by VPN for Group Policy and Configuration Manager to reach it. MDM reaches devices wherever they have internet access, with no VPN required for management traffic. For remote and hybrid fleets, this is one of the largest practical gains.

What MDM cannot (yet) fully replace on Windows

MDM does not replace everything the legacy stack did. Several areas remain stronger in Configuration Manager or depend on infrastructure MDM does not address.

Deep legacy app deployment and packaging

Configuration Manager has decades of depth in complex application deployment: intricate dependencies, detection logic, supersedence, and large legacy installers. MDM app deployment has improved substantially, but organizations with complicated application catalogs and custom packaging often find Configuration Manager still does this better. The gap narrows each year but has not closed for the hardest cases.

Complex Group Policy scenarios without CSP equivalents

While most common Group Policy settings have CSP equivalents, some advanced or niche settings do not yet map cleanly to a CSP. Organizations with elaborate, deeply customized Group Policy environments may find specific settings that MDM cannot reproduce. These edge cases require either a workaround or retaining Group Policy for the affected settings.

On-premise-dependent workloads and legacy infrastructure

Some workloads depend on on-premise infrastructure that assumes domain join: certain line-of-business applications, legacy authentication patterns, file shares with NTFS permissions tied to AD groups, and print infrastructure. MDM manages the device, but it does not by itself migrate these dependencies off on-premise Active Directory. That migration is a separate, larger project.

Imaging-heavy and task-sequence workflows

Organizations that rely on complex imaging, custom task sequences, and detailed OS deployment workflows in Configuration Manager find that Autopilot, while excellent for standard provisioning, does not replicate every advanced task-sequence capability. For standardized modern provisioning, Autopilot is the better model. For highly customized imaging pipelines, Configuration Manager retains capabilities MDM does not match. Microsoft continues to support Configuration Manager alongside cloud-native management; check Microsoft’s current product lifecycle and roadmap documentation for the latest support position.

Co-management: the bridge most organizations actually use

For organizations that cannot move everything to MDM at once, co-management is the practical path. Co-management runs Configuration Manager and Intune MDM on the same Windows devices simultaneously, with each management workload assigned to one authority or the other. Microsoft uses the term “co-management” specifically for the Configuration Manager plus Intune combination.

The model lets IT migrate workload by workload rather than all at once. Each workload can be shifted from Configuration Manager to Intune independently, when the team is ready. A device can have its security baseline managed by Intune while complex app deployment stays with Configuration Manager.

Workload	Move to Intune early?	Why
Compliance policies	Yes	Supports Conditional Access and modern compliance checks
Windows Update policies	Yes	Strong cloud-native fit
Endpoint protection	Often yes	Defender, firewall, and BitLocker policies fit modern management
Device configuration	Gradual	Move after validating CSP coverage for your specific settings
Office Click-to-Run apps	Often yes	Common cloud-management workload
Client apps	Mixed	Standard apps may move; complex packages may stay in Configuration Manager
Resource access policies	Review carefully	Microsoft has changed support around some resource access features

Co-management is not the destination. It is the bridge. The destination for most organizations is cloud-native management through MDM, with Configuration Manager retired once its remaining workloads have equivalents. But the bridge can last years, and for organizations with deep legacy dependencies, running both is the realistic state for the foreseeable future. The honest planning assumption is that Windows fleets move toward MDM gradually, not in a single migration.

One terminology point matters here. Strictly speaking, Microsoft uses “co-management” for Configuration Manager plus Intune. If Configuration Manager runs beside a third-party MDM, Microsoft treats that as coexistence, and the orchestration model is not equivalent. Coexistence has more limitations than co-management on which authority controls which workload, so plan accordingly if your modern stack is a non-Microsoft MDM.

Choosing a Windows MDM

Once the replacement question is settled, the vendor question follows. Windows MDM options divide into Microsoft-native and cross-platform.

Microsoft-native (Intune) for Windows-centric shops

Microsoft Intune is the deepest Windows MDM because Microsoft builds both the MDM and the operating system. It exposes the broadest set of CSPs, integrates natively with Entra ID and Configuration Manager for co-management, and ships Windows management features on or near release. For Windows-centric organizations, particularly those already on Microsoft 365, Intune is the default and usually the strongest choice. It is bundled with Microsoft 365 Business Premium and Enterprise E3 and E5 licenses, so many organizations already own it.

Cross-platform MDM for mixed fleets

Cross-platform MDMs manage Windows alongside Apple, Android, and Linux from one console. They manage Windows through the same native Windows MDM channel and CSPs that Intune uses, so they cover core policy, compliance enforcement, and app distribution. The honest scope statement matters here: cross-platform MDMs generally expose a narrower set of Windows-specific capabilities than Intune, and the deepest Windows management (complex packaging, advanced imaging, intricate legacy Group Policy) still runs best through Microsoft’s own stack.

Bento MDM fits the cross-platform category for organizations that manage Windows alongside macOS, iOS, Android, and Linux from one console. The trade-off is the same as with other cross-platform tools: you gain platform consolidation, but Windows-specific depth is still bounded by the native Windows MDM channel and the CSPs Microsoft exposes. For mixed fleets where Windows is one platform among several and the management needs are mainstream, the consolidation is the value.

Which approach fits your fleet?

Match the approach to the fleet and the legacy footprint.

• Windows-only, modern, cloud-first: Intune with cloud-native MDM. Skip or minimize Configuration Manager. Autopilot for provisioning, Settings Catalog for policy.
• Windows-only, heavy legacy footprint: Co-management. Run Configuration Manager and Intune together, migrate workloads as equivalents mature, retain Configuration Manager for complex packaging and imaging until MDM closes the gap.
• Mixed fleet (Windows plus Mac, Android, Linux): A cross-platform MDM such as Bento MDM for single-console management, recognizing that Windows-specific depth is bounded by the native MDM channel. If the Windows fleet also needs advanced packaging, consider Intune for Windows alongside the cross-platform tool, or weigh whether single-console simplicity wins.
• Regulated, any composition: Prioritize compliance policy, conditional access, and audit logging. MDM with Entra ID conditional access handles modern compliance well. Confirm the specific regulatory controls map to available CSPs and reporting before committing.

Frequently asked questions

Is Windows device management the same as Device Manager?

No. Device Manager is the built-in Windows control panel that shows the hardware components and drivers inside a single machine, opened with devmgmt.msc. Windows device management, in the enterprise sense, is the discipline of managing fleets of Windows machines through policy, provisioning, and security tooling such as MDM, Group Policy, or Configuration Manager. They are unrelated despite the similar names.

Can MDM replace Group Policy?

For most organizations, largely yes. Many common Windows policies can now be delivered through MDM using Configuration Service Providers, surfaced in Intune as the Settings Catalog. Mainstream Group Policy use (security baselines, restrictions, OS and browser configuration) is covered by MDM. Some advanced or niche Group Policy settings do not yet have CSP equivalents, so organizations with deeply customized Group Policy environments may need to retain Group Policy for specific settings.

Can MDM replace SCCM (Configuration Manager)?

Partially, and increasingly. MDM replaces Configuration Manager for policy, compliance, modern provisioning through Autopilot, and standard app deployment. Configuration Manager retains advantages in complex application packaging, advanced imaging and task sequences, and on-premise-dependent workloads. Most organizations bridge the two with co-management, migrating workloads to MDM over time rather than replacing Configuration Manager in one step.

What is co-management?

Co-management runs Configuration Manager and Intune MDM on the same Windows devices at once, with each management workload assigned to one authority. It lets organizations migrate from legacy management to cloud MDM gradually, workload by workload, rather than all at once. It is a bridge toward cloud-native management, not a permanent destination, though it can last for years in organizations with deep legacy dependencies. Microsoft uses “co-management” specifically for Configuration Manager plus Intune; Configuration Manager running alongside a third-party MDM is called coexistence and has more orchestration limitations.

Do I still need Active Directory if I use MDM?

It depends on your workloads. Devices can be joined to Microsoft Entra ID and managed entirely through MDM without on-premise Active Directory. But if you have line-of-business applications, file shares, or authentication patterns that depend on on-premise Active Directory, those dependencies must be migrated separately before you can fully retire AD. Many organizations run Entra ID and on-premise AD together during the transition.

What is the Windows MDM channel?

The Windows MDM channel is the built-in management client in Windows, the same concept as the MDM clients in iOS and Android. An MDM server communicates with it through Configuration Service Providers (CSPs), which expose specific device settings to management. Every Windows MDM, including Intune and third-party cross-platform tools, manages Windows through this same native channel, so the breadth of what any MDM can configure is bounded by the CSPs Microsoft exposes.

Can one MDM manage both Windows and Mac?

Yes. Cross-platform MDM and unified endpoint management platforms manage Windows, macOS, iOS, Android, and often Linux from one console, including Microsoft Intune, Bento MDM, and others. They manage Windows through the native Windows MDM channel. The trade-off is that cross-platform tools typically offer narrower Windows-specific depth than Intune does for Windows, and narrower Apple-specific depth than an Apple specialist does for Mac, so the choice depends on whether single-console management or maximum per-platform depth matters more for your fleet.