Mobile Device Security Guide: MDM, MAM, MTD and BYOD

Phones and tablets now hold the email, chat, MFA approvals and session tokens that unlock most corporate systems, yet they are often managed less rigorously than laptops. The tooling has matured: mobile device management (MDM), mobile application management (MAM), mobile threat defence (MTD), Android Enterprise work profiles and Apple User Enrolment can protect corporate data on both company-owned and personal devices. The difficulty is choosing the right model for each population, setting data protection to a level that users will tolerate, and connecting device health to access decisions. This guide covers ownership models, enrolment, app protection settings, compliance, mobile phishing and BYOD privacy, with phased rollout and measurement advice. It is for endpoint, identity and security teams responsible for iOS, iPadOS and Android fleets.

Key takeaways

• Pick the management model by ownership, not by habit. Company-owned devices should be enrolled automatically and supervised or fully managed; personal devices should get app-level protection or a work profile, not full device control.
• App protection policies protect data, MDM protects devices. MAM controls copy, paste, save, backup and wipe inside managed apps and works without enrolment, which makes it the default for BYOD.
• Compliance only matters when access depends on it. A jailbreak or outdated OS check does nothing until Conditional Access, or your identity provider's equivalent, requires a compliant device or protected app.
• Mobile phishing bypasses most device controls. Smishing, QR code phishing and push fatigue target the user, so pair MTD and link protection with phishing-resistant authentication.
• The MDM console is a privileged system. An administrator account that can wipe every device needs the same protection as a domain admin, including approval workflows for mass actions.

Ownership models and management approaches

What IT can control by ownership model

NIST SP 800-124 Rev. 2 treats organisation-provided and personally owned devices as different deployment scenarios with different risks, and NIST SP 1800-22 notes that BYOD "introduces new privacy risks to employees". The ownership model decides which management features are appropriate.

On a personally owned Android device, Google's documentation says users "retain privacy over their personal apps, data, and usage", while the organisation can lock and wipe the work profile, block screenshots in work apps and restrict Bluetooth, NFC and USB transfers from it. Apple's account-driven User Enrollment separates managed app containers, Keychain items, Mail, Notes, Calendar and Reminders using encryption keys created at enrolment and destroyed at unenrolment, and its MDM command list for User Enrollment includes lock but not erase.

MDM, MAM, MTD and UEM compared

MDM containerisation means keeping work apps and data in a separately managed, encrypted space: the Android work profile, Apple's managed apps and accounts under User Enrollment, or MAM-protected apps. It is what lets IT wipe corporate data without touching personal data. The NCSC BYOD guidance recommends a hybrid where it fits: combine MDM features that suit BYOD with MAM to balance device controls against user privacy, and restrict copying data between work and personal environments either way.

Enrolment that cannot be skipped

• Android zero-touch enrolment: devices bought from an authorised reseller are registered to your zero-touch account. On first boot the device checks for an assigned configuration and provisions as fully managed with your EMM's device policy controller. Devices without a configuration boot unmanaged, so assign a default configuration. Supported on Android 9.0 and later (some 8.0 devices and Pixels on 7.0).
• Apple Automated Device Enrollment: devices assigned through Apple Business or Apple School Manager are supervised automatically at enrolment (iOS 13 and iPadOS 13.1 or later). Supervision "generally denotes that the device is owned by the organization" and unlocks restrictions not available on personal devices. Supervising manually with Apple Configurator erases the device.
• BYOD enrolment: on iOS the user chooses Sign In to Work or School Account and authenticates with a Managed Apple Account federated to your identity provider. On Android the user adds a work profile; only the user can delete it from a personally owned device.
• Enrolment restrictions: block personally owned devices from full device enrolment, cap devices per user, and require MFA at enrolment so a stolen password cannot register an attacker's phone as a trusted device.

App protection policies in practice

App protection policies apply rules when a user opens or moves corporate data inside a managed app, with or without MDM. Microsoft's data protection framework for Intune gives three cumulative levels, and the same logic carries over to other platforms that offer app-level controls.

Level 2 is the reasonable default for most knowledge workers, and Level 3 for people handling high-risk data. MAM selective wipe removes corporate data from the app; the app checks for a wipe request at launch and every 30 minutes while in use. On Android the Company Portal must be installed to receive app protection policies even without enrolment.

Compliance and access decisions

• Compliance policy: require a minimum OS version, a device passcode, encryption, no jailbreak or root, and a maximum MTD threat level. NCSC adds checking for banned apps and using device attestation where available.
• Tenant settings: in Intune, Mark devices with no compliance policy assigned as defaults to Compliant; set it to Not compliant. The Compliance status validity period defaults to 30 days (range 1-120); devices that stop reporting become noncompliant after it.
• Actions for noncompliance: mark noncompliant immediately, notify the user, then remote lock or retire after a grace period you can defend to HR.
• Attestation: on Android, Play Integrity returns MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY; the strong verdict needs hardware-backed signals and a recent security patch. Intune's framework still labels its check "SafetyNet device attestation" and requires a hardware-backed key evaluation at Level 2.
• Conditional Access: require Require device to be marked as compliant for enrolled devices, or an approved app with app protection policy for BYOD, before granting email, files and SaaS. See the Zero Trust Identity Guide.

Mobile threat defence and mobile phishing

MTD apps assess device, network and application risk and report a level such as low, medium or high to the management platform, which compares it with the threshold in the compliance policy and can block access while the device is compromised. For unenrolled devices, the same signal can feed app protection policies to block access or selectively wipe corporate data. If two MTD vendors are configured for one platform, every device must run both apps or it is marked noncompliant.

MITRE ATT&CK for Mobile tracks phishing as T1660, covering smishing, quishing (QR codes that move a desktop email attack onto a phone, where desktop link scanning does not reach) and vishing. Phones are also where MFA prompts arrive, which makes them the target for push fatigue (ATT&CK T1621).

• Link protection: use MTD or secure browser features that inspect links in SMS, messaging and email apps; ATT&CK notes some products use a loopback VPN for this.
• Authentication: move high-risk users from SMS codes and simple push to number matching or, better, passkeys and FIDO2. The Twilio Breach 2022 started with SMS phishing of employees, and the Uber Breach 2022 used repeated push prompts. See the Passwordless and Passkeys Guide.
• Sideloading and profiles: on managed devices block installation from unknown sources and unapproved configuration profiles; on BYOD, rely on MTD to flag them.

BYOD policy and privacy

NCSC is explicit that the device belongs to the user while corporate data belongs to the organisation, and that full management of a personal device effectively turns it into a corporate one. A workable BYOD policy states:

• Eligibility: minimum OS versions, no jailbroken or rooted devices, and which roles may use BYOD at all. Users with privileged or high-risk data access may need a corporate device.
• What IT can and cannot see: publish the list of data collected (device model, OS, managed apps) and what is never collected (personal apps on iOS User Enrollment, personal profile content on Android). NCSC recommends communicating privacy boundaries in the MDM terms of use and training users before they join the BYOD allow-list.
• Wipe scope: selective wipe of corporate data or the work profile on loss, theft or leaving, never a full wipe of a personal device.
• Data protection law: collecting device data about employees is personal data processing, so data minimisation (GDPR Art. 5(1)(c)) and security of processing (Art. 32) apply. Involve your DPO before enabling location, app inventory or network monitoring.
• Unmanaged laptops and VDI: where BYOD extends to computers, NCSC recommends disabling clipboard and drive redirection, idle timeouts and blocking printing in the virtual desktop.

Where identity fits

• MDM admins can wipe the fleet: the Stryker Cyberattack 2026 showed one hijacked admin account using Intune to wipe tens of thousands of devices. Use phishing-resistant MFA, privileged access workstations and least-privilege roles for MDM admins, and enable Multi Admin Approval so wipe, retire, delete, scripts and role changes need a second administrator. Requests expire after three days, and Graph API calls by service principals are also intercepted. See the Privileged Access Management Guide.
• Automation identities: scripts and integrations that call the management API with app credentials are non-human identities with fleet-wide power. Scope their Graph permissions, store secrets in a vault and review them like any admin. See the Service Account Security Guide.
• Device certificates and tokens: MDM deploys certificates for Wi-Fi, VPN and authentication; tie their lifecycle to enrolment so retired devices lose them. Refresh tokens held by mobile apps should be revoked on selective wipe. See the Device and IoT Identity Guide.
• Secrets in apps: in-house apps must not ship API keys; the Mobile Apps Hard-Coded AWS Keys 2022 research found exactly that in Android and iOS apps.

Choosing and rolling out

Decision guidance

MAM only suits BYOD phones used for email, chat and documents: low friction, no device inventory, and selective wipe covers leavers. MDM with a work profile or User Enrollment is needed when personal devices require certificates, per-app VPN or line-of-business apps. Fully managed or supervised devices are right for privileged users, regulated data, frontline shared devices and anyone whose phone is their only endpoint. Small organisations can start with MAM plus Conditional Access and add MDM for company-owned phones later; large organisations usually run all three tiers and should keep the policy set small, with one baseline per ownership model rather than per department.

Phased rollout

1. Inventory: list who accesses corporate data from mobile devices, from sign-in logs, and classify them by ownership and data risk.
2. Protect the console first: lock down MDM admin roles, enable Multi Admin Approval for device actions, and require phishing-resistant MFA for admins.
3. Pilot app protection: assign Level 2 policies to a pilot group, and run Conditional Access in report-only mode to see who would be blocked.
4. Enrol company devices: configure zero-touch and Automated Device Enrollment so new devices arrive managed; re-enrol existing devices at refresh or by a deadline.
5. Turn on compliance: set no-policy devices to noncompliant, add jailbreak, OS, encryption and passcode checks, then require compliance for one app (usually email) before expanding.
6. Add MTD: start with reporting only, tune false positives, then set a threat level threshold in compliance and app protection policies.
7. Rollback: move Conditional Access policies back to report-only rather than deleting them, and exclude a named break-glass group from device requirements. Never roll back by disabling app protection, which leaves data unprotected on devices that already have it.

Detection and measurement

Feed MDM audit logs (policy changes, wipes, retires, role assignments), MTD alerts and sign-in logs with device state into the SIEM. Alert on bulk wipe or retire actions, new admin role assignments, enrolment from unusual locations, and devices that move from compliant to jailbroken or high threat. Useful metrics:

• Coverage: percentage of mobile sign-ins to corporate apps from a compliant device or a policy-protected app; target 100 percent for email and files.
• Patch latency: percentage of managed devices within one major OS version and within 30 days of the latest security patch.
• Noncompliance dwell time: median days a device stays noncompliant before remediation or retirement.
• MTD threat rate: high-severity detections per 1,000 devices per month, and time to block.
• Selective wipe on exit: percentage of leavers whose corporate app data was wiped within 24 hours.
• Privileged action approval: share of wipe, retire and script actions that went through a second approver.

Framework mapping

Common failure patterns

• Compliance without enforcement: jailbreak and OS checks report noncompliant devices, but no Conditional Access rule requires compliance, so those devices still sync mail.
• Default compliant: leaving Mark devices with no compliance policy assigned as on Compliant means any device outside a policy assignment passes.
• Full MDM forced on personal phones: users refuse, find workarounds such as forwarding mail to personal accounts, or the organisation collects data it cannot justify.
• Unprotected admin console: one compromised administrator can wipe the fleet because there is no second approver and no alert on bulk actions.
• Leavers keep data: accounts are disabled, but app data, cached files and tokens stay on personal devices because selective wipe is not part of offboarding. See the Joiner-Mover-Leaver Guide.
• Zero-touch with no default configuration: new devices boot unmanaged and are used for months before anyone notices.

Practitioner checklist

• Define one baseline per ownership model: fully managed, company-owned with work profile, BYOD with enrolment, BYOD MAM-only, dedicated.
• Enrol all new company devices through zero-touch or Automated Device Enrollment with a default configuration.
• Deploy app protection policies at Level 2 for everyone and Level 3 for high-risk roles.
• Set devices with no compliance policy to noncompliant and require compliant devices or protected apps in Conditional Access.
• Integrate MTD and use its threat level in compliance and app protection policies.
• Protect MDM admin roles with phishing-resistant MFA and Multi Admin Approval for wipe, retire and scripts.
• Publish a BYOD privacy notice stating what is and is not collected, reviewed by your DPO.
• Add selective wipe and token revocation to leaver and lost-device processes.
• Report monthly on coverage, patch latency, noncompliance dwell time and approved privileged actions.

Standards and references

• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• NIST: SP 1800-22, Mobile Device Security: Bring Your Own Device
• NCSC: BYOD guidance, put technical controls in place
• MITRE ATT&CK: Phishing (Mobile, T1660)
• Apple: Account-driven enrollment methods
• Google: Android Enterprise Work Profile and its features
• Microsoft Learn: Data protection framework using app protection policies
• Microsoft Learn: Mobile Threat Defense integration with Intune

Related NHI Mgmt Group resources: Device and IoT Identity Guide · Zero Trust Identity Guide · MFA Guide · Remote Access Identity Guide