Microsoft Intune Co-Management with SCCM: Licensing the Hybrid Environment

Co-Management Licence Requirement: Plan 1 Only

Windows co-management — where SCCM (Microsoft Endpoint Configuration Manager / ConfigMgr) and Microsoft Intune manage the same Windows device simultaneously, with workloads split between the two — does not require a higher Intune tier than Plan 1. The co-management configuration, workload split, and cloud attach features are available with any Intune subscription, including the Plan 1 entitlement included in Microsoft 365 E3/E5. There is no "co-management licence" as a distinct SKU. Co-management is enabled by connecting a ConfigMgr site to an Intune tenant (the Cloud Management Gateway or CMG configuration) and configuring which workloads are managed by ConfigMgr versus Intune.

The commercial error in co-management licensing is purchasing additional Intune licences for co-managed devices under the assumption that SCCM-enrolled devices require a separate Intune subscription on top of the M365-included licence. They do not. Every device in a co-management deployment requires exactly one Intune licence per user — the same licence required for Intune-only MDM management. For M365 E3/E5 users, that licence is already included. The co-management configuration itself does not add a licence charge.

Workload Split Decisions — Licence Implications by Workload

Co-management workloads are specific management responsibilities that can be shifted from SCCM to Intune — or kept in SCCM — independently. Common workloads include: Compliance Policies, Device Configuration, Resource Access Policies, Endpoint Protection, Windows Update policies, Office Click-to-Run, and Client Apps. Understanding the licence implications of each workload shift is straightforward: shifting any workload from SCCM to Intune does not change the Intune licence requirement. Plan 1 handles all co-management workloads.

Compliance Policies Workload — Plan 1

Shifting Compliance Policies to Intune enables Conditional Access integration — devices report compliance status to Entra ID, and CA policies can gate access to M365 apps based on device compliance. This is the primary driver for co-management adoption in most enterprises. Plan 1 handles this entirely. The Conditional Access policy configuration requires Entra ID P1, which is included in M365 E3/E5. No additional Intune or Entra tier is required for compliance-driven CA integration in a co-managed environment.

Endpoint Protection Workload — Plan 1, Defender for Endpoint Separate

Shifting the Endpoint Protection workload to Intune means antivirus, firewall, and attack surface reduction policies are managed from the Intune admin centre rather than ConfigMgr. Plan 1 handles the Intune management side. If Microsoft Defender for Endpoint (MDE) is deployed — either Plan 1 or Plan 2 — the onboarding and configuration of MDE through Intune uses Plan 1 regardless of whether MDE Plan 1 or Plan 2 is deployed. The distinction between MDE Plan 1 (included in M365 E3) and MDE Plan 2 (included in M365 E5) is a function of the MDE licence tier, not the Intune tier. Our Defender for Endpoint P1 vs P2 guide covers the MDE tier decision separately.

Windows Update Policies Workload — Plan 1

Windows Update for Business (WUfB) management through Intune — update rings, feature update policies, driver updates — operates on Plan 1. This workload is commonly shifted to Intune as part of cloud modernisation. No additional licence is required. Windows Update Advanced Reporting (through Windows Update for Business Reports in Azure Monitor) uses Log Analytics, which is an Azure cost, not an Intune licence cost.

SCCM / ConfigMgr Licensing — The Software Assurance Requirement

Microsoft Endpoint Configuration Manager (SCCM) is licensed through System Center, which requires active Software Assurance (SA) for the co-management cloud attach feature. Specifically, the "co-management" and "tenant attach" cloud features (connecting ConfigMgr to a Microsoft Intune tenant for co-management, CMG, and admin centre integration) require the Configuration Manager current branch, which requires SA or subscription licensing. ConfigMgr without active SA is on a LTSB (Long Term Servicing Branch) which does not include cloud attach or co-management capabilities.

This creates a Software Assurance dependency that affects EA renewal decisions. If an organisation is letting ConfigMgr SA lapse as part of a cloud modernisation strategy — planning to move fully to Intune — they should validate the co-management workload shift timeline before the SA expiry. Running co-management during a transition period requires active SA for ConfigMgr current branch. Our Software Assurance guide covers the full SA decision framework, including the ConfigMgr SA extension options available in enterprise EAs.

Intune Suite Add-Ons in Co-Managed Environments

The most nuanced licensing question in co-managed environments is which Intune Suite add-on features are managed through Intune versus SCCM — and therefore which devices actually require the Suite add-on licence.

Endpoint Privilege Management (EPM) in Co-Management

EPM (standard user enforcement with controlled elevation) is an Intune Suite capability that can be deployed through Intune to co-managed devices where the Device Configuration workload has been shifted to Intune. If the Device Configuration workload is still managed by SCCM for a device population, EPM policies cannot be delivered to those devices through Intune — SCCM does not natively support EPM policy delivery. This means purchasing Intune Suite for EPM on co-managed devices where the Device Configuration workload has not been shifted to Intune produces zero EPM capability and 100% licence cost. Validate the workload split before any Suite licensing for co-managed devices.

Remote Help in Co-Management

Remote Help (IT-assisted remote desktop support sessions through Intune) works on Intune-enrolled devices — including co-managed devices where the Device Configuration workload has been shifted to Intune. For co-managed devices where SCCM handles device configuration but Intune handles compliance, Remote Help can still operate as long as the device has Intune enrolment (which co-management requires). Remote Help does not require the Device Configuration workload to be Intune-managed. For co-managed environments where Remote Help is the primary Suite driver, the Suite licence scope should be the IT-supported device population — not the full co-managed fleet.

EA Negotiation — Three Co-Management Positions

1. Audit Standalone Intune Licences for Co-Managed Devices

Generate a report of all devices enrolled in co-management from the ConfigMgr console (Monitoring > Co-Management > Co-Management Status). Cross-reference this device list against the M365 licence assignments for the device users. Any co-managed device whose primary user has M365 E3 or E5 already has Intune Plan 1 included. Any standalone Intune Plan 1 line covering those users should be removed at the next EA amendment. Request that the Microsoft account team provide a written licence inclusion confirmation for each SKU in your EA before your renewal to force this validation into the commercial process.

2. Challenge Suite Licences for SCCM-Managed Workloads

If Intune Suite is in your EA renewal proposal for co-managed devices, require a workload-split mapping: which Suite features (EPM, Remote Help, Advanced Analytics) are being delivered through Intune to which device populations, and which device configuration workloads for those devices are already shifted to Intune. Any Suite feature that requires the Device Configuration workload to be Intune-managed (EPM) cannot function on devices where that workload is still SCCM-managed. The validated deployable population — devices with both the correct workload shift AND the target use case for the Suite feature — is the correct licence scope.

3. Use the Co-Management Migration Timeline as a Negotiation Lever

If your organisation is in an active SCCM-to-Intune migration, use the migration timeline to structure phased Intune commitments in the EA. A full-Intune commitment at renewal is appropriate only when the SCCM migration is complete. For an organisation 60% through a 24-month SCCM migration, the correct Intune commitment reflects the current deployed population, not the full target state. Negotiate a right-to-expand provision at committed pricing for the remaining device population as migration progresses — preserving EA pricing without front-loading full Intune licence cost before deployment is complete. This approach is accepted in Microsoft EA Amendment structures and prevents the common pattern of paying for Intune for devices still fully managed by SCCM.

Co-Management in the Full EA Context

SCCM + Intune co-management sits at the intersection of three major EA cost areas: the Intune licence (Plan 1 in M365 E3/E5), the ConfigMgr/System Center SA commitment, and the Microsoft 365 base suite. Optimising the co-management licence position requires visibility into all three simultaneously — which is why co-management deployments that were set up by separate teams (endpoint management team for SCCM/Intune, procurement team for the EA, IT for M365) so frequently produce redundant spend. Our Intune complete guide covers the full Intune architecture, the Software Assurance guide covers the ConfigMgr SA decision, and our EA negotiation guide provides the integrated framework for structuring the full EA renewal around your actual deployment state — not Microsoft's proposed renewal position.