Co-management is not a way to manage remote devices. The Configuration Manager client still has to reach its site.
That sentence appears in the documentation, and the assumption it corrects is what derails most projects begun for hybrid working reasons. What this actually does is add cloud capability on top of an existing Configuration Manager estate. Getting to devices over the internet is a separate piece of work with its own budget and its own timeline.
- 7 workloadsCan be switched from ConfigMgr to Intune
- Pilot firstAny workload, on a separate collection
- Both, not eitherConfigMgr keeps everything not switched
- Not workplace joinedRegistered-only devices are unsupported
Co-management is a management option. Microsoft Entra ID is an identity option.
This distinction is drawn explicitly in the documentation, along with a note that customers conflate the two constantly. Separating them is genuinely the first useful thing to do in any conversation on this subject.
- The management half lets you run Windows devices under both platforms at once, with the two balancing workloads between themselves so conflicts do not arise. It is fundamentally a statement about which authority owns which workload, and nothing more.
- The identity half is a separate question and also a prerequisite. Machines have to be hybrid joined or fully joined to the directory. Anything merely registered, often described as workplace joined, is not supported.
- Then there is a third case worth naming. Configuration Manager running alongside a third-party platform is coexistence rather than co-management, and the workload balancing simply does not happen there, which is why coexistence carries capability limitations that co-management does not.
- Straighten out those three distinctions at the outset and you avoid the most common failure mode we see, which is a device management project quietly stalling on an identity problem nobody put in the scope.
Eight things to establish before enabling it.
Both authorities, deliberately
Your Windows machines carry the Configuration Manager client and are simultaneously enrolled in the cloud service, with you deciding which workloads shift and when. Everything you leave alone carries on being managed exactly as before, as does every Configuration Manager feature that falls outside co-management entirely. Nothing is surrendered by switching this on.
What you gain immediately
Access policies backed by device compliance, remote actions covering restart and remote control and factory reset, centralized health visibility, users and devices and applications joined up in the directory, and modern provisioning for new hardware. Every item on that list arrives before a single workload has been switched, which is why the first phase is easy to justify.
Seven workloads that can move
The list runs to compliance, Windows Update, resource access, endpoint protection, device configuration, the Office Click-to-Run applications and general client applications. Every one moves independently of the others. And it bears repeating that none of them has to move at all for this to have been worth doing.
Piloting per workload
Each workload can be tried against its own separate collection, letting you exercise the new functionality on a small population before a larger group is switched. That granularity, per workload and per collection rather than once for the whole program, is what makes a staged migration genuinely low risk instead of merely described that way in a proposal.
It does not solve remote connectivity
The documented position is that this is not on its own a solution for remotely connected Windows machines, and the reason is simple: the client still has to talk to its assigned site regardless of what else changes. A cloud management gateway is what solves that, and it is an entirely separate decision with its own cost and effort attached.
Join state requirements that exclude a common case
Machines have to be hybrid joined or fully joined to the directory. Anything merely registered, which people often call workplace joined, is unsupported here. That matters more than it sounds, because in estates where personal hardware was registered rather than joined, an entire population sits outside the model and nobody realizes until the pilot.
Two routes in, depending where you start
Machines you already manage get there by establishing hybrid identity and then enrolling. Brand new internet-connected hardware approaches from the opposite direction: it joins the directory, enrolls automatically, and becomes co-managed at the moment somebody installs the Configuration Manager client on it. Most organizations run both routes concurrently.
A dashboard that shows the real state
There is a dashboard reviewing exactly which machines are genuinely co-managed, with graphs pointing at whatever needs attention. On a migration stretched across several months, that view is the only thing separating actual progress from the comfortable assumption of it, and it is worth putting in front of whoever is sponsoring the work.
A project driven by hybrid working needs two pieces, not one.
This gets addressed head on in the official documentation, which tells you how frequently the confusion arises. It produces plans that cannot work, and it produces them convincingly.
- On its own this does not manage remotely connected Windows machines, because the client still has to communicate with its assigned site whatever else you change. That sentence is published, and it is precisely the sentence most business cases quietly omit.
- Connectivity is solved by a cloud management gateway, which neither requires this nor is required by it. Each works perfectly well without the other, and they are commonly deployed together, but they are two separate decisions with two separate budgets.
- So any project driven by a workforce that stopped coming into the office needs both halves scoped independently. One piece for the cloud capability, and either a gateway or an accelerated move of the affected workloads for the connectivity.
- Uncovering the second requirement only after the first is finished is both common and entirely avoidable, and it is the difference between a plan that delivers and one that quietly stalls three months in with the budget already spent.
Four things that keep a co-management project honest.
We check the driver against what co-management does
Where the motivation is managing machines that seldom touch the corporate network, this does not solve it, because the client must still reach its assigned site. What solves that is a gateway, which neither requires this nor is required by it. We establish the real driver in the first conversation, because getting that wrong wastes a quarter.
We audit join state before anything else
Hardware has to be joined or hybrid joined, and anything merely registered cannot take part. Where registration happened organically over the years, as it does in most organizations, that population needs an identity decision made about it before any management decision is worth having. So we count them first.
We move workloads one at a time, piloted
Every workload gets a separate collection to prove itself against before a wider group is switched. Move two or three together and you forfeit the ability to attribute any problem to a particular change, and that loss, more than anything technical, is what turns a controlled migration into a month nobody enjoyed.
We take the immediate value before moving anything
Switching it on by itself produces access policies backed by compliance, remote actions, centralized health visibility and modern provisioning. Landing that first gives your organization something concrete and visible to point at while the longer conversation about which workloads move is still going on in the background.
Four phases across roughly eight to twelve weeks.
- 01Weeks 1 to 2
Establish prerequisites and the real starting point
We check the Configuration Manager version, map join states across the whole estate, and confirm both directory licensing and an Intune license on the administrator account. Machines that were registered rather than joined get listed separately, because they cannot participate and need an identity decision taken before anything else proceeds.
- Configuration Manager version and health confirmed
- Device join state inventory across the estate
- Registered-only devices identified as out of scope
- Licensing and administrator account verified
- 02Weeks 3 to 4
Enable co-management and take the immediate value
It gets switched on with every workload left where it is, which by itself delivers access policies backed by compliance, remote actions, centralized health visibility and modern provisioning. Demonstrating all of that before anybody is asked to move anything buys you a great deal of organizational confidence for very little effort.
- Co-management enabled with no workloads switched
- Automatic enrollment confirmed working
- Conditional Access with device compliance in place
- Co-management dashboard reviewed for real coverage
- 03Weeks 5 to 9
Move workloads one at a time, piloted first
Every workload gets its own pilot collection before a wider group is switched. Sequence genuinely matters here. Compliance and Windows Update are almost always the safest openers, while client applications carry the deepest existing investment and the greatest capacity to disrupt somebody working day.
- Workload order agreed with reasoning
- Pilot collection defined per workload
- Each workload validated before wider switching
- Rollback path confirmed per workload
- 04Weeks 10 to 12
Decide the connectivity question and the destination
Two decisions close the engagement. Whether a gateway is needed for your remotely connected machines, given that none of this addresses that on its own. And then the longer question of whether what you have built is a permanent hybrid architecture or a staging post on the way to full cloud management.
- Cloud management gateway decision recorded
- Long term target state agreed
- Remaining Configuration Manager dependencies documented
- Operational handover with the dashboard as the measure
Six situations where co-management is the right answer.
An organization that needs Conditional Access on Windows
Device compliance becoming available as an access signal is among the immediate benefits, arriving the moment this is enabled and long before any workload moves. Where an organization has built everything else and lacks only that, this is the shortest available route, and in our experience it is very often the specific control an insurance renewal or a SOC 2 audit is sitting waiting on.
An operator with deep Configuration Manager investment
Operating system deployment, elaborate application packaging, site infrastructure: in some organizations that represents the better part of a decade of accumulated work. Replacing all of it wholesale is wildly disproportionate to the problem. This keeps every bit of that investment intact while adding the things Configuration Manager was never going to do by itself.
A business planning an eventual migration
Treating this as a waypoint rather than a destination is entirely legitimate. Workloads shift individually with pilots ahead of each, everything untouched carries on being managed as before, and the whole transition unfolds across quarters with a genuine ability to pause or reverse at any point along the way.
A regulated firm that cannot accept a big-bang change
Switching per workload with a pilot collection behind each produces a change record that is both granular and reversible. Put that in front of a change advisory board and compare the reception with a single migration carrying one cutover date. The same advantage applies later when an examiner asks you to walk through what changed and when.
A company adopting Windows Autopilot
Modern provisioning sits among the benefits that arrive immediately. Where machines are still being built through task sequences by somebody in a back room, that capability on its own frequently justifies switching this on, leaving the much larger workload conversation open for another quarter.
A group with more than one Configuration Manager site
Since several instances can attach to one cloud tenant, this suits organizations assembled through acquisition that now find themselves operating multiple sites. You get a single consistent cloud view spanning all of them without first undertaking the far larger project of consolidating the on-premises infrastructure underneath.
How organizations manage a Configuration Manager estate.
| Feature | Co-management, staged | Configuration Manager only | Full Intune migration |
|---|---|---|---|
Conditional Access with device compliance | Yes | No | Yes |
Intune remote actions | Yes | No | Yes |
Windows Autopilot provisioning | Yes | No | Yes |
Existing ConfigMgr investment retained | Yes | Yes | No |
Workloads move independently | Yes | Not applicable | All at once |
Pilot per workload possible | Yes | Not applicable | Limited |
Remote device management | Needs a CMG | Needs a CMG | Native |
Two consoles to operate | Yes | One | One |
Rollback available | Per workload | Not applicable | Difficult |
Suits a long transition | Yes | Not a transition | No |
Ten things to have in place before enabling co-management.
Requirement
Entra ID licensing
- Detail
- Microsoft Entra ID P1 or P2, included in Enterprise Mobility and Security
Requirement
Administrator licensing
- Detail
- At least one Intune license on the account signing into the admin center
Requirement
Symptom if that is missing
- Detail
- Sign in fails with an unanticipated error occurred
Requirement
Configuration Manager version
- Detail
- A supported version of the current branch
Requirement
Multiple sites
- Detail
- Multiple Configuration Manager instances can connect to one Intune tenant
Requirement
Device join state
- Detail
- Entra hybrid joined or Entra joined, not registered only
Requirement
Intune setup
- Detail
- Intune configured with Windows automatic enrollment enabled
Requirement
Enabling co-management
- Detail
- An Entra user plus Configuration Manager Full Administrator with All scope
Requirement
Creating Entra apps from ConfigMgr
- Detail
- Entra ID Global Administrator
Requirement
Setting up a cloud management gateway
- Detail
- Azure Subscription Manager role
Five steps, and the first tests whether this is the right project.
- 1
Test the driver against what co-management delivers
What you get from enabling it is access policies backed by compliance, remote actions, health visibility and modern provisioning. What you do not get is management of remotely connected machines, since the client still has to reach its assigned site. We put your stated driver against that list before anything else happens.
- 2
Confirm prerequisites and join state
Five things get verified: a supported current branch version, directory licensing at P1 or P2, an Intune license sitting on the administrator account, automatic enrollment switched on, and machines joined or hybrid joined rather than merely registered. That final one is where estates most often discover an unexpected population.
- 3
Enable co-management without switching workloads
Every immediate benefit lands here, with nothing yet moved. Two things follow from doing it this way. Your organization has something demonstrable within weeks, and the question of enabling this becomes cleanly separated from the much longer argument about which workloads should shift and in what order.
- 4
Move workloads individually, each piloted
The seven move in an order you and we agree rather than the order they happen to be listed in, and each one meets a separate pilot collection before any wider switch. Compliance and updates tend to lead; applications, carrying the most packaging work behind them, tend to come last.
- 5
Resolve connectivity and agree the destination
Two questions close things out. Does your internet-based population need a gateway, and is what you have built a permanent architecture or a waypoint toward full cloud management. Both answers are respectable. What causes problems is never actually deciding, because an organization that has not chosen simply drifts.
What organizations ask about co-management.
Fifteen questions to answer before enabling it.
Prerequisites
- Are we on a supported Configuration Manager version?Current branch.
- Do we have Entra ID P1 or P2?Included in EMS.
- Does the admin account have an Intune license?Sign in fails without one.
- Is Windows automatic enrollment enabled?An Intune prerequisite.
- Do we have the required roles?ConfigMgr Full Administrator, All scope.
Devices
- Are devices Entra joined or hybrid joined?Registered only is unsupported.
- How many are registered rather than joined?They need an identity decision.
- Do we run more than one ConfigMgr site?Multiple can connect to one tenant.
- Which devices are internet based?They may need a CMG.
- Are devices on a supported Windows version?Intune supported platforms.
Intent
- Why are we doing this?Cloud capability or migration staging.
- Is remote management the real driver?That needs a CMG, not co-management.
- Which workload moves first?Compliance is usually safest.
- Do we have a pilot collection per workload?Piloting is supported per workload.
- Is this permanent or transitional?Both are legitimate.
Check the join state of your Windows devices.
Entra joined and hybrid joined devices can be co-managed. Devices only registered with Entra ID cannot. That count is the first constraint on any co-management plan and it takes minutes to establish.
Related Services
Explore more solutions that work great with this service