Mobile device management (MDM)

It is based on management interfaces that Apple and Google have built directly into iOS, iPadOS, macOS and Android.

For companies, MDM is the technical prerequisite for operating company phones, tablets in the warehouse or till iPads in the shop securely and uniformly. Anyone introducing their own employee app will sooner or later also face the question of how this app gets onto the devices and how company data remains protected. This entry explains how it works, the differences between platforms, the distinctions from EMM, UEM and MAM, and the employment law points to be observed in Germany.

How mobile device management works

An MDM system consists of a server (nowadays usually operated as a cloud service), a management console for IT and the management client that is already built into the device's operating system. The device registers with the server, receives commands and configurations and reports status information back. With Apple, communication runs via the MDM protocol in combination with the Apple Push Notification service; with Android, via Google's Android management interfaces.

In everyday use, the tasks of an MDM can be divided into four building blocks: enrolling the device, configuration via profiles and policies, remote security functions and app distribution.

Enrolment: bringing the device under management

During enrolment, a device is linked to the MDM server. This can be done manually, for example via a QR code, a link or signing in with a company account. Automatic enrolment is more efficient: company devices that have been purchased are already assigned to the organisation by the manufacturer and go straight into management when they are switched on for the first time. Employees unpack the device, sign in and receive a preconfigured working environment. This approach is often referred to as zero-touch deployment.

Profiles and policies

After enrolment, the MDM pushes configurations onto the device. Typical content includes Wi-Fi and VPN access, email accounts, certificates, a passcode lock with a minimum length, encryption requirements, restrictions such as a blocked camera or disabled app installation from public stores, and requirements for operating system updates. With Apple, these packages are called configuration profiles; with Android, they are called policies. In combination with single sign-on (SSO), employees sign in once and can reach all approved company services.

Locking, locating and remote wipe

If a device is lost, IT can lock it remotely, locate it depending on the platform and device mode, and wipe it in an emergency. A full remote wipe resets the device to factory settings. For privately used devices, a selective wipe is customary instead: only company accounts, managed apps and their data are removed, while photos and private apps remain untouched. Which commands are permitted depends on whether the device belongs to the company or is private.

App distribution

The MDM installs apps automatically, updates them and removes them again when a device leaves management. This applies to public store apps as well as to in-house applications. In addition, IT can pass configuration values to managed apps, such as the server address or the tenant. Employees then no longer have to enter anything, and the app starts directly in the right context.

MDM at Apple: Apple Business, Automated Device Enrollment and User Enrollment

Apple provides a central portal for companies, which since April 2026 has been called Apple Business and combines the previous offerings Apple Business Manager, Apple Business Essentials and Apple Business Connect. There, the organisation links its MDM service, manages company accounts and buys or receives apps for distribution. For schools, the counterpart is Apple School Manager.

Automated Device Enrollment (ADE) is Apple's procedure for company-owned devices. Devices purchased from Apple or authorised resellers appear in Apple Business and are assigned to an MDM server. According to Apple's deployment documentation, devices registered in this way are automatically supervised on enrolment. This allows the full range of restrictions, such as managing Activation Lock or a managed lost mode for lost devices.

For private devices, i.e. bring your own device (BYOD), Apple offers User Enrollment. Users sign in with a managed company account, and the organisation may only set a limited set of settings and restrictions. According to Apple's description of User Enrollment, IT manages only the organisation's accounts, settings and data, not the private account. A full wipe of the private device is not provided for in this mode.

In-house iOS apps are distributed via custom apps. The app developer sets up the app in App Store Connect as a private distribution for a specific organisation, which they address via its organisation ID. After Apple's review, the app appears in the custom apps area of Apple Business. The organisation then distributes it via MDM or via redemption codes, as Apple describes on its page on volume purchasing and custom apps. The app remains invisible in the public App Store.

MDM at Android: Android Enterprise

With Android, the management framework is called Android Enterprise. In its Android Enterprise overview, Google distinguishes several deployment scenarios, which are chosen depending on ownership and purpose:

• Work profile: for private devices. Business apps and data are kept in a separate area; the organisation has no access to the private side.
• Work profile on company-owned devices: for company-owned devices that may also be used privately. The organisation manages the work profile and can additionally set some device-wide policies.
• Fully managed: for company devices used exclusively for work. Here all policies are available, including at device level.
• Dedicated: a subgroup of fully managed devices with a single purpose, such as scanners in the warehouse or kiosk terminals, which are restricted to one or a few apps.

For app distribution, Android Enterprise uses managed Google Play. IT approves apps, and on managed devices users can only install these approved apps. In-house company apps can be published as private apps that are only visible to your own organisation. This creates an internal app catalogue without having to offer the app publicly.

For the development of an employee app, this means: under both iOS and Android there is an official, non-public distribution route. An app built with cross-platform development can serve both routes at the same time.

MDM, EMM, UEM and MAM compared

Several terms have become established around MDM, and they are often mixed up in product descriptions. They describe different scopes of management: from the individual mobile device through individual apps to all of an organisation's end devices.

In practice, the boundaries are fluid. Most of today's products are UEM platforms that contain MDM and MAM as subfunctions. MAM is particularly interesting for BYOD: instead of enrolling the device, an app protection policy prevents, for example, content from the company app being copied into private apps.

Common MDM and UEM solutions

The market is large, and the choice depends on the device mix, existing infrastructure and budget. Frequently mentioned products are, without any ranking and in alphabetical order by provider:

• Apple Business: since 2026 with integrated basic functions for device management, aimed at smaller, Apple-only environments.
• Ivanti: UEM offerings with a long history in the mobile sector.
• Jamf: specialised in Apple devices, centred on Jamf Pro.
• Microsoft Intune: part of the Microsoft ecosystem, closely integrated with Microsoft Entra ID and Microsoft 365, for Windows, macOS, iOS and Android.
• Omnissa Workspace ONE: formerly VMware Workspace ONE. VMware's end-user computing division was sold by Broadcom to the investor KKR in 2024 and has since operated as Omnissa.

In addition, Google with its endpoint management functions and numerous specialised providers offer MDM for Android and Apple. For operation in the EU, the server location, a data processing agreement (DPA) and the provider's certifications are relevant selection criteria, since an MDM regularly processes personal data.

MDM and employee apps: when you need it

Not every employee app requires an MDM. An app for shift schedules or internal news that all employees use on their private smartphones can be provided via the public stores or as a progressive web app (PWA). Security is then provided by sign-in, a role model and encryption in the app itself. The article employee app: use cases, features and costs shows which variant suits which scenario.

An MDM becomes sensible or necessary if at least one of these points applies:

1. The app runs on company-owned devices that are to be set up and maintained centrally.
2. The app should not appear publicly in the stores but be distributed as a custom app or private app.
3. The app processes sensitive data, and the organisation has to enforce minimum standards such as passcode lock, encryption and up-to-date operating systems.
4. Devices are shared in shift work or restricted to one app as kiosk and scanner devices.
5. Company data must be reliably removed if a device is lost or an employee leaves.

This results in concrete requirements for app development: the app should be able to read managed app configuration so that the MDM can pass on tenants or server URLs. Access rights should be controlled via a role-based access control model (RBAC). And the distribution route via Apple Business and managed Google Play should be in the release plan from the outset, because setting up private distribution requires coordination between developer and customer.

Data protection, works councils and BYOD

MDM processes personal data: device identifiers, installed apps, operating system versions and, depending on the configuration, also locations. The rules of the GDPR therefore apply, in particular purpose limitation and data minimisation. The organisation should specify which data the MDM collects, who may view it and how long it is stored. You can find more on the basics in the glossary entry data protection.

Under German employment law, Section 87(1) no. 6 of the Works Constitution Act (BetrVG) is particularly relevant. According to it, the works council has a right of co-determination in the introduction and use of technical equipment designed to monitor the behaviour or performance of employees. According to the established case law of the Federal Labour Court, it is sufficient that a device is objectively suitable for monitoring. An actual intention to monitor is not required.

An MDM that can record locations, app usage or device status generally meets this suitability test. If there is a works council, the introduction is therefore typically regulated in a works agreement. This sets out the purpose, the data collected, access rights, the exclusion of performance and behaviour monitoring and deletion periods. This section is a general classification and does not replace legal advice in individual cases.

With BYOD, there is also the separation of private and business data. The platforms' own mechanisms help here: User Enrollment at Apple and the work profile at Android technically limit the organisation's access to the business area. In addition, a BYOD policy should regulate which data the company can see, under what conditions business data is deleted and that use is voluntary. According to the principle of least privilege, management only receives the rights it really needs.

Frequently asked questions about mobile device management (MDM)

Can my employer see my private photos and messages via MDM?

With correctly set up User Enrollment (Apple) or a work profile (Android), the organisation has no access to private content such as photos, messages or browser history. Only managed accounts, apps and settings are visible. On fully managed company devices, the scope for intervention is considerably greater, which is why private use should be clearly regulated there.

Do I absolutely need an MDM for an employee app?

No. If the app runs on private devices and is provided publicly or as a web app, solid security in the app itself is often sufficient. An MDM becomes necessary if company devices are to be managed centrally, apps distributed privately or security standards enforced at device level.

What is the difference between MDM and MAM?

MDM manages the entire device, MAM only individual apps and their data. MAM is suitable for BYOD scenarios in which employees do not want to enrol their private device, but the company wants to prevent company data leaking into private apps.

How does an in-house iOS app get onto devices without the public App Store?

Via custom apps: the developer publishes the app privately in App Store Connect for the company's organisation ID. After Apple's review, it appears in Apple Business and is distributed to the devices via MDM or provided via redemption codes.

Does the works council have to be involved in the introduction of an MDM?

If there is a works council, this is generally the case, because an MDM is objectively suitable for monitoring behaviour or performance and therefore falls under Section 87(1) no. 6 BetrVG. A works agreement regulating purpose, scope of data and access rights is customary.