The management loop
Every MDM, whatever the brand, runs the same loop:
- Enroll. The device joins management and the agent receives its rights.
- Apply policy. The server sends the rules for the device’s group, and the agent enforces them.
- Stay connected. The server and the device keep a secure channel for commands and changes.
- Report. The device sends its status, inventory and events back to the server.
Steps 2 to 4 repeat as long as the device is in use. When a policy changes in the console, the loop carries the change to every affected device.
Step 1: Enrollment
Enrollment is the moment a device comes under management. On Android, it decides how much control the organization will have, so it is the most important step to get right.
For a company-owned device, enrollment starts on a new or factory reset device, on the first setup screen. The most common methods are:
- QR code. Tap the welcome screen several times, then scan a QR code generated by the MDM. The code tells the device where to download the agent and which server to contact.
- NFC. Touch the new device with another device that carries the setup data.
- Zero-touch enrollment. On supported devices bought from participating resellers, the device is registered to the organization before delivery. When it is switched on and connected to the network, it sets itself up with no technician involved.
- DPC identifier. Type a short code, starting with
afw#, in place of a Google account during setup to download the agent.
For a personal device, the user installs the agent from an app store or a link and follows a short wizard that creates a work profile.
During enrollment, the device usually also receives an enrollment profile: which group it belongs to, which policy applies and, if needed, which user it is assigned to. Methods for each case are covered in device enrollment.
Step 2: Management rights on the device
An Android app cannot normally change system settings or install other apps silently. The MDM agent can, because Android gives it a special role during enrollment. There are two such roles, defined by Android Enterprise.
| Role | Scope | Used for |
|---|---|---|
| Device Owner | The whole device | Company-owned devices, fully managed or dedicated (kiosk) |
| Profile Owner | A separate work profile only | Personal devices (BYOD) and company-owned devices with personal use (COPE) |
A Device Owner can enforce password rules, disable hardware such as the camera or USB, install and remove apps silently, block factory reset, lock the device to a single app and wipe it remotely.
A Profile Owner has the same kinds of controls, but only inside the work profile. The personal side of the device stays outside the organization’s reach. This split is what makes work profiles on personal devices acceptable to employees.
The role is chosen at enrollment and cannot be upgraded later. A device enrolled with a work profile cannot become fully managed without a factory reset. That is why choosing the right ownership model before rollout matters.
Step 3: Policies
A policy is a bundle of rules applied to a group of devices. Typical contents:
- Password and screen lock requirements
- Hardware restrictions: camera, Bluetooth, USB, microphone
- Operating system restrictions: settings access, factory reset, unknown sources, screenshots
- Network settings: Wi-Fi profiles, APN, VPN, certificates
- Apps to install, allow or block
- Kiosk configuration
Policies are assigned to groups, such as “warehouse handhelds” or “sales tablets, Region North”. When a device moves to another group, it receives that group’s policy automatically. Administrators change the policy once, not on each device. See policies.
The agent applies a policy through Android’s own management APIs. Many rules are then enforced by the operating system itself, which is why they stay in force even when the device is offline.
Step 4: The connection between server and device
The server needs a way to reach devices when something changes. There are two common approaches.
- Push through a platform service. The server sends a short wake-up message through a cloud messaging service, and the device then contacts the server to fetch the change.
- A persistent connection. The agent keeps its own secure connection open to the server, so commands arrive within seconds without relying on an outside service.
A persistent connection matters in two cases: when actions must happen immediately, such as locking a stolen device or starting a remote support session, and when the devices work in a closed network where outside messaging services are not reachable.
All traffic should be encrypted, and the device should check that it is talking to the right server. Real-time features such as Live Control build on this channel.
Step 5: Reporting
The final part of the loop is the device telling the server about itself. A typical report includes:
- Hardware model, serial number and identifiers
- OS version and security patch level
- Installed apps and their versions
- Battery, storage, network and SIM information
- Location, if a policy turns it on
- Policy results: which rules were applied and which failed
The server uses these reports for inventory, dashboards and compliance checks. If a device stops reporting, falls behind on updates or fails an integrity check, a compliance rule can respond automatically. Reports can also be exported for audits. See reports.
Cloud and on-premises architecture
The loop is the same wherever the server runs. What changes is who operates it and where the data lives.
| Cloud (SaaS) | On-premises | |
|---|---|---|
| Who runs the server | The vendor | Your IT team |
| Where device data is stored | The vendor’s data center | Your own infrastructure |
| Network requirement | Devices reach the server over the internet | Devices reach the server over your network, which can be closed |
| Updates | Applied by the vendor | Scheduled by your team |
| Typical fit | Fast start, small IT teams | Strict data residency, closed networks |
The trade-offs are covered in cloud vs on-premises MDM.
An example, end to end
A logistics company receives 200 new handhelds for its warehouses.
- A technician scans the enrollment QR code on each device. The agent installs, becomes Device Owner and joins the “Warehouse” group.
- The group policy installs the scanning app, sets the warehouse Wi-Fi and locks the device into kiosk mode with that app only.
- A week later, a new app version is released. The administrator updates it once in the console, and every device installs it over its live connection.
- One device stops reporting. The dashboard shows its last location, and the device is found in a delivery truck.
The same loop works for a hospital’s tablets or a school’s classroom set. Only the policies change. See transport and logistics for more on this sector.
How DeepManage does it
DeepManage follows this loop on Android. Devices enroll by QR code or NFC, and the agent becomes Device Owner or Profile Owner depending on the enrollment profile. Each device keeps its own real-time connection to the server, which is what makes instant commands and Live Control possible, including in closed networks. You can run the server in the cloud or on-premises.