MDM

MDM has three parts: a console with a server, an agent or management profile on each device, and the management interface of the device's operating system. NIST SP 800-124 Rev. 2 (May 2023) describes enterprise mobility management (EMM), also called unified endpoint management (UEM), as a solution to deploy, configure and actively manage mobile devices. An EMM suite may include MDM, mobile application management (MAM) and mobile threat defense. In everyday use, MDM is the name for the whole category.

The operating system decides what an MDM can do. Major mobile platforms expose management APIs that ordinary apps cannot call: controlling app behavior, configuring device and security settings and reading sensitive device information. Access to these APIs may be limited to developers vetted by the platform owner, has to be accepted by the user or the IT staff, and most platforms allow only one MDM to control them. On Android the on-device part is the device policy controller (DPC), which Google describes as the bridge between the EMM console and the device.

A device is enrolled, receives policies, checks in with the server at intervals, reports its state and executes commands. NIST lists the typical controls:

• manage wireless interfaces such as Wi-Fi, Bluetooth and NFC;
• restrict access to hardware (for example the camera) and to features (for example copy and paste);
• detect changes to the approved security configuration and block access from rooted devices or outdated OS versions;
• disable developer mode;
• require a passcode, lock the device remotely, and wipe it after too many failed unlock attempts or after a set time without checking in;
• restrict app stores and apps by allowlist or blocklist, and keep an inventory of installed apps.

The ownership model sets the limits. NIST describes fully managed organization devices, corporate-owned personally enabled devices (COPE), and bring your own device (BYOD), where MAM instead of full MDM can address the owner's privacy concerns. On Android, a work profile keeps work apps and data separate from personal ones. When the profile owner calls wipeData, the profile and its data are removed and the personal side stays. A full factory reset with wipeDevice is reserved for the device owner or the profile owner of an organization-owned device.

For a company that buys MDM for standard phones, the question is which product covers its ownership model. For a company that builds its own device or operating system, management is part of the product, and these requirements apply:

• The ownership model is explicit per device: company-owned, personally enabled or personal. It decides what an administrator may see, restrict and wipe, and the panel shows it next to every device.
• Policy is versioned data per organization and group, as described under deep packet inspection, and the console shows devices that drift from it.
• The device enforces policy offline. A check-in interval, a warning threshold and an automatic wipe threshold run on the device itself, because a stolen phone will not talk to the server. The server computes the same status for the console.
• Every remote command is confirmed and logged: who sent it, when the device received it and what happened. If a wipe fails silently, the operator believes the data is gone when it is not.
• The console is the most valuable target in the system. NIST lists theft of EMM administrator credentials and malicious insiders among the threats, so the panel needs strong authentication, roles and an audit trail.
• Device integrity is checked. SIM card changes, USB modes, debugging and modified system files are signals the device reports and the policy acts on.
• Management and updates belong together. Agent and OS changes reach devices through the OTA channel; policy syncs from the server. Devices on old versions are visible in the console.
• Building on stock Android has a limit: Android Enterprise no longer accepts new registrations of custom DPCs to the Google Play EMM API. A product that controls its own OS build can place management inside the system instead.

From 2019 to 2021 we built Raw Control's hardened Android-based OS, with management built into the operating system and an administration panel for companies and groups.

Offline protection was configured per company or group with three times: how often the device reports to the backend, when the user gets a warning about lost communication, and when the device wipes itself. With the example values of 5, 60 and 120 minutes, the console shows OK while the device reports at least every 5 minutes, WARNING after 5 minutes of silence, CRITICAL after 60 minutes and WIPED after 120, together with the time of the planned wipe. Later fixes covered the warning shown before the wipe and a case where a failed account sync prevented the wipe.

The panel and API managed Bluetooth allowlists and blocklists by MAC address and device class. The phone synced them, blocked connections to untrusted devices and removed already paired ones. When a locked phone lost its SIM card, a 10-minute countdown to reset started; it stopped when the user unlocked the phone with two-factor authentication or put the same SIM back. Other controls covered access to the camera, microphone, location and other sensors at system level, data quotas per app with blocking at the limit, device attestation checks (integrity reports that the phone sent and the backend stored and verified), and the USB modes an administrator allows.