Configuration Manager to Intune: Co-management and Cloud Migration Done Securely

Moving Windows management from Configuration Manager to Intune is usually done one workload at a time, and the security risk sits in the long middle phase where two tools, two permission models and a set of old service accounts all coexist. This guide covers the migration path Microsoft documents: tenant attach, co-management, switching the seven workloads with pilot collections, the cloud management gateway, mapping Configuration Manager roles to Intune RBAC, handing over patching and applications, and finally retiring the network access account, client push accounts and the site itself. It does not repeat how to harden a running Configuration Manager site; that is in the Microsoft Configuration Manager Security Guide. It is written for endpoint engineers, identity teams and security architects planning or part-way through the move. Facts on versions, deprecations and workloads were checked against Microsoft Learn on 8 November 2026.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Configuration Manager has no announced end date. As checked on 8 November 2026, Microsoft Learn lists supported current branch versions 2509, 2603 and 2609, each supported for 18 months, and no product retirement. The pressure to move comes from cloud features, deprecations and Intune-only capabilities, not a deadline.
• Co-management is the bridge, and each workload has one owner. Seven workloads can be switched individually to Pilot Intune or Intune; Microsoft says to configure the Intune side first and make sure every workload is always managed by one tool.
• The cloud attach step creates new privileged identities. Tenant attach needs a Global Administrator at onboarding and provisions an Entra app with Microsoft Graph Directory.Read.All; treat it as a non-human identity with an owner and a secret expiry date.
• Permissions do not migrate themselves. Configuration Manager security roles and scopes must be redesigned as Intune roles, scope groups and scope tags, avoiding standing Intune Administrator and Global Administrator use.
• Decommissioning is a security task. The network access account, client push accounts and site groups persist after the tools stop needing them; retiring them removes credentials attackers actively look for.

What is changing and why

Configuration Manager manages Windows devices from on-premises site servers. Intune manages them from the cloud through MDM. Microsoft's documented path is not a cut-over but a cloud attach: first upload devices to the Intune admin center (tenant attach), then manage them with both tools (co-management), then move workloads to Intune until Configuration Manager has nothing left to do.

Why organisations move: Microsoft lists Conditional Access with device compliance, Intune remote actions such as restart and factory reset, central device health visibility and modern provisioning with Windows Autopilot as benefits of co-management. Some features also require Intune: Windows Autopatch needs the Windows Update policies, Device configuration and Office Click-to-Run apps workloads switched to Intune. Removing an on-premises management server also removes a high-value target: software deployment tools are a documented attacker technique (MITRE ATT&CK T1072).

Official timeline and current status

There is no product retirement date for Configuration Manager. What does have dates is version support and feature deprecation. All entries below are as shown on Microsoft Learn on 8 November 2026; check the source pages before planning, because Microsoft updates them with each release.

A co-management project that stalls for two years will pass at least one version end date, so plan site upgrades in parallel. For the Azure AD Graph retirement in general, see the Azure AD Graph and MSOnline Retirement Guide.

Who and what is affected

• Devices: domain-joined Windows clients (need Entra hybrid join to be co-managed), internet-only clients managed through the CMG, workgroup clients and devices built by task sequence. Co-management uses Entra joined or hybrid joined devices, not Entra registered (workplace joined) devices.
• Endpoint administrators: their Configuration Manager security roles and collections stop governing switched workloads; Intune roles and scope groups take over.
• Identity team: owns the Entra app created for cloud attach, hybrid join, and any Privileged Identity Management for Intune roles.
• Service accounts: network access account, client push installation accounts, site system installation accounts, reporting services point account and migration source site accounts.
• Security operations: logs and alerts move from Configuration Manager status messages to Intune audit logs and Entra sign-in logs.

Finding affected systems and identities

Inventory before switching anything. The aim is to know which devices will move, which identities hold power over them and which accounts can be retired at the end.

For finding and retiring the service accounts themselves, see How to find service accounts with Domain Admin rights and the NHI Offboarding and Decommissioning Guide.

Migration options

Option A: tenant attach only

Upload devices to the Intune admin center without enabling co-management or switching workloads. Tenant-attached devices get only the default scope tag and cannot be assigned other scope tags, so limit which Intune roles can see them with a custom role whose scope tags exclude Default.

Option B: co-management, workload by workload (the common path)

Enable co-management through Administration, Cloud Services, Cloud Attach, then move workloads on the Workloads tab. Each slider has three positions: Configuration Manager, Pilot Intune (Intune manages the workload only for the pilot collection set on the Staging tab) and Intune. A sensible order with the security notes Microsoft documents:

Option C: cloud native for new devices

New devices are Entra joined and enrolled in Intune through Windows Autopilot and never receive the Configuration Manager client; old devices are replaced at refresh. This avoids hybrid join for new hardware but leaves a long tail. If new Autopilot devices must also be co-managed, Microsoft states a CMG is required; for auto-enrolling existing clients it is not.

Decision guidance: small estates with a short refresh cycle often skip most of co-management and go cloud native at refresh. Large estates with heavy task sequence and application packaging investment use Option B for years. Regulated environments that need on-premises content or OS deployment keep Configuration Manager for those workloads and move compliance, updates and endpoint protection first.

Mapping permissions to Intune RBAC

Intune roles combine a management category with Read, Write, Update and Delete actions, granted through assignments that set admin groups, scope groups (which users and devices) and scope tags (which objects are visible). Built-in roles include Help Desk Operator, Policy and Profile Manager, Endpoint Security Manager, Application Manager, Read Only Operator and Intune Role Administrator. Permissions across assignments are additive, and mixing scope tags across assignments can broaden visibility more than intended.

• Configuration Manager Full Administrator: do not map to standing Intune Administrator or Global Administrator. Microsoft advises against using either for routine Intune work; use Privileged Identity Management for just-in-time elevation. See the Privileged Identity Management (PIM) Guide.
• Collection-scoped admins: map collections to Entra security groups used as Intune scope groups, and security scopes to scope tags.
• Role changes: turn on Multi Admin Approval so a second admin must approve changes to roles and assignments.
• Tenant attach RBAC: leave Enforce RBAC on so both tools' permissions apply to tenant-attached actions.

Testing and rollback

1. Prepare: upgrade the site to a supported version, confirm hybrid join and Windows automatic enrolment, and build the Intune RBAC model before anyone uses the Intune console.
2. Configure Intune first: create and assign the Intune policies for a workload before moving its slider, so devices are never unmanaged for that workload.
3. Pilot: set the workload to Pilot Intune with a pilot collection of IT devices, then a second ring of representative users. Note that for Endpoint Protection and Device configuration, Pilot Intune deploys policies but does not remove them when unassigned.
4. Verify: check compliance state, Defender settings, update rings and BitLocker status on pilot devices; compare with the Configuration Manager baseline.
5. Expand: move the slider to Intune for all co-managed devices, one workload at a time, with a change window and a named owner.
6. Roll back: any workload can be moved back to Configuration Manager. Microsoft warns of side effects: for example Windows and Office versions installed by Intune stay at the later version. Keep the Configuration Manager policies in place until each workload has been stable in Intune for at least one patch cycle.

Measures that show it is working: percentage of devices co-managed or Intune-managed; workloads fully switched out of seven; compliance and patch currency for Intune-managed devices against the old Configuration Manager figures; number of standing Global Administrator and Intune Administrator assignments (target zero for daily use); remaining service accounts from the retirement list; days to the cloud attach app secret expiry.

Risks of doing nothing

• Stalled middle state: two tools and two permission models stay live indefinitely, so attackers have two routes to push software to every device (T1072), and auditors have two places to check.
• Old credentials stay in service: the network access account is delivered to clients and is a known credential-theft target (T1552); client push accounts are local administrators on every target (T1078.002). Microsoft recommends Enhanced HTTP instead of the network access account and Deny log on locally for client push accounts.
• Version drift: a site left on an unsupported version stops receiving security updates.
• Feature dependency: deprecated features (resource access, classic CMG, Connected Cache integration) block upgrades or stop receiving development.
• Unowned cloud identity: a cloud attach app created once by a departed Global Administrator, with a secret nobody tracks, is the kind of non-human identity that gets forgotten. See the Microsoft Intune Guide for Intune-side hardening.

Retiring Configuration Manager accounts

1. Network access account: first move content access to Enhanced HTTP or HTTPS, then check dependencies that still need it (multicast, accessing content directly from a distribution point in task sequences, SMB fallback, Request State Store, "Run another program first"). Remove it from site settings and share permissions, then disable and delete it in Active Directory.
2. Client push accounts: remove from client push properties, remove from local Administrators groups through Group Policy or Intune, then delete.
3. Site installation account: transfer console rights to another administrator before removing it.
4. Persisting groups: Microsoft notes that SMS Admins, the SMS_SiteSystemToSiteServerConnection, SMS_SiteToSiteConnection and Configuration Manager_CollectedFilesAccess groups are not removed when a site is uninstalled, and Configuration Manager Remote Control Users is not removed when remote tools are disabled. Delete them manually.
5. Cloud attach: clear Upload to Microsoft Endpoint Manager admin center to offboard, then delete the Entra app and the CMG resources in Azure.

Framework mapping

Practitioner checklist

• Confirm the site runs a supported current branch version and schedule upgrades for the life of the project.
• Inventory devices by join state, admins in both tools, the cloud attach app and every Configuration Manager service account.
• Design Intune roles, scope groups and scope tags before go-live; no standing Global Administrator or Intune Administrator for daily work; enable PIM and Multi Admin Approval.
• Record an owner and secret expiry for the cloud attach Entra app.
• Switch workloads one at a time: configure Intune first, Pilot Intune with a pilot collection, verify, then Intune.
• When moving Windows Update policies, disable the Configuration Manager software update workflow for those devices.
• Scope CMG use with the client setting and plan its removal once no clients depend on it.
• Move content access to Enhanced HTTP, then retire the network access account and client push accounts.
• Delete persisting site groups and the cloud attach app when the site is uninstalled.

Standards and references

• Microsoft Learn: Co-management for Windows devices
• Microsoft Learn: Co-management workloads
• Microsoft Learn: How to switch co-management workloads to Intune
• Microsoft Learn: Updates for Configuration Manager (version details)
• Microsoft Learn: Removed and deprecated features for Configuration Manager
• Microsoft Learn: Accounts used in Configuration Manager
• Microsoft Learn: Tenant attach device sync and device actions
• Microsoft Learn: Role-based access control with Microsoft Intune

Related NHI Mgmt Group resources: Microsoft Configuration Manager Security Guide · Microsoft Intune Guide · Group Policy to Intune Migration · NHI Offboarding and Decommissioning Guide