The pros and cons of mobile device management (MDM) solutions

The proliferation of endpoints and operating systems that employees use to connect to company networks makes protecting sensitive data mind-blowingly complex, especially in remote settings. These challenges often come to a head when a company is seeking a security certification like SOC 2 or ISO 27001 and realizes it can only pass an audit if it can achieve greater visibility and control over its fleet. In such situations, most companies resort to mobile device management (MDM) solutions to give their IT team centralized control over the fleet.

Ultimately, most companies of a certain size need an MDM solution (or potentially more than one) to accomplish things like remote wipes and configuring default settings for new devices.

The problem is that many companies assume they can use MDM to solve all their device security issues. That is incorrect. Leaning too hard on MDM can create problems not only for security but employee morale.

In this article, we’ll go over MDM’s strengths and weaknesses, and where it fits into a larger approach to endpoint security.

The Pros and Cons of MDM Solutions

You know the expression, “when the only tool you have is a hammer, every problem looks like a nail?” In this analogy, MDM is the hammer – a blunt instrument that’s good at solving some problems, but can’t address more nuanced issues. In fact, its approach can even be harmful.

An MDM solution requires employees to agree to have their devices fully managed by their employer. While the capabilities of MDMs differ by platform, they all grant the MDM administrator a form of remote control over the device settings and capabilities. This can be as benign as setting the default state of various security features or as extreme as forcing a device to erase itself without the consent of the person behind the keyboard.

Many workers will be familiar with MDM from a screen like the one above, that pops up to announce a forced reboot of their machine. And whether that capability is a feature or a bug is largely in the eye of the beholder.

Advantages of MDM solutions

There are several reasons why MDM solutions are so widely-used, although some of those reasons are more well-founded than others. MDMs' technological capabilities certainly play a role, but so do cost and force of habit.

Here are some of the most common reasons organizations use MDM solutions:

They are effective at rapidly achieving surface-level compliance.

MDMs can force a device into the desired compliant state (at least on the simplest level) and keep it there without consulting or negotiating with the end user.

That means a user whose device is enrolled in MDM may not be able to turn off its firewall, download unapproved apps, or put off a software update. This has some clear advantages, but it turns out to be a double-edged sword, as we’ll see in the next section.

They enable remote wipe and lock.

These capabilities are crucial for third-party audits since they ensure that sensitive data is not at risk if a device is lost or stolen or an employee is terminated.

They are easy to deploy.

The agent portion of MDM is often built into the OS, and IT can pre-configure devices before they are distributed to employees. That ensures that things like disk encryption are enabled the first time an end user logs in.

However, implementing MDM on existing (not new) devices can present challenges, and failures of installation are common.

They are inexpensive.

Since the OS vendor provides most of the functionalities that make MDM possible, the barrier to entering the MDM space is much lower than building a device management solution from scratch. The commoditization of MDM software means buyers can get competitive pricing and a wide array of vendor choices.

They are a known quantity.

Most IT administrators and managed service providers are familiar with MDMs and can easily find IT engineers with experience implementing them at scale.

There is first-party support.

OS vendors are building their own device management products (e.g., Apple Business Manager for MacOS and iOS, and Microsoft Intune for Windows) that are cheaper and often have better features than third-party MDM vendors.

Disadvantages of MDM solutions

MDMs have a clear use case, but there are still many device security problems they can’t solve, or for which their solutions create bigger problems.

Here are a few MDM drawbacks to consider:

They can’t get you to 100% compliance.

If an MDM can’t get a device compliant with brute force or automation, you’re out of luck. And that means you have no way of dealing with some of the highest-risk compliance issues, such as encrypting SSH keys, securing plain-text two-factor backup codes, or minimizing the time production data is stored on a device.

MDMs also fall short on seemingly straightforward use cases, such as deploying OS patches. It’s not uncommon for IT teams to deploy a patch or update via MDM, only for it to fail on the majority of the fleet due to errors and bugs.

And forcing employee devices to restart without their consent is so disruptive that most IT teams avoid it altogether, and rely on “nudge” tools to get users to install patches. For more on that subject, read our blog on patch management.

The point is: there are many valid security objectives that are too nuanced for the blunt instruments provided by traditional MDM solutions. And because these issues are unsolvable via MDM, they’re often declared out of scope, which creates a false (and dangerous) sense of security.

They offer limited visibility.

Most MDMs only provide a small number of essential data points about a device. IT administrators must write and deploy custom shell scripts to gather valuable data to answer pressing questions about the fleet.

If MDM isn’t installed correctly on a device, then visibility is null, which means most companies have to supplement MDM with Zero Trust solutions, to ensure that devices can’t access company apps unless MDM is functioning.

They create more work for IT.

It takes a lot of effort to maintain an MDM, both in terms of writing scripts and responding to support tickets. For example, if you want to ensure Firefox is always up to date, the MDM method is to force everybody to have Firefox and then disconnect its (already perfectly fine) auto-updating mechanism and push updates through a manual script.

You’re on your own with Linux.

As we’ve written before, MDMs are inherently incompatible with Linux endpoints. There’s no real solution to automatically address the near-infinite choices Linux offers its users regarding basic OS features like firewalls, terminals, and automatic updates.

At most organizations, Linux users make up a small percentage of the workforce, but since they deal with some of its most sensitive corporate data, this turns out to be a big problem.

They can create long-term employee morale and productivity problems.

MDM solutions take away a user’s agency over their device, leading to frustration and bad feelings between end users and IT. Here’s a common MDM complaint: An employee is in the middle of their workday when suddenly a popup appears and informs them that their laptop will restart in 10…9…8…

In the best case scenario, this is a minor update that only takes a few minutes, but it could easily be an OS update that costs employees an hour they’d been counting on or makes them late for a meeting.

In addition, end users sometimes have good reasons for violating MDM policy. A developer might need to turn off their firewall for ten seconds to test something, but MDM takes away that option.

They create as many “exceptions” as rules.

The average end user may have no choice but to put up with locked-down devices and forced restarts, but the average CEO won’t tolerate an intrusive agent telling them what they can do with their device.

Most companies with MDMs have “VIP lists” of users who are exempt from participating because they find it obnoxious and disruptive. The size of that list can quickly balloon, and everyone on it is a security risk.

They can lead to employees using Shadow IT.

Users who don’t qualify as “VIPs” can still find ways around MDMs – usually by working on their personal devices. Ironically, this exacerbates the very problem MDM was initially trying to solve: sensitive data disappearing onto invisible devices and unapproved apps.

They can’t manage BYOD or contractor devices

MDM software isn’t a good solution if you have a “bring your own device” (BYOD) policy. It’s extremely uncommon for a workplace to attempt to install MDM on workers' personal devices due to privacy concerns, so those are essentially out of scope. You’ll run into the same problem if you work with any third-party contractors, since they will likely be enrolled in MDM via their actual employer, and it’s impossible for devices to be enrolled in more than one MDM at a time.

Device security is bigger than MDMs

So here’s what we’ve established so far: MDM solutions are complex to deploy and maintain. While they’re a known quantity in the IT world, their invasiveness and less-than-stellar user experience significantly reduce their effectiveness in addressing today’s cybersecurity challenges.

Furthermore, if you’re trying to protect your corporate data, MDMs can only address a single piece of the puzzle. For example, they can’t tell you who is using a managed device: that’s what authentication is for.

The case we’re making isn’t that MDM solutions are bad; they’re incomplete. All those missing puzzle pieces–the Linux users, the VIPs, the SSH keys and sensitive data–also need to be addressed.

This gap between the devices you manage (and therefore trust) and the devices you allow to access sensitive resources (Linux machines, personal and contractor devices) is called the Access-Trust gap, and it’s one of the primary security flaws for organizations that rely exclusively on MDM for device management. If MDM could solve those problems, it would, but clearly, a different approach is required.

Embrace a user-first endpoint security solution

As you may have guessed, we’re not exactly disinterested observers when it comes to this topic. After all, our Extended Access Management (XAM) software includes a device security and compliance solution that solves many of the problems that fall outside the scope of MDM.

1Password Extended Access Management comes packaged with a Device Trust component, which gives IT admins a cross-platform (even Linux!) dashboard for all devices; you can see thousands of data points about your device inventory. IT admins can run queries and set compliance policies across a much wider array of issues than with MDM.

But our most important differentiator is how we communicate with users. Instead of forcing changes onto their devices, 1Password Extended Access Management’s Device Trust portion sends automated alerts to employees when a problem is detected. The notification includes simple self-remediation steps that teach users to resolve the issue themselves. This minimizes disruption on users (no more surprise restarts) and reduces the strain on IT resources.

1Password Extended Access Management also makes the device monitoring process transparent through our Privacy Center, which lets users see who can access their devices, what data is collected, and even the complete source code of the agent running on their devices. Even when using personal devices, employees are assured that their personal data stays private.

1Password Extended Access Management also has the ability to enforce compliance. When a device isn’t in a secure state, users can’t authenticate via SSO until they’ve fixed the problem. It’s a straightforward way to achieve total fleet compliance without robbing employees of agency.

Instead of a top-down “big brother” approach, 1Password Extended Access Management uses the principles of Honest Security to give users a seat at the table.

Ready to change the device management conversation, and to learn how XAM closes the Access-Trust gap?

Read more about XAM and see what a user-focused approach to security looks like.

Elaine Atwell

Manager of Content Marketing