Enterprise Mobility Management: EMM, MDM and BYOD Security

MDM (Mobile Device Management) is the foundational layer — it covers device enrollment, configuration profile deployment, remote wipe, application inventory, and device-level policy enforcement. EMM (Enterprise Mobility Management) adds mobile application management (MAM), mobile content management (MCM), and identity/access management layers on top of the MDM foundation. UEM (Unified Endpoint Management) extends the same management console to cover all endpoint types — smartphones, tablets, laptops, desktops, and in some platforms, IoT devices — through a single policy engine and administrative interface. In practice, most current enterprise platforms marketed as UEM include the full EMM capability stack, and the distinction between EMM and UEM is primarily a marketing boundary rather than a functional one.

MAM controls specific applications on a device rather than the device itself. Managed applications receive security policies — encryption of app data at rest, copy-paste restrictions between managed and unmanaged apps, PIN requirements for app access, remote wipe of app data without affecting personal content — without requiring device enrollment. MAM is preferred in BYOD scenarios where employees are unwilling to enroll personal devices in full MDM but the organization needs to enforce data protection on corporate applications (email, documents, collaboration tools). Microsoft Intune's App Protection Policies provide MAM-without-enrollment for Microsoft 365 apps; BlackBerry UEM's application management can similarly operate without device enrollment. The tradeoff is that MAM provides no visibility into device health — whether the device is jailbroken, running outdated OS versions, or enrolled in a competitor MDM — and organizations with stricter compliance requirements may require at minimum the device attestation data available only from device enrollment.

Apple's Automated Device Enrollment (ADE), formerly Device Enrollment Program (DEP), allows IT administrators to configure iOS and macOS devices before they ship to end users — the device enrolls into the organization's MDM automatically on first boot via Apple Business Manager (ABM) without any end-user setup steps. ADE requires the devices to be registered with ABM through an Apple Authorized Reseller or Apple directly at time of purchase. Once registered, devices appear in the ABM portal and can be assigned to an MDM server. On first boot, the Setup Assistant is customized to show or skip specific panes, and the MDM enrollment is triggered automatically. ADE-enrolled devices can be configured as supervised, which enables a broader set of MDM restrictions and management capabilities than standard enrollment. Devices enrolled through ADE cannot be permanently unenrolled by the user — the MDM profile is locked to the device.

Android Enterprise provides four primary enrollment modes: (1) Work Profile — for personally-owned BYOD devices, creates a managed container for work apps while leaving personal apps and data untouched; (2) Fully Managed — for corporate-owned devices, places the entire device under MDM control starting at initial setup; (3) Dedicated Device — for corporate-owned single-purpose devices (kiosks, shared task-worker devices), locks the device to specific applications and disables standard Android launcher; (4) Fully Managed with Work Profile (also called COPE — Corporate Owned Personally Enabled) — for corporate-owned devices where employees also use the device personally, provides full device management with a separate personal profile the IT team cannot access. The appropriate mode depends on device ownership (personal vs. corporate) and use pattern (knowledge worker vs. task worker vs. kiosk). Google's zero-touch enrollment provisions fully managed and dedicated devices without end-user setup steps.

Managed App Configuration, defined by the AppConfig Community specification, is a standard mechanism for enterprise MDM platforms to push configuration data directly into managed applications without requiring end users to manually enter settings. Supported on both iOS (using the Managed App Config standard from Apple's MDM protocol) and Android Enterprise (using Managed Configurations via the Android Enterprise API), AppConfig allows IT administrators to pre-configure applications — VPN client settings, email server addresses, identity provider URLs, and app-specific policy parameters — at deployment time through the MDM console. Applications that implement the AppConfig standard receive these configuration values in a key-value dictionary format that the app reads at launch. All major EMM/UEM platforms support AppConfig, including BlackBerry UEM, Microsoft Intune, VMware Workspace ONE, and SOTI MobiControl. Application vendors publish their supported AppConfig keys in AppConfig-formatted XML schemas available from the AppConfig Community catalog.

Application wrapping modifies an app binary before distribution, injecting a management SDK layer that enforces policies without requiring changes to the original app code. The wrapping tool wraps the compiled IPA (iOS) or APK (Android) with a management shim. This was an important technique when app developers had not yet built MDM or MAM SDK integration into their apps. The disadvantage of wrapping is that it re-signs the app, potentially violating vendor support agreements, and the wrapping shim must be maintained across OS updates. AppConfig and MAM SDK integration are the preferred current approaches: AppConfig for configuration delivery, MAM SDK (such as the Microsoft Intune App SDK or BlackBerry Dynamics SDK) for enforcing data-at-rest encryption, copy-paste controls, and conditional access within the app. Most major enterprise applications now include Intune App Protection Policy support natively or via the Intune SDK, reducing the need for wrapping.

The BlackBerry Dynamics SDK (formerly Good Dynamics) is a mobile application management and security SDK that app developers integrate into iOS and Android applications. Applications built with the Dynamics SDK operate within a secure container managed by BlackBerry UEM — data stored by those apps is encrypted with keys controlled by the UEM policy, and the apps can only communicate with other Dynamics-enabled apps or through approved network channels enforced by the Dynamics container. Use cases include regulated-industry mobile applications where network isolation and data-at-rest encryption must be demonstrably enforced at the application layer. BlackBerry provides Dynamics-ready versions of standard enterprise applications (email, calendar, browser, document editor), and third-party ISVs build custom Dynamics-enabled apps for sectors including financial services, healthcare, and government. The SDK is distinct from Android Enterprise MAM and AppConfig — it operates outside of standard Android Enterprise management APIs through its own secure container.

Mixed-OS enterprise fleets are the operational norm. The management strategy centers on selecting a UEM platform with genuine parity for both iOS and Android policy depth — not one with strong iOS support and limited Android Enterprise configuration, or vice versa. BlackBerry UEM, Microsoft Intune, and VMware Workspace ONE all maintain documented policy parity lists for iOS and Android Enterprise. The critical comparison points are: enrollment mode support (ADE/supervised for iOS; fully managed, work profile, COPE for Android); configuration profile depth; app management capabilities (AppConfig, MAM SDK support); and compliance policy flexibility (conditional access based on device health attributes). Organizations with regulated-industry requirements should specifically verify that their platform supports the compliance policy attributes relevant to their regulatory framework — for example, verifying that the MDM can enforce minimum OS version requirements as a conditional access gate for both iOS and Android endpoints.