Your identity provider and your MDM are two control planes

An identity platform and a device-management platform can both hold facts about the same employee and the same laptop. Each console can expose and sometimes change part of that state. Both can show something that looks like the truth.

The question that rarely gets written down is which of them is supposed to win when they disagree. That disagreement often appears after a migration, a reassignment, or a change made in one console that never reaches the other.

Authority is not which console can display or edit a fact. It is which system is supposed to win when two systems disagree about that fact. Everything else in this note follows from that distinction.

What each plane is authoritative for

The two planes are not competing implementations of the same idea. They answer different questions, they are consulted at different moments, and they fail in different ways.

Those are categories of responsibility rather than a feature comparison, and the line between them is drawn differently by different products. Some identity platforms hold device records. Some device-management platforms provide directory services and can act as the account source. Neither of those is a defect, and a platform that does both is frequently the correct purchase for a smaller estate.

What a combined platform does not do is answer the question. If one system holds both sets of facts, the authority question becomes internal rather than absent: which subsystem is consulted, in what order, when a policy and a device state imply different outcomes.

The dependencies that are real

A small number of couplings between the two planes are genuine. They are worth identifying precisely, because they are the ones that should survive a platform change.

A device signal used in an access decision. Where an identity platform can consume a posture or compliance signal from device management before granting access, the access decision depends on a fact the identity platform does not own. Whether that signal exists, how quickly it refreshes, and how much of the device state it actually reflects vary considerably between platform pairings, and in some combinations there is no such signal at all.

Identity lifecycle events reaching the device estate. Where identity is the lifecycle source, a joiner, mover or leaver event is authoritative there, and the device plane consumes it: a device is assigned, reassigned, or made subject to a leaver action. The device plane is not deciding whether the person still works here. It is acting on a fact it does not own.

Recovery material bound to an enrolled device. Where recovery material is escrowed into the management platform, the ability to recover a machine depends on the device record being intact and correctly associated with the right person and the right enrollment. Custody, escrow behavior and recovery paths differ by operating system and by management platform.

These are architectural dependencies. A shared console or an untested convention is not.

Coupling that is packaging

One vendor selling both planes does not merge the planes. It merges the interface.

The pattern shows up in a few recognizable ways. One console can present the user and device as a single joined view, so a change to a person can look like a change to a machine. A trust signal can work inside the suite and have no equivalent outside it, so an access policy that reads device state cannot be reproduced if either half is replaced. Assigning a device can imply an entitlement, or granting an entitlement can imply a device, without either implication being written anywhere.

None of that is dishonest, and none of it is an argument against buying both from one vendor. The risk is narrower and more specific: when a single console presents the boundary as though it were not there, the boundary does not get written down. It often becomes visible during a migration, when one half moves and the other does not, and the implicit relationships have to be reconstructed from behavior.

Where authority becomes ambiguous

Ambiguity is rarely designed. It arrives when a second system is introduced and the first is not fully retired, and both remain able to write the same fact.

Two systems can create or disable the same account. Two systems can hold a device record and disagree about who the device belongs to. Both can be right at different moments, which is what makes the condition hard to notice: nothing is broken, and every console is internally consistent.

Explicit authority is written per fact, not per platform. Who owns whether a principal exists. Who owns whether a device may be enrolled at all. Who owns the association between a person and a machine. Who owns the recovery material. A single platform can appear in more than one of those rows, and a fact can be held in several places at once. A cached copy is not a claim of ownership. The failure is not duplication. It is two systems both believing they are the source while no document says which one is.

Deciding that a change in one plane should deliberately not propagate to the other is a legitimate design decision, and it is the one most often mistaken for a broken integration. An estate that has chosen decoupling and written it down is in a better position than one where propagation happens to work and nobody knows why.

Test the boundary before something else tests it

This is an expected-versus-observed exercise, and the order matters. Writing the model down first is what makes it a test of the architecture rather than a description of current behavior.

• Write down the intended authority and the expected propagation before touching anything. For each fact both planes can hold, record which system owns it, what should propagate, and what should deliberately not.
• Use a controlled test identity and a spare enrolled device. Not a real person's account, and not a machine anyone is relying on that day.
• Change identity state. Record what changes in device management, and what stays the same by design.
• Change device-management state. Reassign the device to a different test principal, and record what identity learns from it and what it deliberately does not.
• Compare the observed result against the written model.

A mismatch is not automatically a fault. It may expose an undocumented dependency, ambiguous ownership, or a boundary that is not operating the way it was designed to. All three are cheaper to find in a test than in a migration.

Explore this expertise: Endpoint Management & MDM

All technical notes