For Mac Admins navigating the future of device management, understanding declarative device management (DDM) and Apple’s evolving approach is critical. In announcing DDM and releasing some details, Apple was looking for the MDM (Mobile Device Management) providers out there to start exploring this way of managing devices, and looking for feedback. From what I’ve seen, DDM is only lightly being implemented with heavy guardrails, and some MDM providers are just sticking with Legacy Profiles despite clear signs that this is no longer the way.
I am down the rabbit hole of DDM, and Apple’s implementation of this new method of managing devices. Join me on the journey.
Legacy Profiles: Why They’re Fading Out
Apple has a way with words. When they’re ready to retire a technology, they mark it as “Legacy.” As a former Apple Authorized Service Provider, I’ve seen this happen over and over: when models of iMacs, MacBooks, or even iPods reached “Legacy” status, parts were sometimes available, but official support was done. Now, Apple has granted that same “Legacy” label to plist-based .mobileconfig profiles (configuration files in Apple’s property list format)—the traditional method for configuring devices through an MDM.
Many MDM providers still rely on these legacy profiles, offering user-friendly interfaces to configure them without needing direct plist editing. Some may rely on Configurator 2 or iMazing Profile Editor. But the writing’s on the wall: legacy profiles aren’t future-proof. As of macOS 15.1 Sequoia, legacy profiles still function—for now. But Apple is actively phasing them out, and certain settings, like passcode policies, already fail to enforce correctly.
Also at issue with legacy profiles is the nature of delivering the profiles. As Mac Admins, we like to joke that MDM profiles are like UDP packets. We use a network term to illustrate how MDM profiles are delivered: in this case, like UDP packets. In a TCP/IP-based network, UDP packets are sent blindly, never asking for a receipt for delivery (to save time, and because it doesn’t matter if that packet made it). Whereas TCP packets have a return receipt to confirm that the packet of data arrived at its intended destination.
One way of verifying profiles were delivered and settings were enforced was to use osquery to verify the current state of the device.
What is DDM?
Declarative device management is more than just a TCP implementation of profile delivery. DDM describes to the device how it should be configured, and the device enforces that configuration. Additionally, the device will call back to the MDM server to provide a status update.
But, DDM is much more than a handful of configuration settings. DDM allows for describing the state a Mac Admin desires the device to be in before, say connecting to the corporate network using a VPN. Maybe you require that FileVault full disk encryption is enabled, and the firewall enabled before a device connects to the VPN. The idea is that we can declare the desired state of the device, and the device enforces that state locally.
What most Mac Admins have experienced with DDM is managing software updates. Apple to an extent Sherlocked the open-source Nudge project that admins have used for years to enforce software updates. And, it’s pretty cool. Mac Admins can declare a minimum version and a specific date and time to install it on a device. Admins can add links to corporate websites for policy, and we can even push specific builds in the declaration. From what I have seen, not one MDM provider has implemented this well, but we will get into more of that later.
What’s not been made clear until recently is how the cadence of software updates works with DDM. What I have also discovered is that once you choose DDM, the legacy profiles and legacy MDM commands no longer work. You cannot unring the bell, so to speak. MDM providers don’t understand this, and all are slow on the uptake of these new methods.
In short, DDM improves reliability, reduces network dependency, and ensures devices can enforce configurations locally—resulting in a more consistent experience for users and administrators alike.
The DDM paradigm shift.
With DDM, devices gain autonomy. Instead of triggering actions like the InstallASAP command, the MDM simply declares the desired state, and the device enforces it independently. And, if a device somehow falls out of the desired state, it will work to get to the desired state. That could be in the form of prompting the user to run an update, or forcing a new password before unlocking the device.
One capability still missing from MDM providers is status listeners for status subscriptions. Listeners are feedback from the device to the MDM provider that the profile is in place and the device is compliant. Think of this as an osquery-level investigation of device state, reported to the MDM provider, and not reliant on a third-party to investigate. We see status items of passcode.is-compliant, passcode.is-present , softwareupdate.beta-enrollment, and softwareupdate.pending-version for configurations.
Preparing for the Shift to DDM
As Apple moves away from legacy profiles, the case for adopting Declarative Device Management becomes stronger. DDM represents a fundamental shift in how we approach device management, giving more autonomy to devices and allowing Mac Admins to focus on defining the desired state rather than micromanaging each change. While DDM adoption is still evolving, it’s clear that this is the direction Apple is heading.
In my next post, I’ll dive deeper into the hands-on side of DDM. We’ll explore the available configuration profiles, walk through the process of creating and implementing them, and look at effective ways to verify that settings are applied correctly. If you’re ready to get started with DDM and see it in action, stay tuned—it’s time to unlock the full potential of declarative management.