Two different questions
Organizations that put phones, tablets and laptops in staff hands face two separate questions. The first is a policy question: whose devices may be used for work? That is the territory of a bring your own device approach. The second is a tooling and control question: how does the organization configure, secure and keep track of the devices it wants to protect? Mobile device management, usually shortened to MDM, answers the second question.
MDM can be applied to company-owned devices, and in lighter forms to personal ones. A mobile device management policy is the written set of rules explaining how the tool is used, what it controls and what employees can expect. This article is general information, not legal or IT-security advice. Privacy and employment rules vary by location, so qualified professionals should review any policy.
How MDM typically works
MDM software has two parts: a central management console used by administrators, and a connection to each device, built on features provided by the device’s operating system. The common lifecycle looks like this.
Enrollment. The device is registered with the management system. For company-owned devices this can often happen automatically when the device is first switched on, so staff receive equipment already set up. For personal devices, the user usually opts in, sometimes with a more limited profile.
Configuration. Once enrolled, administrators can push settings and applications. Examples include requiring a passcode, setting screen lock times, configuring email and wireless network access, installing approved apps and blocking certain features. Settings can be applied to groups, such as everyone in a department.
Monitoring and inventory. The system generally reports which devices exist, who has them, which operating system version they run and whether they meet the rules. Devices that fall out of line can be flagged or denied access to business resources until fixed.
Updates. Administrators can often require or schedule operating system and app updates, supporting good software patching habits.
Lost or stolen devices. Many tools can lock a device remotely, display a message or show its last known location, depending on the device and privacy settings.
Remote wipe. The administrator can send a command to erase the device, or on managed personal devices just the work data. This is a key safeguard if a device is lost, though it only works if the device can connect to the network, and it should not replace encryption of stored data. Encryption basics explains why both measures are used together.
Retirement. When a device is replaced or an employee leaves, the device is removed from management and its work data cleared.
Potential benefits
- Consistent security settings. Rather than trusting each person to configure their own device, the organization can set a baseline.
- Faster setup. Automated enrollment can reduce hands-on IT work for each new device.
- Reduced impact of loss. Lock and wipe options can limit exposure if a device goes missing.
- Visibility. An up-to-date inventory shows what exists and what needs updating.
- Controlled applications. Approved apps can be distributed and unapproved ones restricted, which can reduce risk.
- Support for compliance work. Records of settings and device status can help demonstrate that controls exist, although they do not alone satisfy any particular rule.
- Easier offboarding. Access and data can be removed in a defined way.
Limits and drawbacks
- Cost and effort. There are license fees and administrative time, and policies need ongoing upkeep.
- Complexity across platforms. Different operating systems offer different management capabilities.
- Privacy concerns. Employees may worry about what administrators can see, especially on personal devices. A policy should state in plain words what is collected and what is not.
- User friction. Strict settings can annoy staff, leading some to find workarounds, which can reduce security.
- Not a complete security system. MDM does not stop phishing, careless sharing or malicious apps by itself. It is one layer among several, alongside measures like multi-factor authentication and a security awareness training program.
- Dependence on connectivity. A device that is offline may not receive commands until it reconnects.
What an MDM policy should cover
A clear policy usually addresses:
- which devices and users are in scope
- what the organization can see, collect and control, and what it will not
- minimum security requirements and update expectations
- permitted and prohibited apps and uses
- what employees must do if a device is lost or stolen, and how quickly
- when a remote wipe may occur and what data it affects
- who is responsible for repairs, damage and replacements
- how devices are returned and cleared when roles change
- how the policy will be reviewed and updated
Employees are more likely to accept a policy they understand, so explaining the reasons as well as the rules helps.
Company-owned versus personal devices
With company-owned devices, the organization can generally apply deeper controls because it owns the hardware, and employees may reasonably expect less personal use. With personal devices, the balance shifts: organizations commonly limit controls to a protected work area on the device and avoid managing the whole thing. Either way, the least-privilege idea applies to the controls themselves, meaning collect and control no more than is needed for the security purpose.
Choosing and introducing a tool
When evaluating options, consider the device types you must support, how easily the tool works with your existing sign-in system, what it costs as headcount grows, how quickly administrators can act in an emergency, and how well it handles the privacy limits you want. Piloting with a small group, writing the policy before turning on controls, and communicating clearly tend to produce fewer problems than a sudden rollout.