It’s no easy feat for a company to maintain security and enforce standardized policies across a fleet of devices. 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.
In a nutshell, MDM solutions make devices behave in specific ways according to predefined security policies so companies can pass audits, prevent data breaches, and obey data privacy and security laws. Despite the word “mobile” in the name, MDMs often extend to the management of laptops, desktops, and tablets. There are many independent MDM providers and proprietary MDMs from Microsoft and Apple.
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.
You know the expression, “when the only tool you have is a hammer, then 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, and its approach can even be harmful.
An MDM solution requires employees to agree to have their devices fully managed by a central authority, their employer. While the capabilities of MDMs differ by platform, they all grant the MDM administrator a form of remote control over the device’s 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.
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:
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 can’t turn off its firewall,download unapproved applications, 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.
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.
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, setting up MDM on existing (not new) devices can present challenges and failures of installation are common.
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.
Most IT administrators and managed service providers are familiar with MDMs and can easily find IT engineers with experience running them at scale.
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:
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.
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 applications unless MDM is functioning.
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.
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 data, this turns out to be a big problem.
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.
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.
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.
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 applications.
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 security challenges.
Furthermore, if you’re trying to protect your data, MDMs can only address a single piece of the puzzle. For example, they can’t tell you who is using a 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. If MDM could solve those problems, it would, but clearly, a different approach is required.
As you may have guessed, we’re not exactly disinterested observers when it comes to this topic. At Kolide, our product is a device security and compliance solution that solves many of the problems that fall outside the scope of MDM.
Kolide gives IT admins a cross-platform (even Linux!) dashboard for all devices, so you you can see thousands of data points about your fleet. 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, Kolide 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.
Kolide 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.
Unlike MDM, Kolide 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, Kolide uses the principles of Honest Security to give users a seat at the table.
Ready to change the device management conversation? Watch our on-demand demo and see what a user-focused approach to security looks like in practice.