What is DDM? Apple's Declarative Device Management, explained
In Apple IT, DDM means Declarative Device Management: how Macs, iPhones and iPads now keep themselves configured. What it is, how it differs from MDM, and why it matters now.
Stabilise
In Apple IT, DDM stands for Declarative Device Management. It's the way Macs, iPhones and iPads are managed now. Instead of a management server sending a device one instruction at a time and checking back to see what happened, it tells the device what state it should be in. The device gets itself there, keeps itself there, and reports back when something changes.
If your business uses Jamf, Intune, Iru or any other MDM to manage Apple devices, DDM is already doing a lot of the work. Since macOS 27, it's the only way to manage software updates at all.
If you searched for DDM and meant a BTEC grade, a dividend model or a dental degree, this isn't that page. This one's about Apple devices.
What DDM means, in plain English
Classic MDM works like a manager sending emails. The server sends a command ("install this profile", "tell me your OS version"), the device does it, and the server has to keep asking to find out if anything changed.
DDM works more like handing someone a written brief. Apple's own definition: "you define the target configuration state of a device and the device autonomically attempts to achieve and maintain that state." That's from Apple's introduction to declarative device management (opens in a new tab).
Two things follow from that, and they're the whole point.
The device does the work. It applies the settings itself, in the background, without waiting for the server. If something drifts, it puts it back.
The device reports, rather than being polled. Apple calls this the status channel. When something the server cares about changes, like the OS version or whether an update installed, the device says so. The server doesn't have to keep asking.
For a business, that means fewer devices in a "we sent the command, not sure if it landed" state, and a management console that's closer to the truth.
How it's different from classic MDM
| Classic MDM | DDM | |
|---|---|---|
| Who drives | The server, one command at a time | The device, working to a target state |
| How the server knows what happened | It polls the device | The device reports changes on its own |
| If the device is offline | Commands wait until it checks in | It already has the brief, and keeps applying it |
| Software updates on macOS 27 | No longer functions | The only supported way |
DDM isn't a separate system you buy. Apple built it into the existing MDM protocol, so a device still enrols in your MDM service in the normal way. The difference is in how that service talks to it.
The building blocks
Apple splits DDM into four kinds of declaration. You'll rarely touch these directly, because your MDM hides them behind its own screens, but the names show up in documentation and settings.
- Configurations. The settings themselves. Apple describes them as similar to profile payloads: accounts, settings and restrictions.
- Assets. Reusable data that configurations point to, like a certificate or a user's details.
- Activations. Bundles of configurations applied together, all or nothing. They can carry conditions, so one set applies only to iPads, or only to Macs above a certain OS version, and the device checks the condition itself.
- Management. General information about the organisation and the management service.
Then there's the status channel, which is how all of that gets reported back.
What businesses use it for today
This is where DDM stops being theory. A few of the things it now handles:
Software updates. This is the big one. A software update declaration sets a target OS version and a local date and time. If the user hasn't updated by then, Apple's documentation (opens in a new tab) says the device "force installs it". That works on iOS 17 and macOS 14 or later, and doesn't need supervision.
A separate settings declaration (opens in a new tab) handles deferrals of 1 to 90 days, automatic downloads and notifications on supervised devices running iOS 18 or macOS 15 and later. For anyone working to the Cyber Essentials 14-day patch rule, the deadline declaration is how you actually enforce it.
Apps and packages. From macOS Tahoe, App Store apps, custom apps and installer packages can be deployed through DDM, as required or optional, and the status channel reports whether they installed. That's from Apple's WWDC25 session (opens in a new tab).
Moving to a new MDM without wiping. Also from WWDC25: you can reassign a device to a new management service in Apple Business Manager and set a deadline. The user gets told, and if they don't act, the migration runs on its own. The new service takes over Activation Lock and rotates the FileVault key. If you've ever put off changing MDM provider because it meant wiping every Mac, this is the change that fixes it.
Locking down system files. Service configuration files (opens in a new tab) for things like sudo, SSH and PAM can be delivered declaratively into a tamper-resistant location, and the Mac uses those ahead of its defaults. So a user can't quietly loosen them.
Security and privacy on macOS 27. This year added declarative control over which apps and binaries can run, and a single consolidated privacy prompt for app permissions. We covered both when they were announced.
Why it matters now
Apple has been moving to DDM since 2021. In 2025 it deprecated the old MDM update commands. In September 2026 it switched them off. Apple's enterprise notes for macOS 27 (opens in a new tab) put it plainly: "Legacy software update management no longer functions in all 27.0 operating systems." That covers the old update commands, queries, deferrals and recommended cadence.
So if your MDM's update policy was set up the old way, it does nothing on a Mac running macOS 27. It isn't holding updates back, and it isn't enforcing them. On a fleet that's half Tahoe and half macOS 27, you need both, set up separately. We went through what that means in practice in macOS 27, three weeks in.
Which devices support it
DDM first appeared in iOS 15 in 2021, for user enrolment only. From iOS 16, iPadOS 16, macOS 13 Ventura and tvOS 16, it works with every enrolment type (opens in a new tab) MDM supports, including supervised devices and Shared iPad.
There isn't one minimum version for everything, though. Each declaration has its own. The software update deadline needs iOS 17 or macOS 14. The update settings need iOS 18 or macOS 15. Newer features need newer systems. In practice, any Mac or iPhone still getting security updates supports the parts that matter.
Do you need to do anything?
Mostly, no. Your MDM service writes the declarations, and Jamf, Microsoft Intune and Iru all support DDM, including for software updates. If you're weighing them up, our MDM comparison covers the differences.
But it's worth asking whoever manages your devices three questions:
- Are our update policies declarative? If not, Macs on macOS 27 are ignoring them.
- Do we have a deadline set? Without one, updates are a suggestion, and the 14-day rule is your problem.
- Are old scripts doing jobs a declaration now does? Older setups often use scheduled scripts to nag about updates or fix settings that drift. A declaration does that more reliably. Third-party app lifecycle is a different job, and tools like Munki still have a place there.
If the answer to any of those is "not sure", that's the bit to fix first.
Frequently asked questions
- What does DDM stand for in Apple device management?
- Declarative Device Management. It's Apple's way of managing Macs, iPhones, iPads and other Apple devices where the management service tells the device what state it should be in, and the device works to reach and keep that state on its own, reporting back when something changes.
- Is DDM replacing MDM?
- Not exactly. DDM is an extension of Apple's MDM protocol rather than a separate system, so devices still enrol in an MDM service like Jamf, Intune or Iru. What it replaces is the old way of managing them with one-off commands and polling. For software updates the switch is already complete: legacy MDM update management no longer functions on macOS 27 and the other 27.0 operating systems.
- Which devices support DDM?
- DDM arrived with iOS 15 for user enrolment in 2021, and from iOS 16, iPadOS 16, macOS 13 Ventura and tvOS 16 it works with every MDM enrolment type. Individual features have their own minimums: the software update deadline declaration needs iOS 17 or macOS 14, and the software update settings declaration needs iOS 18 or macOS 15.
- Can DDM force a Mac to install an update?
- Yes. The software update declaration sets a target OS version and a local date and time. If the user hasn't installed the update by then, the device installs it. It doesn't need the Mac to be supervised. A separate settings declaration controls deferrals of 1 to 90 days and notifications on supervised devices.
- Do we need to do anything to use DDM?
- Mostly, your MDM service does the work. What you need to check is that your MDM supports the declarations you rely on, especially software updates, and that your update policies are set up the declarative way, because the old ones are ignored by macOS 27.
