Declarative Device Management: A Complete Guide

Apple's MDM protocol has worked the same way since iOS 4 in 2010: the server sends a command, the device responds, and you wait for the next check-in to find out whether anything actually happened. Declarative device management is Apple's architectural rethink of that model, introduced at WWDC 2021 and expanding significantly with every OS release since.

So what exactly is it? Instead of your MDM server sending commands and hoping devices comply, it declares a desired end state. The device receives that declaration, gets itself there, and proactively pushes its compliance status back — no polling required.

What DDM does not do is replace the legacy MDM protocol. Remote wipe, app installation via ABM, and device lock all still run on legacy MDM commands. DDM augments the existing protocol; it does not retire it. Those two systems are designed to run in parallel, indefinitely.

This article covers DDM's four core components, how it compares to legacy MDM across the dimensions that matter operationally, which Apple platforms support it and since when, what the coexistence model actually requires in practice, how to start migrating without breaking your fleet, and how to verify whether your MDM vendor's DDM support is real or just a release note.

TL;DR

What Declarative Device Management Actually Is

Apple introduced what is declarative device management as a concept at WWDC 2021 — the first time the MDM protocol's core architecture had been revisited since iOS 4. DDM (declarative device management, as it's widely abbreviated) debuted on supervised iOS/iPadOS 15 devices and arrived on macOS with Ventura (13) in October 2022.

The architecture shift is straightforward to describe but significant in practice. Legacy MDM is command/response: your server tells the device what to do, the device does it or doesn't, and the server finds out at the next check-in — potentially hours later. DDM is state-declaration: the server describes what the end state should look like, and the device figures out how to get there on its own. The device also reports back when its state changes, without waiting to be asked.

Here's what a declaration looks like in practice. Rather than pushing a mobileconfig payload, you send a JSON object like this:

{\n  "Type": "com.apple.configuration.passcode.settings",\n  "Identifier": "com.example.passcode",\n  "Payload": {\n    "MinimumLength": 8,\n    "RequireAlphanumeric": true,\n    "MaximumGracePeriod": 5\n  }\n}

The device receives that declaration, applies it, and maintains it. No mobileconfig file. No re-push if the device drifts.

DDM is built around four object types that work together:

• Declarations — JSON objects that define a desired configuration, asset, or management behavior
• Status channel — a dedicated path through which devices proactively push state changes to the MDM server
• Activations — links between status data and configuration declarations; the device applies a configuration only when a condition is true
• Predicates — the conditional logic activations evaluate, resolved entirely on the device without a server round-trip

Apple's documentation on DDM is thorough if you're building an MDM server — less useful if you're administering one. For a broader breakdown of where MDM fits relative to other endpoint management frameworks, MDM vs EMM vs UEM is a useful reference.

The Four Parts of Declarative Device Management (And What Each One Changes)

Apple's declarative device management framework is built around four object types that work together as a system. One runs continuously in the background (status channel), one defines what the device should look like (declarations), one connects those two conditionally (activations), and one lets the device make decisions without calling home (predicates). For organizations already invested in apple device management, understanding these four components is what separates a surface-level DDM rollout from one that actually changes your compliance posture.

Declarations — Telling the Device What to Look Like, Not What to Do

Declarations come in three subtypes. Configuration declarations define device settings: passcode policies, Wi-Fi, VPN, restrictions. Asset declarations carry data referenced by other declarations — certificates, credentials. Management declarations control MDM enrollment behavior and server communication.

What this means day-to-day: Instead of pushing a mobileconfig and hoping it lands, you write a declaration once. The device reads it, applies it, and keeps itself in that state. Configuration drift — what practitioners call "ghost profiles" from legacy commands that never completed cleanly — is self-corrected by the device without a server re-push.

Second-order consequence: When you retire a legacy mobileconfig in favor of a DDM declaration, check whether any other profiles in your stack reference the same configuration payload. Silent gaps can open if dependencies aren't audited first. Some admins have disabled legacy profiles expecting a DDM declaration to cover the same ground, only to find the declaration type does not yet exist in the catalog.

The Status Channel — Compliance Reporting You Can Trust

The status channel is a dedicated, bidirectional path. Devices subscribe to status items and push updates to the MDM server when state changes — no query required. As of iOS 17/macOS 14, subscribable status items include passcode compliance, OS version, device attestation, disk management state (macOS 14+), and software update install reason (macOS 14+).

What this means day-to-day: Practitioners describe the shift as going from "a compliance snapshot from some point in the past" to "compliance data you can trust for an audit right now." Under legacy MDM, compliance reports reflect state at last check-in — potentially hours old. With DDM status subscriptions active, your MDM console updates within minutes of a state change.

Trio MDM's compliance reporting updates device compliance status in real time, calculating a compliance percentage per device and a benchmark score across the fleet — a useful reference point when evaluating whether your current MDM console surfaces DDM status data at the same fidelity.

Second-order consequence: When DDM status subscriptions are active, your compliance dashboard will update more frequently. Make sure your reporting pipelines and alert thresholds are calibrated for near-real-time data, or you'll generate false-positive alerts on normal device state transitions.

Troubleshooting: If status subscriptions are active but your MDM console isn't reflecting device state changes, check whether your vendor's compliance dashboard is actually surfacing DDM status data — or just showing legacy MDM check-in data alongside it. This is a known implementation gap in some platforms.

Activations — Conditional Logic on the Device

Activations link a status subscription to a configuration declaration. The device only applies the configuration when the predicate condition evaluates as true — without any server round-trip. A practical example: a declaration that activates a stricter passcode policy only when the device's attestation status indicates it's operating off-network.

What this means day-to-day: Context-aware configuration without real-time server communication. The device evaluates its own state and acts accordingly.

Predicates — The Device's Decision Logic

Predicates are the conditional logic that activations evaluate. The device uses its locally stored status channel data to resolve the predicate true or false, then acts. Predicates are the most advanced part of DDM authoring — most admins starting out won't need them immediately. Passcode and Software Update declarations don't require complex predicate logic, so they're the right place to start.

Which Apple Platforms Support DDM, and Since When

Declarative device management on macOS arrived with Ventura in October 2022 — a full year after the iOS debut. Since then, the framework has expanded across Apple's full platform lineup. The table below is your fleet reference.

If you're running macOS 12 Monterey devices alongside macOS 13/14 machines, you have a DDM readiness gap. Those two device groups will behave differently in your MDM console: DDM-capable devices push compliance state in near real time; pre-DDM devices report at check-in intervals. Legacy MDM continues to handle the older devices without any workflow change — the gap shows up in compliance reporting fidelity, not in management capability.

Troubleshooting: If you're unsure which of your devices are DDM-capable, pull an OS version inventory from your MDM console. Anything below macOS 13 or iOS 15 will still be managed by legacy MDM commands only, and compliance reporting for those devices will reflect check-in timing, not real-time state.

What DDM Does Not Replace (And Why That Matters)

DDM has been framed by some vendors and community members as an MDM replacement. It is not. Apple's own documentation page "Combining MDM and Declarative Device Management" exists because this needed to be corrected directly.

The relationship between declarative device management and MDM is one of coexistence, not succession. As of iOS 18/macOS 15, the following functions remain legacy-only with no DDM equivalent:

• Actions like remote wipe, device lock, and forced app installation still run on legacy MDM commands — DDM has no equivalent for these
• App installation via ABM/VPP
• Full certificate inventory with expiry dates (better handled via legacy MDM queries)
• Detailed third-party app version inventory — the DDM status catalog does not yet cover this

Practitioners managing DDM in production describe maintaining "hybrid reporting" as a result: DDM for OS compliance and passcode status, legacy MDM queries for app inventory and certificate management. The community phrasing "we're still on XML configs for everything except updates" is a normal status description, not a failure condition. What it does require is an MDM console that surfaces both DDM status data and legacy MDM query data in the same compliance view — so the operational picture doesn't fragment as your fleet splits between DDM-capable and pre-DDM devices.

The DDM declaration catalog does expand with each annual OS release cycle — Apple adds new declaration types at every WWDC. What matters for planning is knowing which configuration categories already have DDM equivalents and building your migration around those first. The migration section below starts there.

One underappreciated planning note: When a colleague or new hire needs to cover your Apple environment, DDM configurations and legacy MDM profiles need to be documented separately. The mental model for each is different enough that a team member fluent in mobileconfig authoring may not immediately recognize a declaration-based workflow. Document both systems explicitly.

Where to Start: Moving From Legacy MDM to DDM Without Breaking Things

The coexistence model means there's no hard cutover. You enable DDM capabilities incrementally, alongside legacy MDM, with no re-enrollment required for existing managed devices. When planning your declarative device management adoption, the order of operations matters more than speed.

Step 1 — Audit Your Existing Mobileconfigs

Export all active configuration profiles from your MDM console and catalog them by type: passcode, Wi-Fi, VPN, restrictions, certificates. Then cross-reference against Apple's declarative device management documentation, which lists all current declaration types — cross-reference it against your active mobileconfig list before disabling any legacy profiles.

Do not disable a legacy profile expecting a DDM declaration to cover it until you've confirmed two things: the declaration type exists in Apple's current catalog, and your vendor exposes it in the admin console. Admins who skip this audit have ended up with configuration gaps that were silent — no error, just missing enforcement.

Step 2 — Enable Software Update Enforcement First

Community consensus is clear: Software Update enforcement is the highest-value, lowest-risk first DDM declaration to enable. Legacy MDM Software Update commands are advisory at best — users can dismiss them, and compliance reports mark the device as managed even when it's three OS versions behind.

DDM's com.apple.configuration.softwareupdate.enforcement.specific declaration changes that materially. It enforces a target OS version with a hard deadline the device applies independently of user action. This requires no re-enrollment and is testable on a device subset before fleet-wide rollout.

One thing admins in production don't always anticipate: users who've spent years dismissing update prompts will not be expecting a hard deadline. A one-paragraph email explaining the change and the timeline prevents most of the help desk fallout.

Troubleshooting: If DDM Software Update enforcement isn't applying on target devices, check first whether those devices are running the minimum supported OS version and whether your MDM server is actually syncing declarations — or still routing update requests through legacy MDM commands.

If your current vendor's DDM implementation is limited to the backend handshake only, the "How Trio MDM Helps" section below covers what substantive DDM support looks like in practice — or you can browse best apple mdm for a broader vendor comparison.

Step 3 — Test Declarations With Apple Configurator 2 Before Deploying

Before pushing declarations through the MDM server, use Apple Configurator 2 (free, Mac App Store) to validate JSON declaration syntax locally. As of its 2024 update, Apple Configurator 2 added declaration manifest preview capability — if you're running an older version of the app, update it before using it for DDM testing. This reduces the risk of malformed declarations reaching a production fleet, which matters more with JSON than with legacy XML mobileconfig files because MDM admin UIs for DDM declarations are less mature and offer less inline validation.

Does Your MDM Vendor Actually Support DDM? Here's How to Check

"Does my MDM vendor actually support DDM?" is the most frequently asked, least consistently answered question in Mac admin communities. The reason it keeps coming up is that vendors use "DDM support" to mean different things. Not all vendors implement Apple DDM to the same depth — some have the backend protocol handshake in place but have not built declaration authoring or DDM status surfacing into the admin UI at all.

Apply these five criteria to your current vendor before investing in migration:

• Can you build declarations natively in the admin console? If you're still uploading XML mobileconfig files with DDM running invisibly in the background, the admin-facing workflow has not changed.
• Does the compliance dashboard display DDM status subscription data? Specifically: does it show passcode compliance and OS version state updating in near real time, not just at check-in intervals?
• Does the console expose Software Update enforcement via declarations? Not just the legacy "schedule update" MDM command — a declarative enforcement option with deadline logic.
• Does the console log declaration sync events? So you can verify declarations are actually being sent and acknowledged, and troubleshoot when they silently fail.
• Does the vendor's documentation reference specific DDM declaration type identifiers? Vendors with substantive DDM support will use identifiers like com.apple.configuration.passcode.settings. Vendors with surface-level support use generic marketing language only.

The question isn't whether a vendor says they support DDM — it's whether the console actually lets you use it.

If you're evaluating platforms with a broader lens, unified endpoint management covers how UEM capabilities relate to Apple-specific management depth.

How Trio MDM Helps You Manage Apple Devices

The workflow concerns this article has covered — compliance reporting fidelity, Software Update control, and consistent management across a mixed Apple fleet — are exactly what Trio MDM is built to address.

Trio MDM integrates directly with Apple Business Manager and Apple School Manager, using Automated Device Enrollment (DEP) for zero-touch provisioning. Newly assigned devices enroll automatically, establishing the supervised status required for full DDM capability from day one.

On compliance reporting, Trio MDM updates device compliance status in real time, calculating a compliance percentage per device and a company-wide benchmark score. That is the kind of compliance visibility that DDM's status channel architecture is designed to produce — and Trio MDM surfaces it across your fleet. For macOS-specific compliance depth, Trio MDM supports CIS Level 1 and Level 2 benchmarks, covering the current macOS version and one version prior.

Trio MDM also enforces device-wide security controls and automatically applies compliance configurations without requiring manual policy setup per device — which means your fleet stays compliant without requiring you to re-push policies every time a device drifts. Policy automation, security profiles, remote lock, and remote wipe are all available from a single console.

Trio MDM runs on annual per-device pricing with no minimum — you're not locked into a seat count that doesn't match your fleet size — and volume discounts are negotiable. You can test it on your fleet with a 14-day free trial.

Start your free trial or book a demo to walk through your specific fleet configuration with someone who knows the product.