Most people know to be suspicious of an unexpected text claiming to be from their bank. This campaign works because the message comes from someone the victim already knows and trusts.

How the scam works

The message arrives from a contact’s WhatsApp account, which has most likely already been compromised by the same scam. It includes a link and asks the recipient to vote for a child taking part in a contest.

The site asks the victim to pick a contestant, then to enter their phone number and the code they receive.

That code links the victim’s WhatsApp account to a device the attackers control.

The site also offers a QR code to scan, which links the account in the same way.

Once linked, the attackers can read the victim’s new messages and send messages in their name, including the same voting link to everyone in their contacts. The victim’s phone carries on working as normal, so most people have no idea their account has been taken over.

The phishing pages are also built to stay out of sight. Each one loads only when visited through its full URL, and visiting the bare domain returns a 403 Forbidden error, which makes the sites harder for automated scanners to find.

Why this matters for organisations

Many employees use WhatsApp to talk to colleagues, clients, and suppliers, whether on a company phone or their own. A hijacked account gives attackers a view into those conversations and lets them message people as a trusted member of staff. Because the lure arrives through a messaging app, email security tools never see it, and mobile device management doesn’t close the gap either, because MDM and mobile threat defence do different jobs.

Indicators of compromise

We identified the following domains through our own detections and reverse IP lookups. They have been defanged so they can’t be clicked, and most are now offline.

• ballethfibs[.]cc
• czechballetschool[.]site
• awardancing[.]cc
• awardancing[.]ws
• awardancing[.]com
• awardancing[.]sbs
• awardancing[.]cfd
• besttack[.]top
• jordan-skill[.]com
• skill-bright[.]cyou
• sup-steel[.]click
• wiki-drell[.]online

Almost every phishing URL we saw used one of these two paths:

• /p/29/#
• /l/vote2026m11

The domains resolved to two IP addresses, hosted in Czechia and France:

• 95.182.87[.]131
• 138.124.92[.]4

The hosting location shows where the servers are rather than where the attackers are. However, the website’s source code contains extensive comments written in Russian, which suggests it was built by Russian speakers. The code also makes repeated references to Telegram, suggesting the template may have been reused from an earlier scam targeting Telegram users. The site shows signs of being built with AI tools, including AI-generated images. A template that has already been adapted from one messaging app to another could easily be adapted for other countries and languages, so we expect this campaign may spread.

How Corrata detected the campaign

Corrata’s zero-day phishing protection (ZDP) assesses domains it has not seen before and quarantines them if they are judged risky. None of the domains in this campaign had been seen before, so ZDP assessed them, judged them risky, and blocked access, whether the link arrived by WhatsApp, SMS, or any other app. This stopped users before they ever reached the page asking for their phone number, so customers were protected before the scam had a name.

How to keep yourself safe

1. Never enter a code into a website: WhatsApp verification and pairing codes are only ever needed inside the WhatsApp app. If a website asks you to enter your phone number and then a code you’ve just received, close it, because that is how attackers link your account to their device.
2. Check your linked devices: Open WhatsApp settings, go to Linked devices, and review everything listed there. If you see a device you don’t recognise, log it out straight away.
3. Turn on two-step verification: This adds a PIN that’s needed whenever your number is registered on WhatsApp, which makes it much harder for someone to take over your account.
4. Confirm unusual requests with the sender: If a friend sends you a link asking you to vote, donate, or log in, call them or message them on a different app to check they really sent it. Their account may have been compromised.
5. Treat links on every platform with caution: Phishing now arrives through WhatsApp, Telegram, social media, and QR codes as well as SMS and email, often from people you trust.

For organisations

Staff can’t be expected to spot a convincing link from a friend every time, so protection needs to work at the device level through mobile threat defence. Corrata’s zero-day phishing protection blocks links like the ones in this campaign whichever app they arrive through, even when the domain is brand new.

To see how it works, request a demo.

The post The WhatsApp “vote for my friend’s child” scam that takes over your account appeared first on Corrata.

This page separates those product types into layers, covering products built for phones and tablets running iOS and Android rather than for laptops. For each it sets out what the software does, where its protection ends, and who sells it. Nothing here is ranked, because the right choice depends on what you already own.

Corrata publishes this guide and sells in two of the layers below. Vendors are included if they sell to organisations and have a documented offering for iOS or Android. Application shielding products such as Appdome and Guardsquare are out of scope, because they protect apps your organisation publishes rather than the phones your staff use.

What counts as mobile security software

The useful boundary is the operating system rather than portability.

Mobile security software protects phones and tablets running iOS and Android, along with the company data they reach. A laptop is portable too, but it is a different engineering problem, because a desktop operating system has long let security software install at a privileged level and observe the whole machine. A phone has never allowed that.

A vendor describing one agent across laptops, phones, and tablets is describing two engineering approaches under one brand, and the mobile half deserves separate evaluation.

A secure access client running on a phone is also not the same category as a product that detects threats on one, and treating them as interchangeable is how gaps get missed.

Why mobile security software is built differently

Desktop security consolidated over about two decades. Antivirus, host firewall, device control, and behavioural detection all merged into endpoint protection platforms, and those in turn became endpoint detection and response.

Mobile never went the same way, for reasons that come down to how the two operating systems are built.

The sandbox denies the view that desktop agents rely on: iOS and Android isolate applications from one another, so one cannot read another’s files or watch what the user does inside it. The level of system access that desktop agents have relied on has never existed on a phone. Desktop platforms are moving the same way, with Apple replacing kernel extensions with user-space system extensions and Microsoft building a platform for antivirus and endpoint detection to run outside the Windows kernel.

Products are built on sanctioned interfaces instead: What a mobile security product can see is set by the APIs each platform chooses to expose. Network extensions allow traffic to be inspected, management frameworks report configuration state and application inventory, and attestation services report whether an application or device meets the platform’s integrity criteria. Neither platform returns a jailbreak or root flag directly, so products infer that condition from other signals, and every vendor is working through the same set of interfaces.

The two platforms expose different things: Android allows an application to enumerate other installed applications and read their permissions, though since Android 11 it must declare which ones it needs to see or hold a permission that Google approves on Play. iOS allows none of it, so a product claiming identical capability on both platforms is worth questioning.

Mobile security fragmented into layers rather than consolidating into a single agent, because no one interface exposes all of it. Working out which layer a product occupies is most of the buying decision.

What the threats actually are

• Phishing outside email: Mobile phishing arrives through SMS (smishing), RCS, WhatsApp, Signal, Telegram, and LinkedIn, none of which an email gateway sees. A truncated address bar shows only a fraction of a URL, and there is no hover preview to check it against. 
• QR code phishing: A code scanned with the native camera takes the user into a browser with a single tap and no security inspection in between, as our blog on QR code phishing sets out.
• Applications: Sideloading on Android, enterprise certificate abuse on iOS, and the alternative app marketplaces that the Digital Markets Act opened up on iOS in the EU all put software on a device without full store review. The more common problem is a legitimate store application requesting far more permission than its function requires.
• Networks: Phones join networks constantly and silently, and an attacker operating a network the device trusts can intercept any traffic that is not independently protected.
• Unpatched and unsupported devices: A phone on an operating system version that no longer receives security updates stays fully functional and fully exposed, and such devices accumulate quietly in any fleet that includes personally owned phones.
• Commercial spyware: Products sold to government customers and used against journalists, lawyers, and executives have repeatedly reached devices through zero-click delivery, as our history of iOS spyware documents.
• Data leaving through AI applications: Consumer AI services are installed on employee phones in volume, and company documents and client information are routinely pasted into them, making AI governance a necessity.

Built-in mobile protection on iOS and Android

Mobile platforms are more secure by default than a general-purpose desktop operating system, so the right starting point is a frank account of what you already have.

What the platforms cover

Application sandboxing, store review, and code signing are built in. Apple delivers OS security updates directly to every supported device. On Android, the full patch level depends on the handset maker, so two phones bought on the same day can sit months apart.

Apple offers Lockdown Mode for people at elevated risk of targeted attack, and Advanced Data Protection for end-to-end encrypted iCloud storage, though Advanced Data Protection has been unavailable to UK users since February 2025, when Apple withdrew it following a Home Office notice under the Investigatory Powers Act. 

Google Play Protect scans Android applications, and work profiles separate company from personal data on one device.

Where it stops

Store review does not catch everything, and it does not apply to apps installed from outside the store. Android devices left on an old patch level are exposed to vulnerabilities fixed upstream months earlier. 

Work profiles separate data without inspecting anything, so nothing stops a phishing link opened in the personal half of the device.

One limit applies to all of them, and it is the decisive one. None of these controls tells your security team anything. There is no alert, no console, and no record of what happened. Everything below exists to close that gap.

The layers, and who sells each

Each layer names the vendors that sell into it.

Device management: MDM and UEM

Management platforms enrol devices, apply configuration, distribute applications, enforce policy, separate company from personal data, and wipe company data remotely. Unified endpoint management extends the same model to laptops.

This is the foundation layer, and it is usually already in place. It is also the deployment path for much of what follows, because threat products are commonly distributed through it.

Management ends at administration. It verifies that a device is in a known good state, and it does not observe what happens on a device that is already in one.

Products in this layer include Microsoft Intune, Omnissa Workspace ONE UEM, Jamf Pro, Ivanti Neurons for MDM, SOTI MobiControl, IBM MaaS360, Scalefusion UEM, and Hexnode UEM. 

The line between management and detection is the one buyers most often misread, and our comparison of MDM and MTD covers where each of them stops.

Mobile threat defence

Mobile threat defence products detect threats that device management cannot see, including on phones that are fully compliant and up to date, and they work at the device, application, and network levels.

Device-level detection covers the state of the operating system, including jailbreak and root detection, weak configurations, and unsupported releases. Application-level detection goes deeper on Android, where packages and permissions can be inspected, than on iOS, where visibility into other applications is limited to what a management platform reports. Network-level detection is where phishing is caught, because a malicious link resolves to a destination that can be blocked before the page loads. 

A management platform tells you a phone is patched and configured to policy. It does not tell you the person holding it has just entered their credentials on a page registered an hour earlier. The device stays compliant throughout.

Corrata, Check Point, CrowdStrike, Ivanti, Jamf, Lookout, Microsoft, Pradeo, SentinelOne, and Zimperium all sell in this layer, each covered in more detail in our guide to mobile threat defense software.

Mobile data loss prevention and AI governance

This layer governs where company data goes once it is on a phone. The destinations that matter are consumer AI services, unsanctioned cloud storage, personal accounts in otherwise sanctioned applications, and the advertising and analytics infrastructure embedded in applications installed for other reasons.

Detection and data control are different problems. One asks whether something harmful is reaching the device; the other asks where information is leaving it. An employee pasting a client contract into a consumer AI service has not been attacked, and the data has still left the organisation.

The mobile version of this problem is harder, because the traffic does not traverse a corporate network and the applications are often on devices the organisation does not manage.

Two kinds of product address this, and they are not interchangeable. Mobile-native tools apply controls on the phone itself, and Corrata, for example, discovers and classifies AI applications across a fleet and blocks uploads to unapproved services. 

Security service edge platforms such as Netskope and Zscaler apply comparable controls across a whole estate, which suits an organisation already running one rather than one solving a mobile problem.

DNS and web filtering

Filtering products block known-bad or policy-prohibited destinations, either by refusing to resolve a domain or by blocking the connection at a gateway. They are inexpensive and effective against threats that rely on reaching a known destination.

DNS filtering works on domain lookups, so a connection made directly to an IP address bypasses it, as does a lookup sent to an encrypted resolver that the filter does not control. It also works from lists, so it is weak against a domain registered an hour ago.

Cisco Umbrella, Cloudflare Gateway within Cloudflare One, and DNSFilter sell here, and filtering is bundled into several management platforms. On phones, each works through the vendor’s own client, so check which platforms that client supports.

Choosing by situation

The criteria below matter most when a particular problem is driving the purchase.

When phishing arrives by text, chat, and QR code

• Channel coverage: Establish which channels the product can see. A product that inspects only browser traffic will miss links opened inside a messaging app’s own in-app browser, so ask about each channel individually.
• Inspection method: A product filtering on domain lookups misses a connection made directly to an IP address.
• Where analysis runs and how fresh it is: Phishing infrastructure is short-lived, so ask what the product does with a destination it has never seen, and whether assessment happens on the device or in the vendor’s cloud.
• What happens after detection: Products vary between alerting the administrator, warning the user, and blocking the connection outright. Only the last of those prevents credential entry.

Two things remain out of reach of any product here. Voice social engineering that carries no link puts nothing in the traffic to inspect, and a QR code scanned with the native camera on an unprotected phone takes the user wherever it points.

When the fleet is BYOD or unmanaged

• The population is larger than it looks: Beyond personally owned devices, this group includes contractors, board members, seasonal staff, suppliers with system access, and employees who were offered enrolment and declined it. None of them appear in the enrolled device count.
• Deployment without management: Ask whether the product deploys to a device that is not enrolled. Apple restricts system-wide content filtering on iOS to supervised devices, and the per-app alternative needs the targeted apps installed through a management platform, so any product covering an unenrolled iPhone is reaching it another way.
• What is collected: Establish what telemetry leaves the phone and what an administrator sees in the console, asking both separately.
• Where data is processed and stored: Ask where processing happens, where data rests, and whether that is contractual or current practice. 
• How much it interrupts the user: Software that prompts, warns, or slows the device gets uninstalled or worked around, whatever the detection is like. Ask what the employee experiences when nothing is wrong. 

When you are building zero trust

• Identity provider integration: Posture only matters if it reaches the access decision, so establish which identity providers are supported and what the integration passes.
• Continuous against point-in-time: A check at enrolment and one at sign-in both leave a session running on a device whose state may have changed. Ask how often posture is re-evaluated.
• Coverage of unenrolled devices: An architecture that only evaluates enrolled devices has left out the devices that most need evaluating. Corrata Identity Gate allows access from personal devices only where Corrata is installed and the device has a good security score.
• Revocation: Establish what happens when a device fails, and whether existing sessions are terminated or only new ones refused.
• Output to the rest of the stack: Check what the product sends to your SIEM or XDR platform. Corrata integrates with SIEM platforms.

Conclusion

Mobile security software is a set of layers, each solving a different problem, and vendors describe them in language similar enough to make them look interchangeable.

Work out which question you need answered, identify the layer that answers it, and establish what your existing licensing already covers before buying anything, because several management platforms bundle filtering and several security suites include a mobile tier that may already be paid for but not yet deployed.

If mobile phishing and data loss on employee devices are your problems, you can request a demo to see how Corrata handles both.

The post How Mobile Security Software Works, Layer by Layer appeared first on Corrata.

Employees are also more likely to fall for the mobile version. Verizon’s 2026 Data Breach Investigations Report found that phishing simulations delivered by phone, through SMS and voice, had a median click rate around 40% higher than email simulations.

This guide is for security leaders and architects responsible for employee mobile device security. It explains what mobile threat detection is, why existing controls miss mobile threats, and how on-device detection finds phishing and malware, including on personal phones.

What is mobile threat detection for employee phones?

Mobile threat detection for employee phones is the continuous monitoring of the smartphones and tablets staff use for work. It identifies phishing, malware, network attacks, and risky configurations, then blocks or contains them before they reach corporate data. It is the detection layer of mobile threat defence, a category often searched for under the US spelling “mobile threat defense”.

Mobile threat detection works alongside mobile device management (MDM), but serves a different purpose from other mobile security software. MDM controls how a device is configured, while mobile threat detection assesses whether the activity on it is safe. Phones also face conditions laptops rarely do. Most phishing arrives outside email, devices move between networks all day, and many are personal phones the organisation does not fully control.

Where existing controls leave gaps in mobile threat detection

Most enterprise security stacks were designed around email, laptops, and the corporate network, and each layer has a blind spot on mobile.

Email security only sees email. On mobile, attackers favour channels that never touch the mail server, and mobile phishing increasingly arrives through SMS, WhatsApp, QR codes, and social media. An SMS is delivered by the mobile operator, so it reaches the phone without passing any control your organisation owns.

MDM manages the device rather than defending it. It enforces passcodes, pushes apps, and reports the operating system version, but it cannot judge whether a link is malicious or whether an app is beaconing to a command-and-control server.

Network controls only see the traffic routed to them. A secure web gateway or corporate VPN can inspect connections while the phone is tunnelled through it, but phones spend much of the day on cellular data and public Wi-Fi, and many personal devices are never tunnelled at all.

What mobile threat detection needs to see

Effective detection combines signals from the network and the device. The useful ones fall into five groups:

• Destinations: the domains, server names, IP addresses, and ports a device connects to, checked against mobile-focused threat intelligence.
• Apps: the installed app inventory, app hashes, and permissions, with particular attention to sensitive permissions such as accessibility.
• Traffic behaviour: background connections the user never sees, which are often the clearest sign of malware.
• Connection integrity: TLS certificate metadata that reveals interception on a hostile Wi-Fi or cellular network.
• Device posture: the operating system version, patch level, and configuration weaknesses that make an attack more likely to succeed.

No single signal is enough. A suspicious domain matters more when a new app with accessibility rights contacts it.

The limits of routing mobile traffic through a gateway

One common way to gain mobile visibility is to send device traffic through a cloud gateway or always-on VPN and inspect it centrally. This can work, but it carries three trade-offs.

Coverage depends on the tunnel staying up, so detection stops whenever the profile disconnects or is switched off. The gateway also lacks device context. It cannot see the installed apps, their permissions, or the device configuration that turn a suspicious connection into a confirmed threat. On personal phones, routing every connection through company infrastructure means the organisation handles employees’ personal browsing. That is hard to justify under GDPR, and it tends to undermine BYOD adoption.

How on-device mobile threat detection works

On-device detection moves the inspection to the phone. A security app inspects connection attempts locally, checks them against threat intelligence, and blocks malicious destinations before the connection completes, without sending traffic to a remote gateway. Because the app runs on the device, it can also correlate network activity with the installed apps, their permissions, and the device posture.

This approach works wherever the device goes. It also suits personal phones, because only security findings reach the console.

How mobile threat detection finds phishing on phones

Mobile threat detection finds phishing on phones by checking the destination of every connection against threat intelligence. A malicious page is blocked at the moment of the click, whichever app delivered the link. This matters because the lure often arrives through a channel no security tool can scan, such as an SMS.

Effective mobile phishing detection combines five techniques:

1. It inspects every connection, regardless of the app: A link opened from SMS, WhatsApp, Teams, LinkedIn, or a QR code becomes a connection request, so checking the destination covers every delivery channel at once.
2. It uses threat intelligence built for mobile campaigns: Smishing domains are often registered, used, and abandoned within hours, and feeds tuned for email tend to miss them.
3. It blocks the infrastructure as well as the URL: Phishing kits reuse hosting, so blocking the IP ranges behind known kits catches new pages before they appear on any blocklist.
4. It treats high-risk hosting platforms with caution: Some free website builders host a disproportionate share of phishing pages, so restricting them on work devices removes significant risk.
5. It feeds blocked attempts into the incident process: A blocked click shows who is being targeted and through which channel, which helps you spot a campaign aimed at a particular team.

How to detect mobile malware on employee phones

Mobile malware detection uses two methods. The first checks installed apps against known malware and flags apps that request dangerous permissions. The second watches network behaviour. Even sophisticated spyware must talk to its operators, and that traffic can be detected and blocked.

The network method matters most on iOS, where sandboxing stops security apps from scanning other apps’ files. Blocking command-and-control traffic also stops malware sending data out while the device is cleaned up. Our guide to improving mobile malware detection on work phones covers these methods in depth, and our history of iOS spyware from Pegasus to DarkSword shows how advanced threats have evolved.

What is mobile threat detection for BYOD in 2026?

Mobile threat detection for BYOD runs on employees’ personal phones to find phishing, malware, and network attacks while keeping personal data, messages, and browsing private. In 2026 it has become a core part of employee mobile device security, because personal phones now hold the authenticator apps, email, and SaaS sessions that attackers target.

Three shifts make BYOD detection more pressing this year:

1. AI tools let attackers write fluent, personalised smishing messages at scale, and Verizon’s 2026 Data Breach Investigations Report documents threat actors using AI across the attack lifecycle, from reconnaissance through to initial access.
2. Apple’s User Enrollment and Android’s work profile separate work data from personal data and restrict what IT can see. Threat detection must work without full control of the device.
3. A phishing page that captures a password or MFA code on a personal phone can lead straight into corporate systems, even when the link arrived in a personal chat.

Good BYOD detection meets five tests:

1. It runs locally and sends only security findings to the console.
2. It does not need to read messages or collect browsing history.
3. It protects every app, since a phishing link in a personal WhatsApp chat can still harvest work credentials.
4. It ties access to device health, so a compromised phone, or one with its protection removed, loses access to corporate resources.
5. It is transparent with employees about what it collects and why.

Turning detection into response

Detection is only useful if it triggers a fast response. Your employee mobile device security process should define three things in advance:

• Automatic containment: blocking malicious connections immediately and quarantining a compromised device so it cannot reach corporate data during investigation.
• Access decisions: ensuring only devices known to be secure can reach email, SaaS apps, and internal systems.
• User guidance: alerting the employee in plain language and guiding them through removing a malicious app or updating the operating system.

What to look for in a mobile threat detection solution

When you evaluate enterprise mobile security tools, these questions separate strong detection from basic coverage:

• Does detection keep working on cellular and public Wi-Fi without depending on a tunnel?
• Does it cover phishing that arrives through SMS, messaging apps, and QR codes, as well as email?
• Can it detect malware on iOS as well as Android, given iOS sandboxing?
• Can it block command-and-control traffic by domain, IP address, and port?
• What data leaves the device, and can you explain that to employees using personal phones?
• How has its phishing detection rate been tested, and against which attacks?

For a wider view of the vendors in this space, see our overview of the mobile threat defence software market.

How Corrata protects employee mobile devices

Corrata was built around patented on-device traffic inspection. It observes thousands of data points on each device every day, including device configurations, app hashes, app permissions, domain and server names, IP addresses, port numbers, and SSL certificate metadata. All traffic is processed on the device rather than through an external gateway, so protection follows the phone wherever it connects.

For mobile phishing, Corrata blocks suspicious links using threat intelligence specialised for mobile. This covers SMS, WhatsApp, QR codes, LinkedIn, and other channels. It also blocks the IP ranges used by phishing toolkits and website builder platforms with a high incidence of phishing. If an employee scans a QR code that leads to a phishing page, Corrata blocks the destination.

For mobile malware, Corrata blocks malware download sites, scans installed apps, and monitors apps that use dangerous permissions. By blocking command-and-control traffic across malicious domains, IP addresses, and ports, it disables malware on the device. Automatic quarantining limits the damage while users are guided through removal.

Because processing happens on the device, Corrata does not read the content of messages, and only security-critical information is sent to the cloud. That makes it practical to protect personal phones as well as corporate ones.

To see on-device mobile threat detection working on your own fleet, request a demo of Corrata.

The post How to Detect Threats on Employee Mobile Phones appeared first on Corrata.

This guide explains what each tool does, where MDM stops, how the two work together, and how to decide what your fleet needs.

What is the difference between MDM and MTD?

The two tools look at different things. MDM looks at the state of the device and whether it is configured the way policy says it should be. MTD looks at what is happening on and around the device and whether it is under attack.

What MDM does

MDM is the tool IT uses to enrol, configure, and control a fleet of devices. Most MDM products have grown into unified endpoint management (UEM) platforms, such as Microsoft Intune and Omnissa Workspace ONE, which manage phones alongside laptops.

Typical MDM tasks include enforcing a passcode and encryption, setting a minimum OS version, deploying and updating apps, pushing Wi-Fi, VPN, and email settings, separating work and personal data, and locking or wiping a device that is lost or belongs to someone who has left. On personal devices, that wipe is usually a selective wipe that removes only company data.

MDM can also check a few security-related settings, including OS version, passcode status, and, in most products, whether a device has been jailbroken or rooted. Those checks describe how the device is configured. They do not inspect the links a user opens, the networks the phone joins, or what installed apps are doing.

What MTD does

MTD is mobile security software, offered by the around ten vendors in our guide to mobile threat defence software, that runs as an app on the device and looks for threats in the device itself, its apps, its network connections, and the links and websites the user opens.

It detects phishing sent by SMS, messaging apps, email, and QR codes, malicious or over-permissioned apps, rogue Wi-Fi and man-in-the-middle attacks, and signs of compromise such as spyware. When it finds a threat, it can block it on the device, warn the user, and report a risk level that other systems act on.

Comparing MDM and MTD

Is MDM enough to secure company phones?

For most organisations it falls short, because MDM was built to manage devices and has no view of the attacks that most often reach phones.

Take a phone that passes every MDM check, with a passcode, a current OS, and only approved apps. Its user can still tap a phishing link in a WhatsApp message, enter their Microsoft 365 password on a fake login page, or join a hotel Wi-Fi network that is intercepting traffic. MDM reports the phone as compliant throughout, because none of those events changes how the device is configured.

There are two further gaps. MDM covers only enrolled devices, so personal phones used for email and Teams, and contractors’ devices, often sit outside it entirely. MDM also evaluates compliance when a device checks in, so it has no way to react the moment an attack starts.

MDM remains essential for the job it does. Detection is the part it leaves uncovered, and that is the job MTD is built for.

What MDM misses without mobile threat defence

MDM can confirm that a device is configured correctly, but most of the threats that reach phones never touch that configuration. Without MTD, four kinds of attack go unseen.

• Phishing outside email: Links sent by SMS, messaging apps, collaboration tools, and QR codes bypass the email filters most organisations rely on, and MDM has no view of the links a user opens.
• Malicious and over-permissioned apps: MDM can deploy approved apps and restrict others, but it does not analyse what an installed app is doing, so mobile malware hidden inside a legitimate-looking app goes unnoticed.
• Network attacks: A phone that joins a rogue hotspot or a network that is intercepting traffic still shows as compliant, because MDM does not inspect the device’s connections.
• Compromise and spyware: MDM checks whether a device is jailbroken or rooted, but advanced spyware usually runs without leaving those signs, and connections to attacker infrastructure are invisible to it.

MTD covers each of these on the device and turns what it finds into a risk level, which is where the two tools start to work together.

Do I need MTD if I already have MDM?

If your phones and tablets can reach company email, files, or SaaS apps, you almost certainly do. MDM keeps the device set up correctly, and MTD covers the threats that a correctly set-up device can still meet.

The two also make each other more useful. MDM can deploy the MTD app silently to enrolled devices, so users do not have to install anything. MTD in turn gives MDM and your identity provider a risk signal that configuration checks could never produce, so a phone that has just connected to a malicious network can lose access before any compliance check would have noticed.

Some organisations already have an MTD option through an existing vendor. Microsoft 365 E3 and E5 include Microsoft Defender for Endpoint, which has apps for Android and iOS, and our comparison of Corrata and Microsoft Defender for Endpoint on mobile covers how that option works. Whichever product you look at, test whether it detects threats across messaging apps as well as the browser, and whether it covers the personal devices your MDM does not reach.

How MDM and MTD work together

On a managed device, the two tools form a loop. The MDM enrols the device, applies policy, and deploys the MTD app. The MTD app then monitors the device, its apps, and its connections, blocks what it can immediately, and calculates a risk level.

That risk level feeds compliance and conditional access, so a device with an active threat loses access to company apps. Once the user fixes the problem, for example by removing a malicious app or updating the OS, the risk level drops and access returns without IT having to step in.

For a wider view that also covers mobile EDR and SIEM integration, see our guide to mobile endpoint security.

MDM and MTD on personal devices

Personal phones are where the difference between the two tools matters most. Employees are often reluctant to enrol their own phone in MDM, since full enrolment gives the employer control over a device they paid for, and many organisations do not ask them to. Those phones still read company email and join Teams calls.

MTD can protect a personal device without MDM enrolment. The app is installed from an email or SMS invite, protects against phishing, malicious apps, and network attacks, and can report the device’s risk into access decisions. Before rolling out any MTD product to personal devices, check what it collects; Corrata sets this out in its product privacy statement.

How to decide what your fleet needs

If you manage corporate-owned phones through Intune or Workspace ONE, keep the MDM and add MTD, then connect MTD’s risk level to compliance and conditional access so that a detection changes what a device can reach.

If staff also use personal phones for work, run MTD on those devices through invite-based installation, and base access to company apps on device risk instead of enrolment status.

If you run a smaller fleet without MDM, MTD on its own covers the threats, although you will still lack central configuration, app deployment, and remote wipe. Corrata Essentials is built for fleets of up to 250 devices.

How Corrata works alongside your MDM

Corrata provides mobile threat defence for iOS and Android, protecting corporate-owned and personal devices in the same platform. It integrates with the leading MDM platforms, including Microsoft Intune and Workspace ONE, for zero-touch deployment, and personal devices activate from an email or SMS invite.

It also works with identity providers including Microsoft, Google, and Okta, and with EDR and XDR tools such as Microsoft Defender for Endpoint.

Detection runs on the device. Corrata blocks phishing links across SMS, messaging apps, email, and browsers, detects rogue Wi-Fi and adversary-in-the-middle attacks, blocks connections to command-and-control infrastructure, and flags dangerous apps, jailbroken or rooted devices, outdated operating systems, risky configurations, and spyware.

When it finds indicators of compromise, the device can be blocked from enterprise apps until the issue is fixed, and the user gets guided steps to resolve it.

To see how Corrata would sit alongside your current MDM, you can request a demo with our team.

The post MDM vs MTD: what each one does for company phones appeared first on Corrata.

It usually spans three layers:

1. Mobile endpoint management controls how devices are configured.
2. Mobile threat defence detects and blocks attacks.
3. Mobile endpoint detection and response brings the visibility and response options security teams rely on for laptops and servers to phones.

Most organisations have the first layer in place and assume it covers the other two. This guide explains what each layer does, where the gaps usually sit, and what to ask vendors when you close them.

What is mobile endpoint security?

A mobile endpoint is any phone or tablet that connects to company data, including email, Microsoft 365, SaaS apps, and internal systems. Mobile endpoint security protects those devices, the data on them, and the accounts they can reach, across iOS, iPadOS, and Android.

Phones need their own approach because they work differently from laptops. Apps run in sandboxes that limit what a security tool can see, and software arrives through app stores rather than IT-controlled installers.

Devices also move between home, office, and public networks throughout the day, and the same phone often carries personal messaging, social media, and work apps side by side. Desktop security tools were built for a different operating model, so they rarely translate directly to mobile.

Why phones are the weakest point in most endpoint strategies

Attackers target phones because they hold credentials, MFA approvals, and access to email and collaboration tools, and because they are watched less closely than laptops. The most common threats are:

• phishing links sent by SMS, messaging apps, and QR codes
• malicious or over-permissioned apps
• attacks on public and rogue Wi-Fi networks
• devices left on outdated OS versions with known vulnerabilities

Phishing is also more effective on mobile than in the inbox. The Verizon 2026 Data Breach Investigations Report found that phishing simulations using text messages and voice calls had a median click rate about 40% higher than email. These messages bypass the email security tools most organisations rely on, which is why SMS and messaging-app phishing so often reaches employees unfiltered.

Many of the types of malware that affect laptops now have mobile equivalents. They are also harder to spot, because the sandboxing that protects users limits what mobile malware detection tools can observe.

Personal devices widen the gap further. Many organisations let staff read email or use Teams on personal phones that are not enrolled in MDM. IT then has no view of the device’s health, even though the phone can still reach corporate data.

The three layers of mobile endpoint security

The table below compares them.

Mobile endpoint management (MDM and UEM)

Mobile endpoint management covers the tools IT uses to enrol, configure, and control devices. These include mobile device management (MDM) and unified endpoint management (UEM) platforms such as Microsoft Intune and Workspace ONE, which manage phones alongside laptops.

They set passcode and encryption rules, deploy and update apps, enforce a minimum OS version, separate work and personal data, and lock or wipe a device if it is lost.

These controls deal with configuration and policy. An MDM can confirm that a phone has a passcode and a current OS, but it cannot see a phishing link in a WhatsApp message, a rogue Wi-Fi hotspot, or an app quietly sending data to an unknown server. It also only covers enrolled devices, which usually leaves out personal phones and contractors.

Compare MDM vs MTD

Mobile threat defence (MTD)

Mobile threat defence adds the detection that management tools lack. It runs as an app on the device and looks for threats in four areas: the device itself, its apps, its network connections, and the links and websites the user opens.

When it finds a threat, it can block it, warn the user, and pass a risk score to the management and identity layers. MTD is a well-established category, with around ten vendors compared in our mobile threat defence software guide, and most of them integrate with the major UEM platforms.

Mobile endpoint detection and response (mobile EDR)

Mobile EDR applies the EDR model to phones. That means continuously collecting device, app, and network events, raising alerts, and supporting investigation and automated response within the same SOC workflow used for laptops and servers.

In practice, the line between MTD and mobile EDR has blurred because many MTD platforms now include detection and response features. The term is mostly used to describe how deeply a product supports the security team once a threat is found.

Can your EDR protect mobile devices?

Many security teams assume their existing EDR already covers phones. Desktop EDR depends on deep access to the operating system, including process activity, file system changes, memory, and kernel events.

iOS and Android do not give third-party security apps that level of access, so a desktop agent cannot simply be installed on a phone.

This changes how detection and response works on mobile. Mobile tools rely on the signals that are available to them:

• network traffic and the destinations apps and browsers connect to
• installed apps and their permissions
• device configuration
• operating system integrity

The strength of a mobile EDR capability depends on how much it can learn from those signals and how quickly it acts on them.

Some EDR platforms extend to mobile through their own apps. Microsoft Defender for Endpoint, for example, has apps for Android and iOS, and our comparison of Corrata and Microsoft Defender for Endpoint on mobile sets out how the two approaches differ. Whichever route you take, test the mobile product against the requirements checklist instead of assuming it matches the desktop agent.

What mobile endpoint detection and response should include

A mobile detection and response capability should cover five areas.

Real-time detection and on-device remediation

The tool should act the moment a threat appears, for example by blocking a phishing site, cutting traffic to a malicious server, or warning the user, without waiting for an analyst to step in. Users should also get clear guidance on fixing issues they control, such as updating the OS or removing a risky app.

Risk-based conditional access

Detection becomes far more useful when it changes what a device can reach. The device’s risk level should flow to your identity provider or UEM, such as Microsoft Entra ID and Intune. Access to Microsoft 365 and other SaaS apps can then be blocked or limited until the threat is resolved. This is how zero trust principles extend to phones.

Automated response through integrations

For higher-risk threats, the platform should trigger action in the tools you already run. Examples include a selective wipe or app removal through the UEM, quarantine through network access control, or a policy change on the firewall. Look for controls over which responses run automatically and which need approval.

Investigation telemetry and threat hunting

Security teams need enough history to investigate an incident properly. That means device, app, and network events kept long enough to look back over weeks or months. Ask how long each type of data is retained and whether longer retention costs extra. For high-risk users, on-demand forensic collection such as iOS sysdiagnose files and Android bug reports adds valuable depth.

Threat intelligence and false-positive control

Detection is only as good as the intelligence behind it. Ask where the threat data comes from, how often it updates, and how the vendor handles new domains that no list has seen yet. How the tool handles mistakes matters just as much. Look for allow-listing, a simple way for users to report a wrongly blocked site, and a team that reviews those reports quickly.

How MDM, MTD, and EDR work together

Management, threat defence, and detection and response are designed to be combined. On a managed device, a typical flow runs as follows:

1. The UEM enrols the device, applies policy, and deploys the threat defence app silently.
2. The threat defence app monitors the device, its apps, and its connections, blocks what it can immediately, and calculates a risk level.
3. That risk level feeds conditional access in the identity provider, so a compromised phone loses access to corporate apps until it is fixed.
4. Alerts and telemetry flow into the SIEM, where the SOC can investigate mobile events alongside laptop and server activity.

Personal devices outside MDM can still be covered. The threat defence app can be installed from an email or SMS invite and report device risk into access decisions, giving security teams a view of phones that IT does not manage. The data on those phones needs protecting too, which is where mobile data loss prevention and controls on employee use of AI tools complete the picture.

How to Choose Mobile Endpoint Security in 2026

Mobile endpoint security requirements checklist

Use these questions to assess your current setup or to compare vendors.

• If an employee taps a phishing link in a text, a WhatsApp message, or a QR code, what stops the page from loading, even if the site was set up only hours earlier?
• Can you protect phones that IT does not manage, such as contractors’ and employees’ own devices? What do those users need to do to get protected, and how does their protection compare with a managed phone?
• How would you know if a phone had been jailbroken, was running an unsupported OS version, had its screen lock switched off, or had been targeted by spyware?
• Can you tell which apps on a phone are malicious or ask for more access than they need, and which AI tools your staff are using?
• What happens when a phone joins a fake hotspot or a network that is intercepting traffic, and is app traffic checked as well as browser traffic?
• When a threat is found, what happens without anyone stepping in? How does the device’s risk level affect what it can access, and how much history is kept for investigations?
• Which management, identity, and SIEM tools does it work with today, and how do alerts reach the right people?
• What can your admins see on an employee’s personal phone, how noticeable is the app on battery and performance, and is it available in the languages your staff use?

How Corrata approaches mobile endpoint security

Corrata provides threat detection and response for iOS and Android, protecting corporate-owned and personal devices in the same platform. Devices enrolled in a UEM activate through zero-touch deployment, and personal devices activate from an email or SMS invite. Corrata supports iOS 14.0 and Android 7.1 onwards.

Detection runs on the device using Corrata’s in-house engine. Traffic is inspected through a local loopback VPN that works alongside a corporate VPN, with a battery impact of around 1.25%. This lets Corrata block phishing links across SMS, messaging apps, email, and browsers, including newly registered sites and adversary-in-the-middle kits built to steal MFA codes. It also stops malicious destinations reached through QR codes.

On the network side, Corrata detects rogue Wi-Fi and man-in-the-middle attacks and blocks connections to command-and-control infrastructure at DNS and IP level. On the device itself, it flags jailbroken or rooted devices, out-of-date operating systems, risky configurations, and mercenary spyware.

When a threat is found, Corrata acts on the device in real time and can restrict access until the issue is fixed. Alerts flow into your SIEM, and Corrata’s security research team maintains a database of around 250,000 zero-day domains to keep detection current.

Corrata’s product privacy statement sets out what is collected from personal devices, and the app is available in English, French, Spanish, and German. Corrata is ISO 27001:2022 certified and runs an annual third-party penetration test. Every customer gets a named customer success manager, along with onboarding and admin training.

If you are reviewing your own stack, you can work through the requirements checklist with our team to see where Corrata fits.

The post Mobile endpoint security: Closing the MDM and EDR Gap appeared first on Corrata.

So the fair question is not whether Microsoft has something for mobile, but what that agent covers, where it stops, and whether the gaps matter for your risk profile. We spend a lot of time in Microsoft-first environments, so we put this together for security and IT teams working through exactly that question.

What we compared, and what we did not

This comparison covers Defender for Endpoint on iOS and Android, against Microsoft’s own published capability list.

Microsoft has other products that touch mobile, and it would be unfair to ignore them. Intune app protection policies control data movement inside managed apps. Entra conditional access decides who gets to connect. Purview handles classification and DLP. Where one of those changes the picture, we say so. Comparing Corrata against the entire Microsoft estate is a different exercise, and a much longer one.

Microsoft’s mobile capabilities are spread across several places: Defender web protection, custom URL indicators, and Intune app configuration policies for Edge. Coverage also varies by platform and by how a device is enrolled, since malware scanning is Android only, vulnerability assessment of apps on iOS applies to enrolled devices, and web protection on supervised iOS devices works differently from unsupervised ones. So if you are uncertain about what your current licence covers on mobile, that is understandable, and is worth checking before you assume either way.

The short version

Corrata’s DLP, AI governance, device quarantine and forensic capture sit in the Business and Enterprise tiers rather than in Essentials, so the comparison above is against the full platform.

Read down that table and the pattern matters more than the individual rows.

Corrata’s coverage is broad because it comes from one place: category-based web filtering, DLP over data heading to unsanctioned services including AI assistants, visibility of SaaS use across the fleet, encryption quality assessment, forensic capture from a suspect device, and quarantine while it is investigated. All of it needs an agent that can see the device’s own traffic in detail and act on it locally, which is what on-device deep packet inspection provides.

Defender’s mobile agent works from the destination and the device’s configuration instead. It provides anti-phishing and blocks unsafe network connections, scans apps and files on Android, assesses vulnerabilities, detects jailbreak on iOS and root on Android, and feeds risk into conditional access. That architecture is why it has no category filtering, no mobile DLP, no view of AI or SaaS use, no encryption assessment and no on-device forensics. 

Let’s break it down across six areas of concern.

Phishing that arrives outside the browser

Most mobile phishing does not arrive by email any more. It arrives by SMS, WhatsApp, iMessage, a QR code on a poster, or a poisoned search result. Defender’s web protection provides anti-phishing and blocks unsafe network connections, with custom indicators covering URLs and domains. It works from the destination, which means the delivery channel matters less than whether the destination is already flagged.

That is where the difference shows up. In Corrata’s own weekly testing across mobile messaging channels, Defender for iOS detected fewer than one in five of the phishing attacks we sent through. 

Our detection inspects traffic on the device in real time, and Zero Day Protection blocks destinations with no reputation history rather than waiting for one to build. Phishing infrastructure that only lives for a few hours is where reputation-based checking struggles most.

Acceptable use and category-based web filtering

If you need to stop staff reaching gambling, adult or other categories on a work phone, Defender will not do it. Microsoft’s documentation states that web content filtering is not supported on mobile platforms, on either Android or iOS. You can block named sites with custom URL and domain indicators, so a specific block list is achievable, but there is no category engine behind it.

There is a second route, and it is worth understanding before anyone suggests it. Intune app configuration policies let you set an allow list or a block list on Edge for iOS and Android. On iOS, Microsoft’s Edge data security guidance notes that the two lists are mutually exclusive, so you get one or the other. The lists apply at navigation level, so a blocked URL embedded inside a page still loads, and Edge blocks sites only when they are reached directly rather than through an intermediate service such as a translation proxy. And it only covers Edge, so it does nothing unless you also block every other browser through conditional access. Maintaining a hand-built domain list per category, across two platforms, in a single browser, is not what most acceptable use policies assume.

Corrata filters by category across all traffic rather than one browser, which supports acceptable use enforcement and wider compliance efforts.

Data leaving the device, including AI chatbots

This is the gap that has grown fastest. Staff paste customer data into whichever AI assistant is open, and on mobile most security teams have no visibility at all.

Microsoft’s endpoint DLP covers Windows and macOS devices, with no mobile equivalent. Shadow IT discovery has more than one route: you can ingest firewall and proxy logs, which will pick up mobile traffic while the phone is on your network, and you can use the Defender for Endpoint integration, which is what extends discovery beyond the corporate network, requires Plan 2 or Defender for Business premium, and lists Windows and macOS as the supported operating systems. So a phone on cellular or home Wi-Fi is not covered either way.

Intune app protection policies do help here, and any fair assessment should say so. They stop data moving from a managed app into an unmanaged one. They work at the app boundary, though, so they cannot tell you which AI services your staff are using, and they will not stop someone opening an unsanctioned chatbot in a browser and typing into it.

Corrata works at the network layer on the device, which means you can allow the AI tools you have sanctioned, block the ones you have not, restrict unauthorised file shares and email services, and see which SaaS services your mobile fleet is actually using, on or off your network.

Spyware, forensics and containment

Mercenary spyware is a niche concern for most organisations and an existential one for a few: legal, journalism, public sector, anyone with exposure to nation-state interest.

Investigating it needs three things. Continuous visibility of device traffic. The ability to pull diagnostic files and packet captures off a suspect handset. A way to contain the device quickly. Microsoft’s mobile capability list does not include behavioural monitoring of device traffic, and device isolation is documented for Windows, macOS and Linux rather than mobile. Mobile alerts and network events do surface in the portal and, with Plan 2, in advanced hunting. What you cannot do is pull diagnostic files or a packet capture off the handset itself, which is what a spyware investigation turns on.

There is a containment route on mobile, which is risk-based conditional access. It blocks the device from reaching corporate resources, which is useful and worth configuring. It does not take the device off the network, so anything already resident on it keeps running and keeps talking to its operator.

Corrata monitors device traffic continuously, collects diagnostics and packet captures for investigation, and can quarantine a device when something is found.

How well is the traffic actually encrypted?

Defender’s network protection detects rogue Wi-Fi and rogue certificates, which covers the classic interception scenarios and is a real capability. Microsoft documents the ability to allow-list root certificate authority and private root certificate authority certificates in Intune, which is how you stop Defender flagging your own internal certificates as rogue, and that configuration is set out in the Android guidance. Worth knowing that Microsoft moved open wireless network detections from portal alerts to the device timeline in May 2025, so if your SOC processes were built around those alerts they will need revisiting.

What network protection does not do is assess connection quality. Weak cipher suites, outdated TLS versions and applications sending sensitive data over encryption that should not be trusted all sit outside what the mobile agent looks at.

Corrata inspects the TLS handshake on the device and reports weak encryption when it finds it, and blocking is available as an administrator policy choice rather than something that happens by default.

Employee privacy and permissions

Privacy deserves care here, because Microsoft’s position is clearer than it is often given credit for. Its privacy documentation states that an organisation cannot see browsing history beyond blocked malicious sites, location history, message content, contacts or stored files, and admins have controls over what appears in threat reports.

The practical difference is permission footprint, and it matters because permission prompts are what employees actually react to during rollout. On Android, the app requests storage access so it can scan for malicious files, and prompts for location access so network protection can assess Wi-Fi threats. 

Location is optional, and declining it leaves certificate-based protection working while Wi-Fi threat detection is reduced. On iOS the picture depends on how the device is enrolled. Unsupervised devices get a VPN profile prompt, and web protection depends on it. That VPN is a local loopback that keeps traffic on the device, and admins can make the permission optional, though skipping it leaves web protection inactive. Supervised devices are different, because Microsoft provides a control filter profile that delivers web protection without installing the VPN at all, and can pair it with zero touch onboarding so the user does not need to open the app to get onboarded. If you run a supervised iOS estate, the permission-prompt concern largely goes away.

There is one more distinction worth knowing if you run supervised iOS devices. Microsoft’s iOS configuration documentation states that on supervised devices with the configuration profile, Defender can access the entire URL, while on unsupervised devices it has access only to the domain name.

Corrata does not access location, read message content, scan files or record browsing history. What it observes is connection metadata: domain and server names, IP addresses, port numbers, SSL certificate details, app hashes and permissions. Domain-level metadata rather than full URLs, page content or search terms is a meaningful distinction, and it is the one worth making explicit when a works council asks.

Where compliance comes into it

Neither NIS2 nor DORA names mobile threat defence, and no product makes you compliant. Both expect you to show the measures you have in place and evidence how you detect and report incidents. Mobile is usually the part of the estate with nothing to show, and DORA’s clocks are short: initial notification of a major incident within four hours of classification and 24 hours of becoming aware.

Defender covers part of this. Devices appear in the portal, alerts land with everything else, and posture feeds conditional access. What it cannot give you is category-level acceptable use enforcement, a record of what data left a device, or on-device collection to reconstruct an incident on a handset.

Corrata covers that ground. Acceptable use by category, visibility and policy control over data going to unsanctioned services including AI assistants, diagnostics and packet capture from a suspect device, and quarantine while it is investigated, all reporting into your SIEM. For regulated organisations, that supports compliance efforts in the one area that is usually dark.

Which one do you need?

Defender for Endpoint is a strong product, and this comparison should not leave you thinking otherwise. Across Windows, macOS and Linux it gives you EDR, device isolation, vulnerability management and forensic investigation, feeding an XDR picture that spans identity, email and cloud. If your risk is concentrated on laptops and servers, that is a good place to be.

Mobile sits differently inside that mix. The mobile agent brings a subset of what Defender does elsewhere: connection checks against known-bad destinations, app scanning on Android, vulnerability and jailbreak reporting, and risk signals for conditional access. The deeper capabilities stay on the desktop side, which is why category filtering, DLP, on-device forensics and isolation are absent on phones.

That matters more than it used to. Phishing arrives by message rather than email, data leaves through AI assistants nobody sanctioned, and commercial spyware increasingly targets handsets alongside laptops. Phones carry the same data as laptops with a fraction of the visibility, which is why a purpose-built mobile threat defence layer has become a distinct requirement rather than a nice-to-have.

Corrata is that layer. On-device deep packet inspection gives you phishing protection across messaging apps, browsers and QR codes, policy control over AI and SaaS use, category-level acceptable use enforcement, encryption quality assessment, and forensic capture and quarantine when something goes wrong, without asking employees for permissions that read their files or track their location.

Book a demo to explore what Corrata sees on a handful of test devices.

The post Corrata and Microsoft Defender for Endpoint: How they compare on mobile appeared first on Corrata.

Mobile threat defense software exists to close that gap. It sits within the wider field of mobile security software, and it is separate from device management. The difference matters more than the names suggest.

This guide covers why phones need their own protection, what mobile threat defense software does, how it differs from the tools sitting next to it, and which providers are active in 2026.

Note: Corrata publishes this guide and is one of the providers listed.

Jump to the list ↓

What is mobile threat defense, and why you need it

Phones are built differently from laptops, and that shapes how they can be protected. Mobile operating systems run each app in a sandbox and withhold the kernel-level access that desktop security tools rely on, so protection has to work through narrow interfaces that the platforms choose to expose, and Android exposes considerably more of them than iOS.

Phishing is the threat that matters most, and on a phone it arrives through text messages, WhatsApp, LinkedIn, Signal, and other channels that no email gateway inspects. The small screen makes it harder to spot, because addresses are truncated and there is no hover preview.

QR codes take this further. A code on a poster, an invoice, or a parking meter is scanned with the phone’s camera and opens a page that nothing on the corporate network inspects, an attack known as quishing.

Apps, networks, and the device itself are the other routes in. Sideloading bypasses store review altogether, rogue access points combined with downgrade or certificate tricks can expose traffic the user believes is protected, and older Android handsets stop receiving security updates while they are still in daily use. Commercial spyware sits at the severe end, and some of it needs no interaction from the target at all.

Each of these maps onto one of the three detection layers described below. Our guide to mobile security software covers how they fit alongside device management, data loss prevention, and filtering.

What is mobile threat defense software?

Mobile threat defense, commonly shortened to MTD, is software that detects and blocks threats on iOS and Android devices. It usually works across three layers:

• At the device layer, it checks the state of the phone itself, looking for jailbreaking or rooting, missing security updates, weak configuration, and signs of compromise.
• At the app layer, it assesses installed applications for malicious behaviour, excessive permissions, and unsafe data handling.
• At the network layer, it inspects connections to catch interception attempts, and to block traffic to phishing and command-and-control infrastructure.

Deployment is usually through an app pushed out by whatever management platform the organisation already runs, though most products also support devices that are not enrolled in management at all. That matters for contractors, and for staff who decline to enrol a personal phone.

Where the analysis happens varies between products, and it is one of the more meaningful differences between them. Some run detection on the device itself, so the threat decision is made locally rather than in the cloud, which means protection continues when the phone has no connectivity and the content being assessed is never sent away for analysis. Others send telemetry to a cloud service that assesses risk centrally, which allows heavier analysis and correlation across a fleet. Several combine the two.

Most products also feed a signal into access decisions. If a device is judged risky, conditional access policies can block it from reaching email, files or business applications until the problem is resolved.

It is worth being clear about the limits. Mobile threat defence does not manage devices, distribute software, or enforce configuration, nor does it replace the security controls sitting in front of your applications and data. It detects and responds to threats reaching the phone. 

MTD, MDM, UEM and mobile EDR: what the differences are

These four terms are used loosely, and the overlap may cause genuine confusion during procurement:

Mobile device management, or MDM, handles enrolment, configuration and policy. It sets passcode rules, pushes applications and certificates, separates work data from personal data, and wipes a device when someone leaves. MDM administers a phone, but it is not built to detect an attack on one.

Unified endpoint management, or UEM, is the broader version of the same idea. It brings phones, tablets, laptops and desktops into one console. Several UEM products bundle some threat detection, which is often adequate for lower-risk fleets, and it is worth establishing what yours already includes before buying anything additional.

Mobile threat defence (MTD) sits alongside both. It may assume devices are managed, and concentrates on identifying threats and stopping them. In most deployments, MTD and MDM run together and exchange information, with the management platform acting on what the threat product finds.

Mobile endpoint detection and response, or mobile EDR, is a newer framing borrowed from the laptop world. The emphasis shifts from detection towards investigation: collecting operating system telemetry, reconstructing what happened on a device, and supporting a forensic response. Several established providers now use this label for products that differ considerably in what they actually collect and support, so it tells you less than the underlying capability does.

One further category is often mistaken for this one. In-app protection, sometimes called app shielding or mobile application security, protects software your organisation publishes to its own customers. It strengthens your app against tampering and reverse engineering. It is useful work, aimed at an entirely different buyer, and not what this guide covers.

Mobile Threat Defense Software in 2026

The providers below are sold as distinct offerings for iOS and Android, with published technical documentation and integration into at least one major management platform. Entries are not ranked.

One thing worth knowing before you read on: the number of vendors in this market is larger than the number of independent detection engines. Some products are built on licensed technology from other vendors in this same list, which is noted in the relevant entries.

Corrata

Headquarters: Dublin, Ireland

Corrata’s mobile threat defence platform delivers threat detection and response and data loss prevention for mobile endpoints on iOS and Android.

It blocks phishing attacks across every channel, detects spyware and cuts off its communications, controls the use of Shadow AI, prevents data loss, protects against adversary-in-the-middle interception, monitors device configuration for vulnerabilities, and keeps compromised devices away from sensitive data.

Features:

1. On-device deep packet inspection: Inspects app traffic on the device across all ports and key protocols, not DNS alone, with IP and port blocking and dynamic malware detection.
2. Mobile phishing protection beyond email: Catches attacks delivered via notifications, text messages, QR codes and social media posts, including credential harvesting, MFA bypass and authentication cookie theft.
3. Shadow AI governance and DLP: Monitors policy breaches on connections to consumer AI services, unsanctioned SaaS and ad tracking, and intervenes automatically. Learn what is AI governance.
4. Spyware and malware detection with quarantine: Intercepts command and control traffic to stop exfiltration, guides users through removal, and automatically quarantines at-risk devices per specifications in your policy.
5. Device trust and conditional access: Assesses posture on both corporate and personally owned devices, and blocks access from any device that fails.
6. Deployment: Corrata offers zero-touch for managed and unmanaged devices, with manual enrolment by email or SMS for BYOD fleets and organisations without MDM.
7. Integrations: Microsoft Intune and Omnissa Workspace ONE for management, Microsoft, Google and Okta for identity, and Microsoft Defender for Endpoint for XDR. ISO 27001 certified.
8. Privacy-preserving architecture: No location tracking, no file scanning, no browsing history and no access to message content.

Check Point Harmony Mobile

Headquarters: Tel Aviv, Israel 

Check Point Harmony Mobile is the mobile threat defence component of the Check Point Harmony suite. It secures iOS and Android devices across app, network and OS attack vectors, and integrates with existing UEM platforms for compliance and policy enforcement.

It stops malware from infecting employees’ devices by detecting and blocking the download of malicious apps in real-time. It blocks phishing delivered through any app, prevents man-in-the-middle attacks on cellular and Wi-Fi networks, blocks infected devices from accessing corporate data, and recognises and blocks advanced jailbreaking techniques.

CrowdStrike Falcon for Mobile

Headquarters: Austin, Texas

CrowdStrike Falcon for Mobile extends the Falcon platform’s endpoint detection and response to iOS and Android, managed from the same console as workstations and servers. CrowdStrike positions it as mobile EDR rather than conventional MTD.

It detects suspicious activity and links across texts, email, browsers and QR codes, uncovers mobile malware, network disruption, spoofed identities and jailbroken devices, and can contain affected devices from the console.

It offers built-in blocklisting of malicious IPs to reduce risk exposure, blocks malicious links and unauthorised domains, and identifies mobile malware, network disruption, spoofed identities, jailbroken devices and accidental data exposure.

Ivanti Neurons for Mobile Threat Defense

Headquarters: South Jordan, Utah

Ivanti Neurons for MTD protects Android, iOS, and iPadOS devices, both corporate and employee-owned. Ivanti’s MTD capability is built on Zimperium technology, and setup requires a Zimperium management console tenant. Detection and remediation run both on the device and in the cloud.

It monitors device parameters and configuration, network traffic and installed apps, prevents phishing through real-time link analysis, and applies local compliance actions to remediate threats on the device.

Jamf Protect for Mobile

Headquarters: Minneapolis, Minnesota

Jamf is an Apple device management company that added mobile threat defence through its 2021 acquisition of Wandera and has been privately owned by Francisco Partners since January 2026. Jamf Protect covers macOS, iOS, iPadOS, and Android from one product, with traffic inspection delivered through secure DNS by default and a proxy-based option for deeper visibility.

It blocks phishing, cryptojacking and malicious domains in real time, flags apps with dangerous permissions or suspicious developer profiles, filters web content against acceptable use policies, reports cellular data use by app, assesses OS and app vulnerabilities against CVE severity data, and feeds device risk into conditional access. 

Jamf Mobile Forensics is a separate add-on covering mercenary spyware and zero-click attacks for high-risk users.

Lookout Mobile Endpoint Security

Headquarters: Boston, Massachusetts

Lookout Mobile Endpoint Security is a mobile threat defense vendor that protects iOS, Android, and ChromeOS devices, and detects phishing across email, SMS, messaging apps and social media. 

It assesses applications for malware, privacy risk, and security risks, identifies vulnerable operating systems, encrypts and secures DNS traffic, detects network attacks and advanced spyware, and feeds device posture into conditional access decisions.

It identifies rooting, jailbreaking, OS tampering and advanced exploitation techniques. It also identifies rogue Wi-Fi networks, man-in-the-middle attacks, and insecure network conditions in real time. 

Microsoft Defender for Endpoint

Headquarters: Redmond, Washington

Microsoft Defender for Endpoint provides web and phishing protection and blocks unsafe network connections on Android and iOS. Malware detection is available on Android and jailbreak detection on iOS, and Microsoft Defender Vulnerability Management assesses both.

Device risk feeds Intune compliance policies and Conditional Access, and on iOS Microsoft documents a deployment option that uses app protection rather than device enrolment.

Compare Corrata and Microsoft Defender

Pradeo Security Mobile Threat Defense

Headquarters: Montpellier, France

Pradeo is a French mobile security company whose MTD platform protects Android, iOS, and Chromebooks. It detects application, network and OS-borne threats including malware, spyware, intrusive applications and phishing, and remediates them without requiring admin intervention.

Pradeo lists network protection against man-in-the-middle attacks, malicious relay antennas and malicious proxy connections among its capabilities, alongside detection of outdated operating system versions and rooted or jailbroken devices.

SentinelOne Singularity Mobile

Headquarters: Mountain View, California

Singularity Mobile is SentinelOne’s mobile threat defense module, covering iOS, Android, and ChromeOS from the same console as its endpoint products. It describes its detection as on-device and AI-based, and says the product works with or without MDM. SentinelOne announced the product at launch as powered by Zimperium, and Zimperium lists SentinelOne among its partners.

It detects zero-day malware, phishing, and man-in-the-middle attacks, vets apps continuously for privacy and security risk, and blocks network attacks (including rogue Wi-Fi) and unsafe communications.

Zimperium Mobile Threat Defense

Headquarters: Dallas, Texas

Zimperium Mobile Threat Defense protects company-owned and BYOD devices across iOS, Android, and ChromeOS. It states that its on-device machine learning detects known and zero-day threats in real time and continues to work when the device has no network connectivity. Zimperium also licenses its detection technology to other vendors, including Ivanti.

It detects mobile-targeted phishing, assesses both enterprise and personal apps for risk, identifies rogue and unsafe networks, checks device integrity, and supports forensic scanning of affected devices.

Compare Corrata and Zimperium

**All images from respective websites

Choosing the right mobile threat defense software

The products in this market are more alike in their marketing than in their design. These questions tend to separate them:

• What does your existing platform already cover? If you already license a management or endpoint suite that includes mobile detection, the question is not which product is strongest in isolation, but whether the additional coverage justifies a second contract and a second console.
• Are unmanaged devices in scope? Contractors, board members, seasonal staff and employees who decline to enrol a personal handset all reach company data on devices you do not manage. Some products handle these well and some assume enrolment. If this population matters to you, test it specifically rather than taking a datasheet claim on trust.
• Where does detection run? On-device analysis keeps working when connectivity drops and keeps traffic local. Cloud analysis allows heavier processing and correlation across the fleet. Neither is automatically better, but the choice affects offline coverage, battery and data use, and what leaves the device.
• What does it collect from personal phones? This is the question that determines whether a rollout succeeds. Employees will not accept a tool they believe reads their messages or tracks their browsing. Ask what telemetry is gathered, what the organisation can see in the console, and what remains invisible to it. 
• Do you need investigation, or detection alone? If a phone is compromised, what does your team need to do next? Some organisations need an alert and a block. Others need to establish what was accessed, over what period, and to produce evidence for a regulator or an insurer. That distinction points to different products.
• Where is data processed and stored? Sector and jurisdiction may constrain this. Establish which regions handle the telemetry, who the sub-processors are, and whether the answer is contractual or merely current practice.
• How does it fit what you already run? Check the integrations you will actually use: your management platform, your conditional access policies, and your SIEM or logging pipeline. Ask whether these are supported products or a professional services project.
• Is it built on another vendor’s engine? Some products in this market license detection technology from other vendors. That is not a problem in itself, but it is worth knowing, because an organisation running one platform’s management product and another’s threat product can end up buying the same detection engine twice. Ask directly whose technology performs the detection.
• How will you know it works? Agree the evidence before you sign. Run a pilot on real devices in your own environment, with your own policies. Ask what the product misses, and be wary of any answer suggesting it misses nothing.

Conclusion

Phones now carry the email, approvals, customer data and AI tools that attackers want, and many of the controls that protect laptops and email never see what arrives on them. Device management keeps phones configured and compliant, and mobile threat defense adds the detection and blocking that management was never designed to provide.

The providers in this guide differ most in where detection runs, what they collect from personal devices, and how far they go beyond an alert. Several share an underlying detection engine, so it is worth asking whose technology performs the detection before comparing features.

The right choice depends on what your existing licences already include, whether unmanaged and personally owned devices are in scope, and what evidence your organisation needs after an incident.

If you would like to see how Corrata approaches mobile threat defense, book a demo and we will walk through it with your own devices.

The post Mobile Threat Defense Software: The Market in 2026 appeared first on Corrata.

Earlier this year we ran a 12 week proof of value with a leading financial services organisation operating across Africa. The brief was specific: could Corrata detect advanced spyware and mobile threats that their existing controls were missing? The deployment covered 20 users, a deliberately small sample chosen to allow deep analysis of every alert.

Twelve weeks of traffic from 20 devices produced a genuinely broad threat picture: live phishing infrastructure, malware distribution networks, suspicious command and control patterns, aggressive adware and unencrypted data leakage. It also made a strong case for mobile spyware detection built on traffic inspection rather than app inventory alone.

In this post we focus on one area of interest that stood out for how preventable it is: fake versions of popular apps distributed outside official app stores, requesting permission sets that would make a surveillance tool blush. We then walk through the other notable findings from the trial.

Area of interest: fake versions of the apps everyone uses

The most striking discovery of the trial was not an exotic piece of malware, but the apps everybody recognises.

On one enrolled device, Corrata identified unofficial versions of X (Twitter), Facebook, WhatsApp and, remarkably, the Android Settings app itself. Each one was convincing on the surface. The package names matched the genuine apps exactly. The version numbers matched current official releases. To the user, and to any security tool doing a superficial app inventory check, these looked legitimate.

The cryptographic hashes told a different story. Every one of these apps failed verification against the official builds. Same name, same version, different binary. That is the signature of a repackaged app: a genuine application that has been unpacked, injected with additional code, and rebuilt for distribution through third party channels.

The injected functionality was visible in the permission manifests. Compared to their official counterparts, the fake apps requested a set of additional capabilities that reads like a wiretap specification:

• Accessibility service binding on the fake X, Facebook and WhatsApp. Accessibility abuse is the workhorse of modern Android banking trojans and spyware. With this permission, an app can read everything on the screen, capture credentials as the user types them, and interact with other apps on the user’s behalf.
• Call control on the fake Facebook: the ability to answer incoming calls programmatically, place calls without showing the dialler, read the device’s phone number and read the full call log. Together these allow silent call interception and the mapping of everyone the user speaks to.
• System-level powers on the fake Settings app, including the ability to shut the device down, start activities from the background and manage role holders. Impersonating a system app is a persistence strategy: users do not uninstall Settings, and most would never think to question it.

The same device was also making callbacks to two algorithmically generated domains on low-reputation TLDs, the classic fingerprint of command and control communication. Fake apps and C2 traffic on one handset is not a coincidence. An infection chain is observed end to end.

And it was not a one-off. A second device in the same 20 user deployment carried the identical trio of fake X, Facebook and WhatsApp. A third showed suspicious versions of Package Installer and Settings. A fourth combined a modified WhatsApp with traffic to APK download sites and multiple malware distribution domains. Behavioural analysis of the malware on that device showed dynamic code loading, foreground service abuse for persistence, wake locks to keep the device alive, connections to unusual ports including SMTP, and external IP checks. That is a device being operated, not just infected.

The sideloading connection

Where do fake versions of Facebook and WhatsApp come from? Not from Google Play. Official stores are not perfect, but they verify developer signatures, scan submissions, and remove known-bad packages at scale. A repackaged com.facebook.katana with a mismatched hash cannot survive there.

Sideloading inverts that model. Third party app stores and direct APK downloads let anyone upload a rebuilt APK. Popular apps are cloned within days of release, injected with adware, credential stealers or full surveillance toolkits, and served to users looking for a free, unlocked or region-unrestricted version of something they already trust. Third party apps carry the trust in the brand. The scrutiny does not carry with them.

We saw this dynamic from another angle in the same trial. One device carried a fake GPS camera utility downloaded from APKPure, a popular third party Android store. Its permission set combined camera access, fine location, full read access to stored photos and video, persistent background execution and unrestricted network access: the functional definition of spyware, wearing a utility app’s icon. Corrata detected it and quarantined the device, cutting off its network access. The user removed the app. Over the following six days the same malware was detected on the same device five more times, each removal followed by a reinstall. Uninstalling a binary is not remediation when the distribution source is still one tap away.

The infrastructure side was visible too. Devices in the deployment generated blocked traffic to APK download sites and to a regional third party app store whose own client was transmitting device data over unencrypted HTTP: device make and model, operating system version and location, readable by anyone on the network path. No malware required. The store itself was the leak, a reminder that third party app store risk extends beyond the apps on offer to the store client itself.

The wider findings: what else 20 devices surfaced

Fake apps were one thread among several. The same 12 weeks of traffic produced findings across the full mobile threat surface, each significant in its own right.

Malware distribution and C2 infrastructure. Corrata blocked connections to well over a dozen active malicious domains. Several used algorithmically generated names on cheap TLDs such as .cfd, .top, .shop, .help and .world, classic indicators of Domain Generation Algorithms, the technique malware uses to locate its command and control servers even when individual domains are taken down. One device alone was linked to six distribution domains. Another, an iOS device, generated over 300 blocked malware connections during the trial period.

Phishing. Multiple devices attempted to reach live phishing infrastructure, including a domain impersonating a well known pan-African bank and a site harvesting usernames and passwords through a popup. For a financial services workforce, a convincing clone of a peer institution is exactly the lure most likely to succeed.

Suspicious command channels. One device generated simultaneous UDP traffic to four external IP addresses on a port associated with trojan activity. Two of the destination IPs were listed on the Spamhaus blocklist for suspected malicious activity. This is the traffic signature of a callback: an implant checking in with its operators.

Aggressive adware. A single device made 438 blocked connection attempts to one ad-tracking network, the pattern of a persistent process hammering away in the background and degrading privacy, performance and battery life.

Advanced spyware indicators on iOS. The original brief for this trial was advanced spyware detection, and iOS was not exempt from scrutiny. Seven iOS devices in the deployment, spanning multiple OS versions, exhibited traffic patterns that warranted escalation for investigation against known mercenary spyware behaviour.

Sophisticated spyware on iOS leaves almost no trace on the device itself. Its network behaviour is where it becomes visible, which is why mobile spyware detection at the traffic level was central to this engagement.

The pattern underneath the findings

Almost every serious finding in this trial shares a common thread. The threats did not arrive through email, and they did not exploit an unpatched operating system. They arrived through content: an app downloaded from the wrong place, a link tapped in the wrong context, an ad network with malicious intent.

This matters because most mobile security tooling cannot see content. A solution relying on superficial app inventory would have seen com.whatsapp at the current version number and moved on. What surfaced these threats was on-device deep packet inspection combined with cryptographic app verification: the ability to inspect the actual traffic leaving the device and validate what is genuinely installed, on the device, in real time.

That is how you spot a repackaged app with a matching version string, cleartext data leakage, DGA callbacks and phishing connections at the moment they happen, without routing user traffic through the cloud.

What security teams should take from this

1. Verify apps cryptographically, not cosmetically. Package name and version number are trivially spoofed. Hash verification against official builds is the only reliable test, and it caught four fake apps on a single device in this trial.
2. Treat sideloading as a policy decision, not a user preference. If your fleet includes Android devices, define whether third party app stores and direct APK installs are acceptable and enforce it. For BYOD populations where enforcement is harder, visibility becomes the control.
3. Assume uninstall is not remediation. Our repeat-detection data shows malware coming back within hours of the user removing it. Quarantine contains the risk while it is present, but the fix is to root cause the installation source, not just the binary.
4. Treat accessibility permission requests as high-signal events. Legitimate social and messaging apps do not need accessibility service binding. Its presence in a familiar app is close to a smoking gun.
5. Inspect traffic, not just apps. Unencrypted data leakage, C2 callbacks and phishing connections are all network events, and on iOS the network is often the only place advanced spyware shows itself. If your mobile security stack cannot see traffic content, it cannot see the majority of what we found here.
6. Small fleets still produce real findings. This was 20 devices over 12 weeks. Scale the numbers to a 2,000 device estate and consider what is currently going unseen.

Mobile devices are where your users read email, approve MFA prompts and access corporate data. In this deployment, apps indistinguishable from WhatsApp and Facebook at a glance were carrying the permissions needed to read screens, intercept calls and map every contact a user speaks to. They were caught because the device itself was doing the inspection.

If you want to see what 12 weeks of visibility looks like on your own fleet, a Corrata proof of value deploys in under 24 hours, with no MDM required. Book a demo today.

The post When WhatsApp Isn’t WhatsApp: Third party app store risk appeared first on Corrata.

That gap is where shadow AI lives, the AI use nobody sanctioned, nobody reviewed, and nobody can currently see. And it doesn’t only come from careless employees pasting the wrong thing into a chatbot.

Malicious actors have moved just as quickly, using generative tools to craft sharper phishing, automate reconnaissance, and probe for exactly the blind spots that new AI traffic opens up. The result is a widening space between what your people are actually doing and what your controls can govern.

What is shadow AI?

Shadow AI is any use of AI tools inside an organisation that happens without the knowledge or approval of IT and security teams. It’s the AI equivalent of shadow IT, but broader and harder to spot. Sometimes it’s an employee pasting company data into a consumer chatbot to save time.

Just as often it’s an AI feature quietly switched on inside an app the business already uses, sending data to a model provider that nobody signed off on. Because so much of it runs on personal mobile devices and over ordinary web connections, most of it never appears in the tools security teams already run.

Shadow AI matters because it undercuts AI governance before governance even starts. Governance decides which tools are sanctioned, what data may go into them, and how that gets enforced day to day, and all of it assumes you know what’s in use. You can’t write a policy for AI you don’t know about, and you can’t enforce one against traffic you can’t see, which is why you need to know what is AI governance.

Six weeks of real data

For six weeks, our on-device inspection engine recorded what AI activity actually looks like on our customers’ mobile fleets. This wasn’t a survey or a projection. It was real traffic from real devices, logged as it happened.

Between April and June, our detection database captured every AI connection moving across those fleets, and the picture it produced is worth sitting with. Adoption is close to universal, it’s growing fast, and most of it never shows up in the tools security teams already run. The shadow AI it reveals isn’t theoretical, it’s already on the devices in your organisation.

84% of our customers had AI traffic on their mobile fleet, and that volume is climbing by around 40% every month. To be clear, that’s month on month, not annually. So a footprint that looks small today is roughly half again as big four weeks later, and bigger still the month after that. Run that out over a quarter and something a security lead might currently wave off as marginal becomes the largest category of sensitive data leaving the fleet.

The bigger concern isn’t the volume, it’s what the traffic is made of. Of the AI domains we detected, 69% were ones we’d never seen before. That number tells you something uncomfortable about how blocklists work. A list goes out of date the moment you finish writing it, because the tool your team picked up this week wasn’t on anyone’s radar last week. So a static defence always trails a step behind, governing last month’s reality while your people have already moved on.

The easy assumption is that this is really an OpenAI problem. OpenAI did turn up in about a third of accounts, but the interesting part is everything behind it. We saw AI systems most security teams have never heard of, things like Bloomreach, Emarsys, Sprig, Sendbird and Gorgias, plus a pile of AI features quietly built into apps employees already had on their phones.

Nobody chose to deploy most of these. They arrived as updates to software the company already trusted, switching on features that feed data to a model provider with no procurement step, no review, and nothing in the acceptable-use policy to cover them. And that’s the trap: you can’t govern a service you can’t name, and you can’t name one your tools never see.

Why shadow AI isn’t just old shadow IT

It’s tempting to file all this under shadow IT and reach for the usual playbook. That undersells what’s changed. Shadow AI is a genuinely new kind of problem.

Before 2022, there was simply no way for an employee to paste a client database into a consumer service in thirty seconds and get something useful back. The channel didn’t exist. Generative AI opened a completely new route for sensitive data to leave the building, and it’s casual, instant, and at the network level almost impossible to tell apart from ordinary web browsing.

Mobile is where the exposure runs deepest. A personal phone keeps no wall between work and personal life, so company data and consumer apps sit side by side on the same device with nothing in between. No proxy stands in the way, no inspection point, no gateway deciding what’s allowed out. The employee just connects straight to the AI service.

None of the tools already in place catches this, because nobody designed them to. EDR watches for malicious processes, not where a legitimate app sends its data. Email security only covers email, and this leaves by a different door.

Older data loss prevention handled attachments and file transfers, not a browser tab or an in-app assistant streaming text to a model endpoint. Each of those tools does its own job fine. This just isn’t a job any of them was built for, which is why shadow AI slips through a stack that looks complete on paper.

Why AI governance has to start with visibility

There are broadly two ways to respond, and they lead to very different places.

The first is the blocklist: list the AI systems you know about, block them, and hope the list holds. It doesn’t. Our data shows why, with 69% of the domains we saw being brand new. Blunt blocking carries a second cost too. It nudges the more determined employees to work around you, through a personal hotspot or an unmanaged device, and once they do that you’ve lost whatever visibility you had to begin with. You haven’t removed the risk. You’ve just stopped being able to see it.

The second is to make it visible first, then govern it. This is the heart of real AI governance, and the order matters. Rather than guessing at a list, you watch what’s genuinely in use. Every AI service touching the fleet becomes visible, whether it’s sanctioned or not.

New domains surface the moment they appear instead of weeks later when someone gets round to updating a feed. And the device itself stops sensitive uploads in real time, before anything crosses the line. Policy follows what you actually know, which is the only order that works when most of what you’re dealing with didn’t exist last month. You cannot govern shadow AI you cannot see.

Why only on-device DPI sees this

We can see all this because the inspection happens on the device itself. No VPN tunnel, no proxy, no agent relaying traffic back to the cloud. Our on-device deep packet inspection sees the real destination an app or an employee is connecting to, the actual AI service and the brand-new domain, rather than just coarse metadata about the connection.

Traditional MTD and MDM tools don’t look this deep. They’ll flag a known malicious domain or a dodgy Wi-Fi network, but they miss a marketing app quietly shipping data to an AI platform nobody signed off on, or an employee pasting sensitive content into a consumer chatbot.

For our customers, the difference is a live view of every AI service touching their fleet, and the ability to govern it, instead of finding out once the data has already gone. As AI models multiply inside everyday apps, that live view is the only foundation an AI governance policy can actually stand on.

Your employees are already using AI on their phones. That much is settled. The only open question is whether you can see it, or whether shadow AI is growing by 40% a month inside a channel you have no way to inspect.

See Corrata’s DPI in action. Request a demo to understand your organisation’s vulnerabilities.

The post Shadow AI on Mobile: The Need for AI Governance appeared first on Corrata.

During a recent partner evaluation, Corrata flagged a connection to a major banking app. At first glance it looked like a false positive. It wasn’t.

The app was negotiating TLS_RSA_WITH_AES_128_CBC_SHA: a cipher suite considered weak by modern standards. Our on-device DPI engine inspected the full TLS handshake in real-time. Based on that assessment and per the deployment’s configuration, it first reported the weak cipher and then blocked the connection. This is exactly the kind of risk that conventional security tools miss entirely.

Why this weak cipher suite is a problem

RSA key exchange provides no perfect forward secrecy: if the server’s private key is ever compromised, all past sessions can be decrypted. CBC mode has been superseded by GCM and is vulnerable to padding oracle attacks. SHA-1 is cryptoglooraphically broken.

What made this particularly interesting: when we ran the server through SSLLabs, the stronger TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 was available. It just wasn’t being prioritised. This is a configuration error, not a fundamental flaw in the bank’s infrastructure. But from a mobile device’s perspective, the outcome is the same.

Cipher suite comparison

✕  What was used

TLS_RSA_WITH_AES_128_CBC_SHA

• RSA key exchange: no perfect forward secrecy
• CBC mode: vulnerable to padding oracle attacks
• SHA-1: cryptographically broken

✓  What should be used

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• ECDHE: perfect forward secrecy by default
• GCM mode: authenticated encryption, no padding issues
• SHA-384: modern and cryptographically sound

Why only on-device DPI catches this

This only became visible because of Corrata’s on-device DPI. We inspect below the IP layer: no VPN tunnel, no proxy, no agent relaying traffic to the cloud. The inspection happens directly on the device, which means we see the actual cipher negotiated between the app and the server, not just metadata about the connection.

Traditional MTD and MDM tools don’t go this deep. They might flag a known malicious domain or detect a rogue Wi-Fi network, but they won’t catch a banking app quietly negotiating a cipher suite that would make any security engineer wince.

In line with our responsible disclosure policy, we contact the affected organisation directly: sharing our findings, the SSLLabs report, and a clear path to remediation. In every case we’ve done this, the fix has been fast.

Mobile endpoints connect to a lot of servers. Not all of them are configured correctly: including ones you’d expect to be locked down. If you can’t inspect what’s being negotiated at the TLS layer, you’re flying blind.

See Corrata’s DPI in action

Run a proof-of-concept on your own device fleet: deployed in 24 hours. Contact us to book a demo.

The post We caught a banking app using a weak cipher suite. Here’s how. appeared first on Corrata.