One of the first choices you’re confronted with once you start looking for an Apple device management vendor is whether you want a solution that works through Apple Mobile Device Management (MDM) and mobileconfig profiles, or a 3rd party agent running on the devices in your fleet. It’s an important distinction, but we’ve not seen many resources that tease out the differences in detail or explain the implications for a company’s IT operations.

To fix that, here’s a short overview of each option, its strengths, its limitations, and why you might want to choose each. We’ll also talk about solutions like Fleetsmith, which combine both agent and MDM, and why we think this is probably the best model in most cases. (There are some important limitations to this approach, and we’ll get into those too!)

Apple MDM & mobileconfig-based management

Apple Mobile Device Management (MDM) is Apple’s native protocol for device management. It’s one half of Apple Business Manager and Apple School Manager, Apple’s enterprise management program for companies and schools, the other bit being Volume Purchase Program, a system for managing software licenses and delivering apps. It’s the only game in town for managing mobile devices like iPhones, iPads, and Apple TVs, but just one option among many for Macs.

Apple MDM works through Apple’s native Apple Push Notification Service (APNS) and a mobileconfig profile, which is essentially an XML file of commands that are executed when it is applied to an Apple device. Using Apple MDM takes a little bit of upfront setup—you register with Apple, choose an MDM server (either your own or a cloud service), and have your users click through a prompt to “enroll” their device in management. From that point on, Apple will periodically send each device a message through APNS that tells it check in with the MDM server. Each time it does this, the device will connect to the server, download any mobileconfig files, execute the commands within them, delete the file, and then report back to the server with the results.

When it comes to Apple software and OS settings, mobileconfig profiles are quite powerful and can make practically any change you need. There are even some things—such as remote wipe and kernel extension whitelisting—that Apple only allows to happen through MDM.

The downside is that the way things are implemented is not always the best for security, productivity, or reliability. At a high level, many of these issues come from the fact that most Apple MDM functions are operation-based, rather than state-based. MDM can do a thing—installing a new software version or changing a setting—but it cannot determine whether that thing should be done, and this creates a lot of manual work for admins.

A good example of this in action is how Apple MDM handles the Application Layer Firewall. By default, Apple’s Configuration Profile will set the Application Firewall once, but will not enforce those settings over time. These settings can “drift” over time for any number of reasons, including changes made by 3rd party software, so most admins will want extra scripting that checks to see that they’re still set appropriately and resets them if they’re not. But a basic implementation of the MDM protocol won’t do this, and it’s not clear from the documentation that this is how the Configuration Profile works so it’s easy for an admin to miss it.

Bottom line, MDM handles the basics but it often needs extra scripting and tooling to really be an effective solution at scale. These limitations become very visible anytime you try to deal with 3rd party software—package management in particular is a manual and failure-prone process through Apple MDM.

Examples of MDM-based Apple Management solutions: simpleMDM, microMDM, Jamf Now, MobileIron


  • Native. Apple’s prefered way to do device management
  • Relatively secure
  • No need for local 3rd party software
  • Combined with DEP, allows for a nearly (but not entirely) zero-touch deployment
  • Allows customization of the Mac setup for new device deployment when combined with DEP
  • Can distribute software through Apple’s Volume Purchase Program (VPP), which is the only way to do this on iOS
  • Allows remote locking and wiping
  • Allows whitelisting of kernel extensions
  • Allows whitelisting of TCC/PPPC permissions for apps
  • If enrolled through DEP, cannot be removed or overridden by the user. If a user self-enrolls and has local admin rights, they can unenroll their device by deleting the local mobileconfig file.
  • Can be used in a BYOD situation to deliver some (but not all) management & enforcement features on iOS
  • There are many free and open-source options to do device management through the MDM protocol


  • Requires extra set-up steps with Apple
  • Operation-based rather than state-based
  • Very difficult to do package management through MDM—struggles with any install that isn’t a very basic flat package, requires a lot of manual work to keep up with updates.
  • Not well documented, and some of the documentation is, well, wrong. (Example: our fun learning journey with the iOS ScheduleOSUpdate command)
  • MDM commands often fail, usually without much visibility into why they failed
  • For existing devices, needs explicit user permission—there’s no way to enroll a device without going through a prompt.
  • Timing can be a little imprecise, once a command is issued it will take effect anywhere between 30 minutes and 24 hours later
  • Check-ins are relatively infrequent (~30 min), which is non-ideal for enforcement in high-security situations.
  • Some MDM commands aren’t enough to address the use case they’re supposed to address on their own, but most MDM-only vendors just implement the Apple MDM spec as-is without the additional tooling or scripting necessary to get the most out of the command
  • MDM-based management will take more work to implement and maintain, particularly if you go with a free or open source solution.

Why you might choose it

If you have very minimal device management needs, an MDM-only solution is probably enough for you. There are many cheap, free, or open source options that implement the MDM protocol. MDM is also the primary way to manage iOS devices, so if you don’t have to worry about any Macs, you may not need a solution with an agent.

Why you might want to stay away

If you have more complex management or security needs, or if you don’t have a dedicated IT team or significant IT resources to throw at device management, MDM-based solutions are a poor fit.

Agent-based management

Agent-based device management is an alternative model for Mac management specifically—it’s much less of a thing on mobile.

Agent-based management consists of a locally-installed agent program running on a machine and a remote server that it calls back to get instructions and report local device stats. It’s hard to generalize about agent architecture, because it can vary a lot depending on the choices the developers make. The important thing to know is that agent-based management can be extremely secure, provided the agent is designed correctly.

The advantage of agent-based management is that it gives developers maximum visibility and flexibility to control devices. The local agent can do almost anything that a local user with admin privileges can do, and there can be a much tighter coupling between the agent and the control server. This can enable near real-time device stat updates, more complicated package management and enforcement, and even things like remote desktop.

The biggest downside is that agent-based management is often hard to deploy. You need to install and run the agent on every single one of your devices, and that gets a little tricky once you have more than a handful of them. Since the scope of what a 3rd party agent can potentially do is so broad, there could also be privacy concerns with some agents, particularly if you want to use it on devices that your organization does not own.

Examples of Agent-only Apple Management solutions: Munki, osquery


  • Access to a much wider range of device facts and actions
  • Possible to change settings in some 3rd party software, not just OS
  • Allows for more direct remote management and real-time monitoring
  • Often faster and more reliable than the MDM protocol
  • Can be implemented in a more modern, secure, and easy-to-use way than the MDM protocol — state-based, rather than operation-based.


  • Requires a third party software install to your devices
  • Many agent-only solutions are focused on narrow parts of device management (e.g. package management, reporting), rather than being complete solutions on their own
  • Need to get the agent onto all of your devices—this is usually pretty complicated
  • Cannot implement zero-touch deployment through DEP
  • Cannot implement VPP
  • The agent has very wide latitude to make changes to your devices
  • Have to trust that the vendor is implementing things securely
  • Agent can be removed by the user
  • Potential privacy concerns from your users if the agent is monitoring behavior
  • Certain actions are not possible through an agent—remote lock & wipe, kext and TCC/PPPC whitelisting
  • Not useful for managing iOS or tvOS

Why you might choose it

If you need more security and reliability than the base MDM protocol provides, or if you want to gather more extensive device facts or perform more complicated configuration, an agent-based device manager might be a better fit. This is especially true if you want remote monitoring and management (RMM) capabilities, as these are only possible with an agent.

Why you might want to stay away

If you’re more cost-conscious, wary about third party software, or their are privacy concerns related to monitoring your users, you might not want an agent-based device management solution. You will need MDM if you want to take advantage of Apple Business Manager/DEP, remote lock or remote wipe a device, manage iOS devices, or silently install kernel extensions or apps that fall within the scope of a privacy policy protection. If these things are important to you, you will probably want to rule out an agent-only device management product.

Management through both MDM and agent

In some ways the agent vs. mobileconfig debate is a false choice. You can use both at the same time, and many people do. It’s long been a common practice for users of MDM-only products to supplement them with other agent-based products for package management, logging, and visibility. For the most part, the major Apple management vendors have all either moved to this model or are moving to it.

The reason for this is that MDM and agents are synergistic and cover each others’ weaknesses. A local agent adds more functionality on top of base MDM and often delivers a simpler and more reliable experience, while MDM solves the “how do I install the agent” problem, particularly when paired with DEP.

The big potential downside of an MDM and agent setup is complexity. If you’re supplementing your MDM vendor with an agent made by someone else, that’s necessarily going to be more complicated to support than a single solution. The agent and the MDM implementation can be designed to work together seamlessly to eliminate this issue (this is the approach Fleetsmith takes). Not every vendor does this however—it’s not uncommon for agent and MDM to be exposed as separate and distinct systems, even within a single product.

Examples of MDM and agent Apple management solutions: Fleetsmith, Addigy, Jamf Pro, Airwatch, Meraki Systems Manager, custom solution from open-source tools (e.g. MicroMDM+autopkg+Chef+Munki+osquery)


  • Best of both worlds: Marries the strengths of agents and the MDM protocol
  • Solves the “how do I get the agent onto new devices” problem
  • Provides the most flexibility and the widest potential functionality
  • MDM and Agent can work synergistically in many cases to deliver a better end user experience.
  • Higher degree of security is possible because MDM and Agent form redundant layers of management (e.g. MDM can reinstall agent if user deletes it)
  • Can support a “true” zero-touch deployment that goes beyond Apple Business Manager alone—local user accounts, Apple configurations, app installs, app configuration


  • Doesn’t do away with third party software
  • Still need user approval for MDM
  • Some vendors expose the agent and MDM as separate, mutually distinct ways of managing a device, which can be more complicated to administer
  • Requires a high amount of trust in the vendor—wider threat surface means the vendor really needs to take security seriously
  • The custom route here can be a lot of work to set up and maintain
  • Overkill if you don’t need to support Macs.
  • Generally, more expensive—either in license costs for commercial software or time costs for custom built systems.

Why you might choose it

Provided you need to support both Macs and mobile devices, this is the best overall approach to Apple management. Many products that were formerly agent-based have implemented MDM to move to this model.

Why you might want to stay away

This may be overkill if you have very simple needs or a very limited budget, as these more robust management products usually come at a premium cost that might not be justified by your use case. It is possible to implement this kind of solution yourself for free with open source tools, but in this case you’ll be paying with your time, and probably a lot of it.