Declarative device management is quietly replacing the MDM you know

For over a decade, Apple device management worked one way. The server had a picture of what the device should look like, it sent commands, the device carried them out, and the server asked periodically whether that had worked.

That model has a structural weakness, and anyone who has run a fleet has felt it: the server is the only thing that knows the policy, so nothing can be enforced while the device is out of contact.

Declarative device management inverts it. The server sends the device a set of declarations — statements about what should be true — and the device is responsible for making them true and staying that way, reporting back over a status channel when something changes.

Why the old model produced the problems it did

Three familiar frustrations all come from the same root.

Latency. A change made in the console reaches the device on the next check-in, or after a push that may or may not land. On a fleet of any size, “applied” and “actually applied” are different numbers, and reconciling them is a weekly job.

Polling cost. To know the state of the fleet, the server asks every device for its full inventory on a schedule. Most of those answers are identical to the last one. It is expensive at both ends and still out of date the moment it completes.

Silent drift. Between check-ins, a device can fall out of compliance with nothing to correct it. The console shows the state at the last successful poll, which is why compliance reporting always has an asterisk.

Declarations address all three. The device enforces its own configuration continuously, including offline, and it pushes a status update when something changes rather than waiting to be asked.

What this changes in practice

Software updates are the headline. Declarative software update enforcement lets you specify a target OS version and a deadline, and the device manages the process itself — including the countdown the user sees. It is far more reliable than the old command-based approach, which frequently deferred indefinitely on devices that were never plugged in at the right moment. If you have ever had an update campaign stall at 78%, this is the fix.

Compliance signals get faster. Because the device reports state changes as they happen, the gap between a device falling out of policy and your identity layer knowing about it shrinks from a poll interval to close to real time. That directly improves the Conditional Access pattern, where a compliance signal has to be current to be worth anything.

Fewer moving parts on the server. Less polling, less reconciliation, less of the queue-management logic that MDM platforms have accumulated.

What to ask your MDM vendor

Support varies considerably between platforms, and marketing pages are generous. The questions worth asking are specific:

• Which declaration types are supported today? Not on the roadmap — shipping, in the version you are running.
• Is declarative software update enforcement available, and is it the default path or an opt-in?
• How do declarative and legacy profiles coexist on the same device? They can and will, and the interaction is where the surprises are.
• What does the console show? A platform that supports declarations but reports on them through the old inventory model gives you the mechanism without the visibility.
• What is the minimum OS version required for the parts you care about? This sets your fleet’s floor.

What it does not change

Worth being clear, because the phrase gets stretched in vendor material.

It is not a new enrolment model. Devices still enrol the same way, and everything about getting them into Apple Business Manager is unchanged.

It is not a security product. Declarations describe configuration state, exactly as profiles did. A device that is perfectly compliant with every declaration can still be under attack, which is the same distinction as MDM not being mobile security.

And it is not something you migrate to in one movement. Both models run side by side, deliberately, and the sensible path is to move the highest-value policies first — software updates almost always — while everything else stays where it is.

What to do about it now

• Confirm what your current platform actually supports, in your version.
• Move OS update enforcement to declarations first. It is the change with the clearest operational payoff and the easiest one to measure.
• Check your fleet’s minimum OS version, because the floor determines what is available to you.
• Do not rebuild a working configuration for its own sake. Nothing here obsoletes profiles.

More on how we manage Apple fleets.