How Apple is changing MDM in iOS 15

One of the biggest enterprise additions to iOS 15 and iPadOS 15 is a significant change to Apple’s MDM (mobile device management) protocol. Earlier MDM changes primarily focused on adding new management, security, or deployment features, extending what MDM could enforce. Declarative management, introduced at the company’s developer conference in June, is the first change that modifies the protocol itself.

While declarative management will make its debut with iOS 15 and iPadOS 15, Apple said it will also be supported in macOS Monterey, though not right away.

Apple MDM today

Before we get to what declarative management is, let’s take a a brief recap of Apple’s MDM protocol as it has previously been implemented.

Apple MDM encompasses a handful of different components: configuration and provisioning profiles, the MDM service, and various MDM commands.

Configuration profiles are strings of XML data that are formatted as .plist files. These actually predate Apple MDM and were first introduced in iPhone OS 2 alongside support for Exchange. These files can configure or restrict most of the iOS experience. They can even be used to preconfigure enterprise app settings if needed. The contents of a profile are often referred to as a payload.

Provisioning profiles do just what the name implies: they provision various certificates and other security elements that are key to managed devices that enable them to connect with servers/services that are needed to access enterprise resources.

An MDM server/service is the glue that ties together the various devices in an enterprise and assigns profiles to them. MDM can also be used to to query devices for their current state and send MDM commands such as requiring a new password, wiping corporate data from a lost device, or clearing a passcode when the user has forgotten it.

Polling devices for their status is one of the big things that makes MDM work. MDM servers can query devices on an automated basis or on-demand. This polling, which can query for almost every piece of device configuration and then send updates to devices to meet compliance, requires a lot of bandwidth for the device and server/services. One of the goals of declarative management is to eliminate this back-and-forth approach.

The result can be a reduction in server load and bandwidth for the device (and the network it’s connected to). It also affects things like bandwidth for apps and overall battery life.

So what is declarative management? And why should I care?

Declarative management pushes much of the determination about compliance — and, to some extent, remediation from non-compliance — to the device. This offloads functionality from the MDM server/service.

Instead of relying on the server polling to get a current device status, devices are now empowered to monitor their own device state and to proactively communicate that to the server/service as needed. They can also evaluate changes to their device state and take appropriate actions, even if a device is offline and cannot connect to the management services or the internet as a whole.

Goodbye plists, hello JSON

One difference between traditional MDM and declarative MDM is how data is communicated and interpreted. Up till now, configuration profiles have existed as a .plist text files. Declarative management drops that approach in favor JSON objects.

While this is a change, most of these XML data strings are essentially the same despite the difference in file type. I expect that MDM vendors will make this change absolutely invisible to the admin.

Declarations in four types

Under the new system, declarations include four types of directives to managed devices: configurations, assets, activations, and management.

Configuration: This type of declaration aligns closely with configuration profiles in traditional MDM. The declarations designate the various settings, restrictions, and other types of management supported by Apple devices.

Asset: This type of declaration provides supporting information to devices. This includes things like user account information, security certificates, and MDM-related service URLs. To some extent they function like provisioning profiles in traditional MDM (typically used to deploy certificates).

One major advantage to assets: instead of installing multiple certificates (or multiple instances of the same certificate), an asset declaration can be applied to multiple configurations. This should offer IT departments the ability to streamline certificate management; in particular, it should help in deploying updated certificates, since there will be fewer certificates that need to be deployed.

Activation: Activations are essentially rules (referred to as predicates) for when specific configurations or actions should occur. Because declarations are processed on-device, a device will note when its state has changed. It will then determine if the changes have resulted in a state that meets the requirements of an activation (or if it no longer meets the state of an activation) and will proactively apply that activation and its related configuration data in real time.

One of the advantages to activations is that it’s possible to push configuration data to a large swath of devices even if some won’t apply to all of the devices at the time of deployment. Activations allow those configurations to be on-device but in inactive until a change in device state matches an activation and activates the related configuration.

Management: Management declarations are used to send relatively static information to devices. This includes the capabilities of the MDM server or service. This information lets the device know what MDM and declarative management capabilities are available. This will likely become more important going forward as Apple begins to roll out more declarative capabilities and extend them to devices other than iPhones and iPads.

Status

Alongside declarations, there’s a status channel that MDM uses to ensure that the server is aware of the device state. Since declarations apply changes to the device state independently, it’s crucial that there be a way for a device to report its new state to the MDM server or service. This replaces traditional MDM’s need to poll devices periodically for their device state and ensures that device state data is up to date in real time.

The benefits of this are huge, because it releases a lot of the server and network load required to regularly poll all the devices in an organization. It also has the potential to increase devices’ battery life, since the amount of data reported is minimized and only happens when a device state changes. And, as I noted, it has the potential to spot problems, such as a device that’s out of compliance or experiencing unusual (and possibly suspicious) activity, faster because the information gets sent immediately as changes are made.

Extensibility

Extensibility refers to MDM’s ability for devices and MDM servers/services to report to each other what capabilities are available. This can then trigger actions, deploy payloads, and enable new capabilities — and all this can happen immediately.

For more information, you can view the declarative management deep dive from WWDC.

Moving from traditional MDM to declarative management

The biggest question for IT around declarative management is when (and how) does this transition occur? The good news is that it really is up to each organization if or when to adopt declarative management. Apple seems to be planning a soft rollout of declarative management — at first it will only be available to iOS 15 and iPadOS 15 devices under user enrollment (typically preferred for BYOD), and most declarations will not be initially available. As of this writing, for example, only account and passcode configurations are planned to be part of the iOS 15 rollout. Support for macOS Monterey is planned for some time in the future.

It’s also important to realize that, for the moment, declarative management is optional. Eventually, I expect we’ll see traditional MDM deprecated, but I think that that will be a ways off in the future. Until then, traditional MDM will be supported alongside declarative management. This should be a relief for most IT departments.

This is a good time to start thinking about how your current MDM platform and your existing policy and profile portfolio will be able to take advantage of declarative management and where you’ll be able to streamline management using declarations in the future.

This may also be a good time to check in with your current MDM vendor to see what their plan is for supporting declarative management and how they expect it will change the various workflows of their products. Going even further, this could be an ideal time to check out other enterprise mobility vendors (see “With EMM, should you go full stack or best of breed?”) to see what their plans are and to reassess if you want to continue with your current provider.

Ultimately, declarative management is going to return a lot of benefits and make Apple device management a much simpler and less network-intensive process. There will be a learning curve and some trial and error — for customers, vendors, and Apple — but the path looks extremely promising and even exciting.