Declarative Device Management: What Apple’s new MDM model changes for IT
Declarative device management (DDM) is Apple’s modern approach to managing devices, in which each device enforces its own policy autonomously instead of waiting for commands from a management server. It is a structural change to how Mobile Device Management (MDM) works on Apple devices, and Apple has made it the foundation for new management features. For IT teams running Apple fleets, understanding the shift matters because it changes how policy is applied, how compliance is reported, and what is possible.
This post explains what declarative device management is, how its architecture works, how it differs from the legacy MDM command model, and what the change means in practice for IT. It is written for IT and security teams managing or planning Apple deployments in 2026, when DDM has moved from a new capability to the standard model Apple is building everything else around.
One clarification before the details. Declarative device management does not replace MDM; it is a newer way for MDM to work. An organization still uses an MDM service to manage Apple devices. What changes is the mechanism underneath: instead of the server issuing commands and polling for compliance, the server sends declarations that the device stores and enforces on its own. The MDM is still there; it operates declaratively.
The problem with the legacy MDM command model
To see what DDM changes, it helps to understand how traditional MDM works. In the legacy model, the MDM server is responsible for everything. It sends commands to a device (e.g., install this profile, apply this restriction), then polls the device to check the result and ask whether it remains compliant. The device is largely passive: it does what it is told, when it is told, and reports back when asked.
This model has real limitations at scale. The server has to reach the device to change or check anything, so a device that is offline, asleep, or slow to respond falls out of sync. Compliance checking is a repeated cycle of the server asking and waiting, which is inefficient across a large fleet and always slightly out of date. And if a user removes a managed setting, nothing corrects it until the server checks in again and notices the change. The server carries all the intelligence, and the device carries none.
What declarative device management changes
Declarative device management inverts the relationship. Instead of the server sending commands and polling, it sends the device a set of declarations describing the desired state, and the device takes responsibility for reaching and maintaining that state on its own. The intelligence moves from the server to the device.
Three consequences follow directly, and they are the heart of what changes for IT.
Autonomous enforcement. The device enforces its declared state without waiting for the server. If a user removes a managed setting, the device restores it immediately, rather than staying non-compliant until the next server check-in. If the device is offline for days, it continues to enforce its declarations. Policy holds even when the server cannot be reached.
Proactive status reporting. Instead of the server repeatedly polling to ask whether the device is compliant, the device proactively reports state changes to the server through a status channel when something actually changes. The server subscribes only to the status items it cares about, so it receives relevant updates without wasteful back-and-forth. Inventory is more accurate and up to date, with less traffic.
Conditional, on-device logic. Policies can carry conditions that the device evaluates itself. A configuration can be set to apply only when the device meets certain criteria (a specific OS version, an encryption state, enrollment in a particular identity provider), and the device decides whether to apply it based on its own current state, without a round trip to the server. Management becomes context-aware at the device level.
The architecture: declarations, status, and extensibility
Apple’s declarative model rests on a small number of building blocks. Understanding them is what lets an IT team reason about how DDM behaves, so this section covers each.
Declarations are the core. A declaration is a structured document (in JSON) that describes something the device should be or do. The server defines declarations, sends them to the device, and the device stores and acts on them. There are four types of declarations, each with a distinct job.
| Declaration type | What it does |
|---|---|
| Configuration | Defines the device’s actual settings (passcode policy, Wi-Fi, VPN, restrictions). Similar to a legacy configuration profile, but stored and enforced locally by the device. |
| Asset | Supplies supporting data for a configuration, such as certificates or credentials. Can be referenced by multiple configurations to avoid duplication. |
| Activation | Defines the conditions (predicates) under which a configuration applies. The conditional logic runs on the device, not the server. |
| Management | Carries enrollment-level and organizational information, such as the device’s enrollment properties and details about the MDM service. |
The status channel is the second building block. It is a communication path that the device uses to proactively notify the server of changes to its state. The device sends status reports when relevant changes occur, and the server subscribes to the specific status items it wants, so it is notified of an OS upgrade or an encryption change without polling. Status items can also be referenced in activation predicates, which lets the device act on its own state autonomously.
Extensibility is the third. DDM is built so that new declaration types and status items can be added over time as Apple ships new capabilities, without redesigning the model. This is why Apple has been able to make declarative management the base for successive new features: the framework was designed to grow.
Activations and predicates: how conditional policy works
The activation-and-predicate mechanism is where DDM’s on-device intelligence lives, and it is worth a closer look because it differs most from legacy MDM.
A predicate is a logical condition, for example, that the OS version is iOS 17 or later, or that the device is enrolled in a specific corporate identity provider. An activation ties one or more predicates to one or more configurations. The rule is straightforward: a configuration applies only when all of its associated activations evaluate to true given the device’s current state.
The practical effect is that the server can send a device a whole set of declarations covering many possible states, and the device applies the right ones as its state changes, on its own. A configuration to enforce disk encryption can be set to activate only when the device is enrolled with the corporate identity provider. A set of advanced network settings can be set to activate only on a supported OS version. The device evaluates these conditions locally and continuously, so policy adjusts to the device’s real state without waiting on the server. Organizations can even preload declarations that activate later, when a custom management property flips them on.
How DDM interacts with legacy MDM and profiles
Declarative management does not require abandoning everything that came before. DDM and legacy profile-based management coexist on the same device, and Apple defines clear rules for how they interact, which IT needs to understand to avoid confusion.
For most overlapping settings, the system merges the policies and enforces the strictest result. If both a legacy profile and a DDM configuration set a passcode policy, the device enforces the stricter of the two, just as traditional MDM resolves overlapping settings across multiple profiles.
For two specific areas, DDM takes precedence outright: software update configurations and app management. When a declarative configuration and an equivalent legacy MDM command both address software updates or app configuration, the declarative version takes precedence. This precedence matters because software update enforcement is one of the first and highest-impact areas where organizations adopt DDM, and knowing that the declarative policy takes priority removes ambiguity during a migration.
Requirements and how organizations adopt DDM
Declarative device management is available on iOS 17, iPadOS 17, macOS 14, visionOS 1.1, and later. It is enabled by sending a specific device management command to the device, generally during or after enrollment, after which the device operates declaratively. On Mac and on iPad configured for Shared iPad, declarations can also be assigned to individual users through the user channel, not just the device.
Because the MDM service implements DDM support, what an organization can actually do declaratively depends on both the OS version and the MDM platform’s support for the relevant declaration types. Most organizations adopt DDM gradually rather than all at once, and a common, low-risk path looks as follows.
1. Confirm OS eligibility. Check the fleet inventory to confirm devices run iOS 17, iPadOS 17, macOS 14, visionOS 1.1, or later, since older versions do not support the declaration types.
2. Start with software updates. Choose a simple, high-impact first use case, most commonly declarative software update enforcement, which gives precise control over update timing while keeping users informed. This is where many organizations begin.
3. Expand to accounts and security policies. Once software updates are working declaratively, extend to account configurations and security policies over the following weeks, moving settings from legacy profiles to declarations where the platform supports it.
4. Verify enablement and predicates. Confirm that each device successfully enabled DDM via the activation command, and review activation predicates carefully, since a declaration applies only when all its activations evaluate to true. Most adoption issues trace back to OS eligibility, a device not having DDM enabled, or a predicate that never evaluates to true.
Legacy MDM vs declarative device management
The table below summarizes the practical differences that matter to an IT team deciding how to manage an Apple fleet.
| Factor | Legacy MDM command model | Declarative device management |
|---|---|---|
| Where policy runs | Server issues commands; device is passive | Device stores declarations and enforces them itself |
| Compliance checking | Server polls the device repeatedly | Device reports state changes via the status channel |
| Offline behaviour | Falls out of sync until server reconnects | Device keeps enforcing declared state offline |
| Correcting drift | Waits for the next server check-in | Device restores a removed setting immediately |
| Conditional logic | Evaluated server-side | Evaluated on-device through activation predicates |
| Efficiency at scale | Polling generates constant traffic | Event-driven reporting reduces traffic |
What it changes for IT teams in practice
Beyond the architecture, a few practical shifts are worth naming because they change how an Apple fleet feels to run day-to-day.
Compliance is more current and more trustworthy. Because devices report state changes as they happen rather than on a polling cycle, the inventory an IT team sees is closer to real time, and drift is corrected on the device rather than at the next check-in. Compliance stops being a periodic snapshot and becomes closer to a continuous property.
Policy is more resilient. A device that is offline, roaming, or rarely connected still enforces its policy, which matters for remote and field Apple deployments where the server cannot always reach the device. The policy travels with the device.
Software update enforcement gets more precise. Declarative software update management provides more precise control over update timing and enforcement while keeping users informed throughout the process, making it the common starting point for adoption.
The direction of travel is one-way. Apple has made declarative management the foundation for new management features rather than an optional alternative. New capabilities Apple ships are built on the declarative model, so adopting DDM is increasingly about staying current with where Apple management is headed, not just about gaining efficiency today.
Declarative management and your MDM
Declarative device management is an Apple protocol that enables Apple devices to communicate with a management service. It is not something a specific MDM vendor invented, nor is it a product. What an MDM platform does is implement support for the declarative model, so that when IT sets a policy in the console, the platform delivers it to Apple devices as declarations and consumes the status reports the devices send back.
This means the practical experience of DDM depends on how fully the MDM platform supports it. The declaration types a platform can send, the status items it can subscribe to, and how it surfaces declarative compliance all vary by MDM. When evaluating an MDM for an Apple fleet in 2026, it is reasonable to ask directly about declarative support, since that is where Apple management is heading.
Cross-platform MDMs, including Bento MDM, manage Apple devices alongside devices on Android, Windows, and other platforms from a single console. On the Apple side, that includes working within Apple’s management model, which is increasingly declarative, as described here; on other platforms, the equivalent management mechanisms apply. The honest framing is that declarative device management is Apple’s model for managing Apple devices, and a cross-platform MDM is the console that applies it on the Apple side while keeping the rest of a mixed fleet consistent. For an organization running only Apple hardware, an Apple-focused MDM with strong declarative support is a good fit; for a mixed fleet, a cross-platform MDM covers Apple’s model alongside others.
Frequently asked questions
Declarative device management (DDM) is Apple’s modern approach to managing devices, in which the management server sends each device a set of declarations describing its desired state, and the device enforces that state rather than waiting for server commands. It changes the mechanism underlying MDM: rather than the server issuing commands and polling for compliance, the device stores declarations, enforces them locally, and proactively reports state changes through a status channel.
In traditional MDM, the server sends commands and repeatedly polls the device to check compliance, and the device is largely passive. In declarative device management, the device carries declarations, enforces them itself, corrects drift immediately without waiting for the server, continues enforcing policy while offline, evaluates conditional logic on-device via activation predicates, and proactively reports state changes through the status channel rather than being polled. The intelligence moves from the server to the device.
No. Declarative device management is a newer way MDM works, not a replacement for it. An organization still uses an MDM service to manage Apple devices; the mechanism has changed. Instead of sending commands and polling, the MDM server sends declarations that the device stores and enforces on its own. DDM and legacy profile-based management also coexist on the same device, with defined precedence rules governing their interaction.
The four declaration types are configuration (actual device settings such as passcode, Wi-Fi, or VPN, enforced locally), asset (supporting data a configuration needs, such as certificates or credentials), activation (the conditions or predicates that determine when a configuration applies, evaluated on-device), and management (enrollment-level and organizational information, such as the device’s enrollment properties and MDM service details). Together, they let a device store, condition, and enforce policy autonomously.
Declarative device management is available on iOS 17, iPadOS 17, macOS 14, visionOS 1.1, and later. It is enabled by sending a specific device management command to the device, usually during or after enrollment. On Mac and on iPad configured for Shared iPad, declarations can also be assigned to individual users through the user channel. What an organization can do declaratively also depends on the MDM platform’s support for the relevant declaration types.
It makes compliance more current because devices report state changes as they happen rather than on a polling cycle, and drift is corrected on the device. It makes policy more resilient because devices continue to enforce it while offline. It makes software update enforcement more precise, a common starting point for adoption. And because Apple is building new management features on the declarative model, adopting DDM increasingly means staying current with where Apple device management is heading.
Most organizations adopt DDM gradually. A common path is to confirm devices run supported OS versions (iOS 17, iPadOS 17, macOS 14, visionOS 1.1, or later), start with a high-impact use case such as declarative software update enforcement, then expand to account configurations and security policies over the following weeks. Verifying that each device enabled DDM and that activation predicates evaluate correctly resolves most early issues. The MDM platform’s declarative support determines what is possible.
Related Articles
