Yes, when they still need imaging, deep Windows control, or mature reporting that Intune does not fully replace. The decision should be based on operational requirements, not on a generic cloud preference. Many estates will use both for a long transition period, especially where Windows remains the dominant platform.
How to Decide Whether Configuration Manager Still Earns Its Place
The real question is not whether Intune is newer, but whether it covers the full operational set you actually run. configuration manager still matters when you rely on task sequences, OS deployment, tightly controlled Windows servicing, or on-premises management patterns that Intune does not fully replicate. A coexistence model is often the most practical answer during migration.
That means the decision should be anchored in device operations, not branding. If your endpoint estate includes legacy Windows workflows, complex application deployment, bandwidth-sensitive imaging, or reporting requirements that support audit and troubleshooting, ConfigMgr can remain the right control plane for those functions while Intune handles modern MDM use cases.
Where Intune Replaces Some, but Not All, of Configuration Manager
Intune is strongest where cloud enrollment, policy delivery, compliance, and modern remote management are the priority. It is usually easier to standardise, simpler to administer across distributed users, and better aligned with internet-connected device management. For many organisations, that makes it the primary path for laptops and mobile-first or hybrid estates.
Configuration Manager remains stronger where you need deeper Windows-specific control, more mature app deployment options, and local-network-aware management. Hybrid environments often need both because they are solving different problems. The overlap is real, but it is not complete, and forcing a single tool too early usually creates gaps in packaging, imaging, servicing, or reporting.
That is why the most durable operating model is often coexistence with a clear boundary. One platform can own modern cloud management, while the other continues to support the parts of the estate that still depend on traditional endpoint engineering.
What Makes a Coexistence Model Work in Practice
A successful dual-platform setup depends on clarity about which device populations, workflows, and administrative actions belong where. If the same device is enrolled in both tools, teams need a deliberate split of authority so policy, compliance, and application delivery do not conflict. UEM Buyer's Guide is useful here because it frames the broader evaluation criteria around co-management, enrolment, and the trade-offs between UEM and traditional client management.
That boundary matters most during transition. If imaging, software packaging, and compliance reporting are still business-critical, moving all control into Intune before those processes are ready can create more manual work, not less. In mature estates, Configuration Manager often remains as the engineering backbone while Intune becomes the default for new devices and cloud-native policy.
Coexistence also helps when change has to be phased by business unit, geography, or device class. The goal is not to preserve two tools indefinitely for its own sake. It is to avoid a capability cliff while the organisation retires older operating patterns at a pace that matches risk, supportability, and user impact.
Risk and Threat Considerations
Dual management can create policy drift, duplicate configuration, and unclear ownership if teams do not define which platform is authoritative for each setting. That is an operational risk first, but it can become a security risk when control gaps leave devices partially managed or inconsistently remediated.
Failure mechanism: Split authority between platforms can produce conflicting baselines, stale devices, or gaps in reporting, especially during migration or when administrators assume the other console is enforcing the control.
Impact: The result can be weak compliance visibility, inconsistent patching or hardening, and slower detection of unmanaged endpoints or failed policy application.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | ConfigMgr vs Intune is a software and endpoint configuration decision. |
| Recommendation — Standardise endpoint baselines and retire duplicate policy paths. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The question hinges on maintaining approved device baselines during platform transition. |
| CM-8 — System Component Inventory | Coexistence requires knowing which devices and workloads still depend on each management plane. | |
| AU-6 — Audit Review, Analysis, and Reporting | Mature reporting is one reason organisations keep Configuration Manager. | |
| Recommendation — Define the authoritative baseline for each device class before migrating controls. Maintain an accurate inventory of managed endpoints and ownership. Preserve reporting that supports audit, troubleshooting, and exception handling. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The decision is about how endpoint configuration is controlled across two platforms. |
| Recommendation — Document which platform controls each configuration domain. | ||
Practitioner Guidance
What to prioritise: Decide which operational capabilities still require Configuration Manager before you decide how quickly Intune should replace it. Imaging, deep Windows servicing, and richer reporting are the usual anchors for keeping both.
What to verify: Confirm which device classes, deployment methods, and reporting outputs are actually consumed by operations, support, and audit teams. If those outputs are still relied on, Intune-only is usually premature.
Decision rule: If a control, workflow, or report would be materially weaker in Intune today, keep Configuration Manager in the architecture until the replacement is proven, not just planned.
Practitioner takeaway: The best choice is the one that preserves endpoint control without creating a premature migration gap, and in many Windows-heavy estates that means running both platforms for a while, with clearly separated responsibilities.
Related resources from NHI Mgmt Group
- Why do organisations often need both Intune and Configuration Manager to support Zero Trust?
- Should organisations keep Configuration Manager or WSUS after adopting Autopatch?
- How should security teams govern non-human identities alongside human accounts?
- How should teams govern non-human identities alongside CAASM and EASM?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org