Phones and tablets now hold corporate mail, SSO sessions, passkeys and authenticator apps, yet most organisations can tell you far less about a phone's security state than about a laptop's. Mobile threat defense (MTD) products put an agent or SDK on iOS and Android devices to detect risky apps, network interception, phishing and compromised operating systems, then feed a risk level to your device management and access policies. Offerings differ widely in what they can actually see on each platform, how they handle personally owned devices and how cleanly they integrate with MDM and conditional access. This vendor-neutral buyer's guide is for security, endpoint and identity teams who need to define requirements, compare products on evidence and run a proof of concept. For the wider programme (MDM, MAM and BYOD policy) see the Mobile Device Security Guide.
Key takeaways
- MTD is a signal source, not a control on its own. Its value comes from the risk level it hands to MDM compliance and conditional access, so test the integration as hard as the detection.
- The platforms limit what any product can see. iOS sandboxing and Android permission models restrict on-device inspection, so ask each vendor to show exactly which detections run on-device, which run in the cloud and which need a VPN or network profile.
- Phishing on mobile is the threat users meet most. SMS, messaging apps and QR codes bypass email filtering, and real-time relay kits defeat one-time codes, so link and network protection deserve as much weight as malware scanning.
- Personally owned devices change the design. Enrolment, privacy, what data the vendor collects and whether MTD works with app protection on unenrolled devices often decide the shortlist.
- Platform attestation now covers part of the job. Google Play Integrity verdicts and Apple managed device attestation give strong device-integrity signals; buy MTD for what it adds on top of them.
Define requirements
- Device population: corporate-owned (fully managed or supervised), corporate-owned with a work profile, BYOD with a work profile or user enrolment, and BYOD with app protection only. Each mode gives the MTD agent different visibility.
- Threat model: NIST SP 800-124 Rev. 2 describes MTD as detecting malicious apps, network attacks, phishing, improper configurations and known vulnerabilities in apps or the OS, grouped as device, application and network threats. Decide which matter most to you, for example executives travelling to high-risk regions, frontline staff on shared devices or developers with production access.
- Management stack: which MDM or UEM you run, whether you use app protection policies on unenrolled devices, and which identity provider enforces conditional access. See the UEM Buyer's Guide and the Conditional Access Guide.
- Response actions: what should happen at each risk level, from user notification to blocking access, selective wipe of corporate app data or full wipe of a corporate device.
- Privacy and works council constraints: what device and app inventory may be collected from personal phones, where data is processed and how long it is kept.
- Operations: who triages alerts, whether events must reach the SIEM or XDR platform, and the regulatory evidence you need. See the XDR Guide.
Capability areas
| Area | What to look for | Platform notes |
|---|---|---|
| Device and OS risk | Jailbreak and root detection, outdated OS and security patch level, known OS vulnerabilities, developer mode, unknown configuration or device management profiles, unauthorised root certificates | Compare with Play Integrity MEETS_STRONG_INTEGRITY (on Android 13 and later this requires security updates within the last year) and Apple managed device attestation (iOS 16, iPadOS 16.1, macOS 14 or later) |
| App risk | Malicious and sideloaded apps, risky permissions, apps talking to blocklisted services, apps that send data unencrypted, app reputation and vetting reports. See the Mobile Malware Guide | Android allows broader app inventory; on iOS, app inventory usually comes from the MDM for managed apps only |
| Network risk | Adversary-in-the-middle detection (rogue Wi-Fi, TLS interception, certificate tampering), unsafe Wi-Fi alerts, optional on-device VPN for traffic inspection | Network inspection usually depends on a local VPN or DNS profile; check battery impact and conflict with your corporate VPN |
| Phishing and content protection | Link protection in SMS, messaging apps, browsers and email, QR code checking, blocking of malicious domains, real-time categorisation | What each platform lets a third-party app inspect in messages differs; ask what is inspected, on which platform and where |
| Integration and response | Risk level (for example low, medium, high) fed to MDM compliance and conditional access; app protection integration for unenrolled devices; automated remediation playbooks | Check behaviour when the MTD service is unreachable; Intune, for example, has a "Number of days until partner is unresponsive" setting after which partner compliance is ignored |
| Visibility and hunting | Device inventory, OS and patch reporting, raw event export, API, SIEM and XDR connectors, mapping of detections to MITRE ATT&CK for Mobile | Ask for sample events, not dashboards |
| App shielding (SDK) | In-app SDK for your own customer-facing apps: runtime integrity, hooking and tamper detection, overlay detection | Separate requirement from workforce MTD; compare against the OWASP MASVS resilience controls. See the Mobile App Security Guide |
Evaluation criteria
| Criterion | How to test it | Weight guidance |
|---|---|---|
| Detection coverage by platform | Vendor-supplied matrix of each detection, per OS, per enrolment mode, with the mechanism (on-device, cloud, VPN) | High |
| Threat coverage mapped to ATT&CK for Mobile | Ask which techniques they detect, for example Phishing (T1660), Adversary-in-the-Middle (T1638), Exploitation for Privilege Escalation (T1404), Download New Code at Runtime (T1407) and Supply Chain Compromise (T1474) | Medium |
| Integration fidelity | Time from threat to non-compliant state and blocked sign-in; behaviour of remediation and return to compliance | High |
| BYOD and privacy | Data collected per enrolment mode, published data processing terms, user-facing privacy explanation | High where BYOD is common |
| User impact | Battery and data use, onboarding steps, prompts, false positives over two weeks | Medium |
| Operations | Alert quality, triage workflow, event export latency, API completeness, role-based admin access | Medium |
| Vendor security | Independent assessments, admin console MFA and SSO, support access controls, handling of collected device data | Medium |
| Cost and licensing | Per-user or per-device pricing, shared device handling, whether phishing protection or vulnerability reporting is an extra tier | Context |
Small organisations with one MDM and mostly corporate devices often get enough from the MDM's built-in compliance checks plus platform attestation, and should buy MTD mainly for phishing and network protection. Large or regulated organisations with BYOD, high-risk travellers or customer-facing apps usually need the full capability set and an event feed into the SOC.
Questions to ask vendors
- For each detection you list, which iOS and Android enrolment modes support it, and does it run on the device, in your cloud or through a VPN profile?
- How does your risk level reach our MDM and identity provider, how fast, and what happens to compliance if your service or the agent stops reporting?
- How do you detect phishing delivered by SMS, messaging apps and QR codes, and how do you handle real-time relay pages that capture one-time codes?
- What exactly do you collect from a personally owned device, where is it processed and for how long is it kept? Can we see the data model?
- How do you detect malicious device management or configuration profiles and unauthorised root certificates, which NIST SP 800-124 Rev. 2 lists among the threats MTD mitigates?
- Can we export raw events with device identifiers to our SIEM, and which ATT&CK for Mobile techniques are mapped in those events?
- How quickly do you add detections for newly disclosed mobile OS vulnerabilities, and how do you report devices that cannot be patched?
- How is your admin console protected (SSO, phishing-resistant MFA, role separation), and who on your side can access our tenant data?
Red flags
- A detection list that does not distinguish iOS from Android, or managed from unenrolled devices.
- Claims of full on-device malware scanning on iOS without explaining how the platform allows it.
- Integration demonstrated only as a dashboard, with no working compliance or conditional access enforcement.
- No clear answer on what is collected from personal devices, or collection of personal app inventories by default on BYOD.
- Network protection that requires routing all traffic through the vendor with no option to exclude personal traffic.
- No raw event export, or exports without timestamps and device identifiers that a SOC can correlate.
- Phishing protection limited to email links, missing the SMS and messaging channel. The Twilio breach began with text messages to employees' phones that bypassed email filtering.
Proof of concept
- Pick 30 to 50 pilot users across iOS and Android and every enrolment mode you use, including at least one BYOD group with app protection only.
- Deploy through your MDM with the risk-level integration in report-only mode first: record risk, but do not mark devices non-compliant.
- Run controlled tests: a test device with developer mode or an outdated OS, a sideloaded test app on Android, a test configuration profile and root certificate, a simulated rogue Wi-Fi with TLS interception, and phishing links sent by SMS, messaging app and QR code using a safe test domain.
- Measure time from each test event to detection, to non-compliant state and to blocked sign-in once enforcement is switched on for a small group.
- Track battery and data impact, user prompts, help desk tickets and false positives over at least two weeks.
- Export events to the SIEM and confirm an analyst can triage a detection without the vendor console.
- Review the privacy data model with your data protection officer and, where relevant, works council before scaling.
- Document the rollback: how to remove the agent and VPN profile, and how compliance policies revert if the MTD connector is disabled.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across endpoint, identity and NHI security, including how device risk feeds conditional access. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Mobile Device Security Guide · OWASP Mobile Top 10 Guide · Device Trust and Posture Guide · Vishing and Smishing Guide · EDR and XDR Buyer's Guide