Declarative Device Management Coming to Software Updates, Security
![Kandji Team Kandji Team](https://blog.kandji.io/hs-fs/hubfs/Logo/kandji-square-logo.png?width=80&height=80&name=kandji-square-logo.png)
When Apple first introduced declarative device management (DDM) in 2021, the company dubbed the new framework “the future of device management.” DDM improves on traditional MDM by pushing much of the responsibility for device management down to the device itself.
At last year’s Worldwide Developers Conference, the company doubled down on that pronouncement, saying, "The focus of future protocol features will be declarative device management." At some point in the future, the company was saying, any new advances Apple made in its device management framework would appear in DDM form rather than in the original MDM.
This year at WWDC, the company announced that the future had arrived: "The focus of new protocol features is declarative device management." It backed up that change in verb tense by announcing some potentially powerful new DDM-only capabilities for managing Apple devices that could be available to admins this fall.
Managing Software Updates with DDM
That list of new features starts with software updates on Mac, iPhone, and iPad.
The need is simple: Admins want to make sure that the devices they manage have the latest system software without unduly disrupting users or productivity. That means those admins must be able to defer updates (so they can test for compatibility) and then enforce deadlines for updates they want to proceed with. Admins also need some way to verify that devices have been updated according to those schedules.
Under the current framework, admins can use MDM commands to install updates on devices. They can defer updates by using profiles to hide available software updates from users. Those admins and the tools they use, such as Kandji, must then rely on server-side polling to periodically check in with devices to see if they’ve updated properly.
Declarative device management can make that process way more efficient. DDM configurations can be downloaded to each device, specifying the version of the OS (down to the build number) that the device should upgrade or update to; those same configurations can specify the local device’s date and time when the update should occur. DDM predicates can intelligently control the order in which updates happen—installing a specific version of a new OS, say, before a subsequent rapid security response.
![DDM software updates_shadow](https://blog.kandji.io/hs-fs/hubfs/DDM%20software%20updates_shadow.png?width=2660&height=1334&name=DDM%20software%20updates_shadow.png)
While all this is happening, the DDM protocol’s status channel can proactively report back to the admin what’s happening (or not) on all those endpoints. Those status reports can communicate why an update was initiated, which version of the software is being installed, how that update is going, and why failures (if any) have occurred. Such proactive, device-driven reporting is more timely than status updates generated by MDM polling.
DDM can also help keep users in the loop as updates are happening. On Mac, iOS, and iPadOS, users can be notified that an update is pending, and they can choose whether to proceed with it or to defer it until later. If they don’t immediately trigger an update, the software will be downloaded and prepared for installation, and notifications will appear as the deadline the admin set draws closer. And when the deadline is reached, the user will be notified that the update will be applied within an hour.
If devices aren’t yet eligible for DDM (which requires the latest Apple OSes), this DDM update workflow can co-exist with older MDM flows. (In Kandji’s implementation of DDM, if a device isn't eligible for it, we transparently and seamlessly default to the older MDM commands; we do whatever’s right for each device.)
Managing Apps with DDM
DDM can also make it easier for admins to manage the apps that users have access to, even as those users change their roles or devices change hands.
Using DDM configurations that will be made available later this year by Apple, those admins could specify which apps—which can be from the App Store or in-house—should be available on which devices. On Mac, the framework supports packages, but they can contain just one app.
Admins can declare that an app install is required or optional. If they choose the first, the app will be installed and managed as soon as the configuration is activated. If they choose the latter, the app is available for download whenever the user wishes and can be removed at will as well.
As with system software updates, DDM status items can be used to keep users and admins alike informed of the status of the update. They can tell users when an app is available and give them a chance to choose when the installation should happen and then provide feedback as that process proceeds.
Apple will also be providing MDM vendors a new framework to build Self Service apps that can, for example, display real-time installation progress to the user in a way that is simply not possible today with MDM.
Securing Apple Devices with MDM
DDM also makes it easier to keep fleets of Apple devices—particularly Mac computers—safe. It will do so specifically by
- Locking down configuration files for built-in services,
- Monitoring background tasks, and
- Installing certificate and identity credentials.
Managing Service Configuration Files
The Mac ships with a slew of built-in services, such as ssh, sudo, and the bash and zsh shells. Settings for those services are controlled by configuration files. Given the power of these utilities, admins have an understandable interest in managing those files, lest users inadvertently (or purposefully) mess with them and potentially create security gaps.
![DDM managing services_shadow](https://blog.kandji.io/hs-fs/hubfs/DDM%20managing%20services_shadow.png?width=2658&height=1328&name=DDM%20managing%20services_shadow.png)
Declarative device management will soon be able to help. It will do so by way of DDM configurations that can specify special tamper-resistant configuration files for these system services. When such configurations are activated, ZIP files containing those configurations would be downloaded and unzipped into a special location; the system services would then be automatically reconfigured to look to the new settings files.
These new DDM-installed configurations will initially be available from Apple for sshd
, sudo
, PAM, CUPS, Apache httpd
, and finally, bash
and zsh
.
Monitoring Background Tasks
Apple is also making it easier for admins to keep track of the background tasks running on the devices they manage to make sure that the tasks they want to be running are and the tasks they don’t want running aren’t.
That’s all made possible by a new DDM status item that sends a list of installed background tasks from each device. Those status reports can include the unique identifier for the background task; the user ID of the account that’s running that task; how the task is running (as launch agent or daemon, among other options); details about how launchd
initiated the process, and more.
Additionally, DDM will be able to send a status report about whether or not FileVault is enabled or not on a macOS boot volume. MDM can then be used to remediate the situation (if FileVault is not in the state the admin wants), and security-sensitive configurations can be delayed until the Mac is in the posture the admin wants.
Managing Certificate and Identity Credentials
Finally, Apple announced that it would be supporting the distribution of certificates and identity credentials via DDM. The idea is to solve a couple of problems by doing so via traditional MDM.
The biggest problem has been that different managed apps and services might need to use the same certificates or identities. But unfortunately, due to the original architecture of MDM, this has been difficult.
![DDM security_shadow](https://blog.kandji.io/hs-fs/hubfs/DDM%20security_shadow.png?width=2656&height=1349&name=DDM%20security_shadow.png)
MDM includes payloads that can install certificates and identities on endpoints—but when you needed to reference a certificate or identity within a given MDM profile, you had to include it as a payload within that same profile. If you wanted to reference a given certificate in multiple profiles, you either had to include it as a payload in each one or put all the payloads referencing that certificate into the same profile. And if you had to update a given certificate or identity, you had to be sure you did so consistently across all the profiles that used it. It was, in sum, unwieldy.
The future, Apple says, will be less so. You’ll be able to deliver a given certificate or identity as a DDM asset declaration. And that single asset can then be referenced from multiple DDM configuration declarations. If you need to update the certificate or identity, you’ll just need to do so once in the asset declaration; all the configurations depending on it will then just keep working.
Apple will be rolling out these changes with the new versions of its operating systems that will ship this fall.
About Kandji
Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.
See Kandji in Action
Experience Apple device management and security that actually gives you back your time.
See Kandji in Action
Experience Apple device management and security that actually gives you back your time.