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 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.

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:

• Mobile endpoint management controls how devices are configured.
• Mobile threat defence detects and blocks attacks.
• 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.

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 what mobile security involves, what mobile threat defence 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 security, and why you need it

Mobile security is the practice of protecting phones and tablets, along with the company data they reach, from attack and loss of data.

It isn’t simply desktop security on a smaller screen, as mobile operating systems are built differently. Apps run inside sandboxes, and neither platform permits the kernel-level access that laptop security tools rely on. What they offer instead is a set of narrow, sanctioned interfaces, and mobile security products are built on those. 

The two platforms differ in how much they allow. Android permits inspection of installed applications, so app scanning is possible there. iOS does not, which is why coverage on Apple devices depends more on network signals and device configuration. 

The exposure is different too. A phone leaves the corporate network constantly. It joins hotel and airport Wi-Fi, moves between mobile networks, and receives messages through channels that no email gateway inspects. Some phones reaching company data are personally owned, which limits what the organisation can reasonably control. The result is an attack surface that is heavily used, lightly monitored, and reachable by anyone.

Phishing is the threat that matters most, and on mobile it arrives through far more doors than email. Links come in by text message, WhatsApp, LinkedIn, Signal, dating apps and voice calls. Small screens make it harder to spot. Addresses are truncated, there is no hover preview, and mobile interfaces are designed to strip away detail rather than show it.

QR codes push this further again. A code on a poster, an invoice or a parking meter takes the attack off the corporate network altogether, because the person scans it with a personal camera app and reaches a page that isn’t being inspected. This is known as quishing.

Apps are another route in. App store review catches a great deal, though not everything, and sideloading bypasses review completely. Legitimate apps create risks of their own when they request more access than they need, or send data to places the organisation would not sanction.

Networks are yet another way. Rogue access points, protocol downgrade attacks, and certificate manipulation all let an attacker read or alter traffic that the user believes is protected.

Then there are unpatched devices. Mobile operating systems receive frequent security updates, but users defer them, and older Android handsets stop receiving them at all, keeping known vulnerabilities open on devices that are still accessing company systems on a daily basis.

Commercial spyware sits at the severe end. Surveillance tooling sold to government customers is used against journalists, campaigners, officials and senior executives. Some of it requires no interaction from the target at all.

Finally, employees now paste company information into consumer AI apps and chat interfaces on their phones. The data leaves without passing any control the organisation owns.

Mobile security software covers a wide range of tools addressing these risks, from consumer antivirus apps through to enterprise platforms. Some of those platforms manage devices. The category built to detect and block the threats above is mobile threat defence.

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 delivers threat detection and response and data loss prevention for mobile endpoints on iOS and Android. It uses deep packet inspection on the device to inspect traffic across all ports and protocols, giving real-time visibility into threats.

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: 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 VMware 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 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.

Last verified 1 September 2026

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.

AI adoption inside businesses has moved faster than almost any technology before it. Staff now use AI tools by default, often through apps on their own phones. The security measures most organisations rely on were built before any of this existed.

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.

Company investing in domain-specific Small Language Model for privacy-compliant mobile threat detection as AI reshapes the attack landscape

DUBLIN and LONDON, 3 June 2026 (Infosec Europe, ExCeL London) ** Updated on 9 June 2026: terminology updated from “on-device LLM” to “domain-specific SLM” to more accurately describe the model in development. — Corrata, the mobile endpoint security company, today announced a comprehensive reimagining of its approach to mobile device security in response to the rapid transformation of the threat landscape by artificial intelligence. The announcement encompasses new AI governance capabilities, enhanced data loss prevention, and a commitment to developing anon-device domain-specific small language model (SLM) for next-generation mobile threat detection.

“The device in your employee’s pocket is simultaneously connected to AI tools, targeted by AI-powered attackers, and operating in an environment where the threat landscape is being rewritten in real time,” said Colm Healy, CEO of Corrata. “The controls deployed two or three years ago were not built for this world. We have rebuilt ours to match it.”

How AI Is Reshaping the Mobile Threat Landscape

Mobile devices sit at the epicentre of three distinct AI-driven risk dimensions that security teams must now contend with simultaneously.

Hyper-personalised social engineering. AI has transformed phishing from a numbers game into targeted precision. Attackers now use large language models to construct lures from publicly available data, producing messages indistinguishable from genuine communications. Research puts the click-through rate on AI-generated phishing at 54%, against 12% for traditional campaigns. On mobile, where 85% of phishing attacks already occur outside email, across SMS, WhatsApp, Teams and other messaging channels, the impact is acute.

AI-accelerated exploits. In May 2026, Google Threat Intelligence Group confirmed a real-world threat actor had used a zero-day exploit developed with AI, planned for mass exploitation and only stopped by proactive counter-discovery. Finding and weaponising vulnerabilities no longer requires deep expertise or months of effort. The median time from disclosure to active exploitation had already fallen from 771 days in 2018 to single-digit hours before frontier AI models entered the picture. Mobile is particularly exposed, where apps are deployed quickly and sometimes outside the review processes that govern traditional software.

Shadow AI and data loss. When employees find that an AI tool makes them more productive, they use it, approved or not. Research suggests 43% of employees share corporate data with LLMs without authorisation. On mobile, where personal and professional boundaries are already blurred, the exposure is acute: sensitive documents uploaded to consumer AI services, client details pasted into chatbots, proprietary code submitted for debugging. Institutional knowledge is leaving organisations at an unprecedented rate, with no visibility and no controls in place.

How Corrata Is Responding

Corrata has always been built on a simple premise: mobile devices deserve the same depth of security monitoring as laptops and servers. Its on-device architecture inspects 100% of network traffic without routing it through a cloud relay, a visibility advantage no competitor has matched. In the AI era, that foundation becomes more important, not less. Corrata has now extended it across three areas.

On-device domain-specific SLM for enhanced threat detection. The vast majority of mobile traffic is now encrypted, and current detection methods will struggle against the more sophisticated social engineering and exploit techniques that AI is enabling. Corrata is developing an on-device domain-specific SLM purpose-built for the mobile environment. A general-purpose LLM cannot run on a phone with the speed, memory footprint and power budget that continuous threat detection requires. By narrowing the model to this single task, Corrata makes it small enough to run on the device itself, in real time, with no data leaving the phone.

AI governance for the mobile workspace. Corrata’s AI Governance capability lets organisations define which AI services and SDKs are sanctioned in the mobile workspace and enforces those policies automatically. Approved tools are unaffected; access to unsanctioned services, including consumer chatbots, AI coding assistants and embedded LLM SDKs in third-party apps, is flagged or blocked. As AI governance frameworks including ISO 42001 and the EU AI Act mature, mobile is the enforcement gap most organisations have yet to close. Corrata closes it.

Precision mobile DLP for the AI age. Data leakage via mobile is no longer confined to lost devices or unencrypted email. AI tools are now a primary exfiltration channel. Corrata’s enhanced data loss prevention uses fine-grained traffic analysis to detect sensitive corporate data being transmitted to external services, whether deliberately or inadvertently, enabling security teams to act on genuine data loss events rather than chase false positives.

“Corrata brings together the deepest visibility into mobile traffic of any solution on the market with a new generation of AI-native capabilities built for the threats that matter most right now,” said Colm Healy.

Availability

Corrata’s AI Governance and enhanced DLP capabilities are available now. The on-device domain-specific SLM is in active development, with availability to be announced.

About Corrata

Corrata is a mobile endpoint security company headquartered in Dublin, Ireland. Its on-device technology delivers comprehensive threat detection and response for iOS and Android devices, combining advanced mobile threat defence with data loss prevention and AI governance. Corrata is a member of the Microsoft Intelligent Security Association (MISA), verified for use with FirstNet, and is accredited as ‘Cybersecurity Made in Europe’ by ECSO. For more information, visit corrata.com.

###

The post Corrata Reimagines Mobile Device Security for the AI Era appeared first on Corrata.

Something significant happened in early 2026. Two iOS exploit kits – Coruna and DarkSword – confirmed what security researchers had long feared: the most sophisticated mobile hacking tools in the world, once the exclusive domain of intelligence agencies and government-approved surveillance vendors, are now in the hands of cybercriminals.

This is not a theoretical risk. These tools have already been used to drain cryptocurrency wallets, steal banking credentials, and compromise the iPhones of ordinary people who simply visited the wrong website. The threat model for mobile security has changed permanently.

Coruna: From Spy Tool to Criminal Weapon in Under a Year

Coruna is an iOS exploit kit of extraordinary sophistication. When Google’s Threat Intelligence Group (GTIG) published their analysis in March 2026, they described a framework containing five complete exploit chains and 23 individual vulnerabilities, covering every iPhone model running iOS 13.0 through iOS 17.2.1 — a range spanning four years of devices. The code is extensively documented in native English, professionally engineered, and incorporates exploitation techniques and mitigation bypasses not previously seen in public research. Researchers estimate that developing something of this scope would cost in the region of $30–40 million. This is not malware written by a criminal gang. It has all the hallmarks of a well-resourced state or state-adjacent programme.

What makes Coruna alarming is not its technical capability alone – it is the speed at which that capability proliferated.

GTIG first detected elements of Coruna in February 2025, in the hands of a commercial surveillance vendor’s customer. By summer 2025 the same JavaScript framework had been embedded as a hidden iFrame on compromised Ukrainian websites, silently delivering exploits to any iPhone user who visited those pages – a watering hole attack attributed to UNC6353, a suspected Russian espionage group. And by the end of 2025 the complete Coruna kit had appeared on hundreds of fake Chinese cryptocurrency exchange websites, used by a financially motivated criminal group (tracked as UNC6691) to steal credentials and drain crypto wallets.

In less than twelve months, a tool built for targeted intelligence collection had become a mass-market criminal weapon.

How Coruna Works

Coruna operates as a watering hole attack. The victim does not need to receive a malicious message or click a suspicious link – they simply need to visit a compromised or fraudulent website on an unpatched iPhone. The exploit kit fingerprints the device, determines its exact model and iOS version, and silently loads the appropriate exploit chain. If it detects that the device is in Lockdown Mode or private browsing, it stops – one of the few effective mitigations available.

After achieving remote code execution in the browser, the kit escalates privileges to the kernel using a chain of additional exploits, then loads an implant called PLASMAGRID. This injects itself into powerd – a system daemon running as root – and downloads modular payloads targeting 18 different cryptocurrency wallet applications including MetaMask, Phantom, Exodus, and Uniswap. It also scans Apple Notes and device images for BIP39 seed phrases and banking keywords, and exfiltrates anything it finds to attacker-controlled servers.

Two of Coruna’s exploit chains reuse vulnerabilities first documented in Operation Triangulation, the sophisticated 2023 iOS espionage campaign. This does not necessarily indicate shared authorship, but it does illustrate how quickly publicly disclosed nation-state techniques migrate into the broader criminal ecosystem.

Who Is at Risk From Coruna?

Coruna is not effective against current versions of iOS. Any iPhone running iOS 17.3 or later is not vulnerable to the known Coruna exploit chains. However, the risk to unpatched devices is real and immediate: researchers estimate tens of thousands of devices may already have been compromised in the criminal campaign alone. If your organisation has any iPhones running iOS 17.2.1 or earlier, those devices should be updated or taken out of service without delay.

DarkSword: A New Chain, More Actors, Greater Reach

Two weeks after the Coruna disclosure, GTIG published a second report – this time on a separate iOS exploit kit called DarkSword, active since at least November 2025 and targeting devices running iOS 18.4 through 18.7.

Where Coruna is a compiled, multi-architecture framework, DarkSword is implemented entirely in JavaScript. This is significant: it means there is no native binary to detect or sandbox, and it makes the chain trivially easy to host, adapt, and reuse. Any threat actor capable of running a web server can deploy it. Within weeks of the kit’s existence becoming known, the exploit code was published to GitHub – at which point it became available to anyone.

DarkSword uses six vulnerabilities across its chain: two JavaScriptCore memory corruption bugs (CVE-2025-31277 and CVE-2025-43529), a zero-day PAC bypass in dyld (CVE-2026-20700, patched only in iOS 26.3), and additional exploits for sandbox escape and kernel privilege escalation. All six have now been patched, but only in iOS 18.7.2, 18.7.3, and 26.1–26.3 respectively. Devices below these versions remain exposed.

Three Actors, One Exploit Kit

GTIG identified DarkSword being used independently by at least three different actors within the space of a few months – a pattern that mirrors Coruna’s proliferation and confirms that a functioning secondary market for advanced iOS exploits now exists.

UNC6748 used a Snapchat-themed phishing site to target iPhone users in Saudi Arabia, deploying a backdoor called GHOSTKNIFE capable of exfiltrating messages, location history, browser data, signed-in accounts, screenshots, and audio recordings.

PARS Defense, a Turkish commercial surveillance vendor, used DarkSword against targets in Turkey and Malaysia, deploying a different backdoor called GHOSTSABER. GHOSTSABER supports arbitrary SQL queries against device databases, recursive file listing and exfiltration, and the ability to execute arbitrary JavaScript code remotely – effectively giving an operator complete programmatic access to the device.

UNC6353 – the same suspected Russian espionage group that used Coruna in Ukrainian watering hole attacks – subsequently incorporated DarkSword into fresh campaigns against compromised Ukrainian websites, this time deploying a dataminer called GHOSTBLADE. GHOSTBLADE harvests iMessage databases, WhatsApp and Telegram data, photos metadata, location history, Safari browsing history and cookies, cryptocurrency wallet data, device keychains, health data, and the full list of installed applications – essentially a complete picture of a person’s digital life.

Who Is at Risk From DarkSword?

Any iPhone running iOS 18.7.1 or earlier, or iOS 26.0 through 26.2, is potentially vulnerable. Given that DarkSword exploit code is now publicly available on GitHub, the risk of further proliferation – including to actors with limited technical capability – is high. Updating to iOS 18.7.3 or iOS 26.3 is the single most important action any organisation can take right now.

The Pattern: A Secondary Market for Nation-State Exploits

Coruna and DarkSword are not isolated incidents. They are evidence of a structural shift in the threat landscape.

Researchers believe Coruna was likely developed by or for a US government contractor – possibly related to L3Harris – before being sold to zero-day brokers and eventually finding its way to Russian state operators and then Chinese criminal groups. DarkSword is believed to have originated in the Gulf region, possibly from a firm that subsequently ceased operations and liquidated its assets onto the secondary market.

In both cases, the pathway is the same: a government-grade tool, developed at enormous cost, leaks into a secondary market where it is acquired by nation-state actors, then by commercial surveillance vendors, and ultimately by financially motivated criminals. The timeline from first use to criminal deployment is now measured in months, not years.

This mirrors what happened with EternalBlue – the NSA-developed exploit that leaked in 2017 and went on to power WannaCry and NotPetya, causing billions of dollars in damage. The difference is that EternalBlue targeted Windows servers. Coruna and DarkSword target the iPhone in your employee’s pocket.

What This Means for Your Organisation

For most organisations, commercial spyware has historically felt like someone else’s problem – a risk for activists, diplomats, and senior politicians, not for businesses. Coruna and DarkSword make that assumption untenable.

The criminal campaigns associated with both kits are financially motivated and indiscriminate. The fake cryptocurrency sites delivering Coruna were not targeted at specific individuals – they were mass-exploitation infrastructure. Any employee with an unpatched iPhone who visited one of those sites was a potential victim. Their device credentials, corporate email access, authentication tokens, and anything else stored on the phone were all in scope.

The implications for enterprise mobile security are significant:

Patch compliance is now a critical security control, not a hygiene task. The window between a patch being issued and an exploit kit being updated to target unpatched devices is shrinking. In the DarkSword case, vulnerability patches and active exploitation were occurring within the same release cycle.

MDM alone provides no protection against this class of attack. Coruna and DarkSword both operate at a layer beneath mobile device management. A successfully compromised device can lie about its own state. Application lists, compliance policies, and certificate checks are all irrelevant once an attacker has kernel-level access.

Network traffic monitoring is the most reliable detection mechanism available. Every implant – PLASMAGRID, GHOSTKNIFE, GHOSTSABER, GHOSTBLADE – must communicate with a command-and-control server to exfiltrate data. That traffic traverses the network and is detectable. Anomalous connections to raw IP addresses, unexpected data volumes from system processes, and traffic to newly registered or low-reputation domains are all signals that network-layer monitoring can surface.

Immediate Actions

1. Update all iPhones to iOS 18.7.3 or iOS 26.3 immediately. Any device below these versions is potentially vulnerable to DarkSword. Any device below iOS 17.3 is also vulnerable to Coruna.
2. Audit your patch compliance posture for mobile. If you do not have visibility into the iOS versions running across your device fleet, establishing that visibility is the first step.
3. Deploy network-level monitoring for mobile devices. If an exploit does succeed, network traffic anomalies are your most reliable signal.
4. Review your incident response procedures for mobile compromise. A suspected iOS exploitation incident has different evidence preservation requirements than a laptop compromise. Make sure your team knows what to do.

Corrata detects spyware-related command-and-control traffic at the network layer, continuously monitoring mobile devices for the anomalous communications patterns that active implants must generate. Learn more about Corrata’s spyware detection capabilities.

The post Coruna and DarkSword: When Nation-State Spyware Goes Criminal appeared first on Corrata.

If that sentence sounds familiar, your organisation has a problem. Not because Signal isn’t secure – it is – but because end-to-end encryption has become the most dangerous security blanket in enterprise IT.

In February 2025, Google’s Threat Intelligence Group revealed that Russian state hackers had successfully compromised Signal accounts without breaking a single line of encryption. In November 2025, CISA issued a national alert warning that threat actors were actively exploiting WhatsApp, Signal, and Telegram to deliver spyware to high-value targets. The attacks work because encryption protects the message. But the device? That’s another story entirely.

Your employees are having sensitive business conversations on messaging apps right now. Here’s why that should worry you – and what the attackers know that you don’t.

The Security Theatre of End-to-End Encryption

End-to-end encryption creates a mathematically secure tunnel between sender and recipient. Messages travelling through this tunnel are, for all practical purposes, unbreakable. This is a genuine security achievement.

But here’s what the marketing doesn’t tell you: encryption protects messages in transit. It does absolutely nothing to secure the devices at either end of that tunnel.

Think about it this way: a message is encrypted the moment it leaves your employee’s phone and decrypted the moment it arrives at the recipient’s phone. Between those two points? Mathematically impenetrable. At those two points? Completely readable – because the message has to be readable for humans to use it.

Modern threat actors don’t attack the encryption. They attack the endpoints. And they’ve developed remarkably sophisticated methods to do it.

Four Ways Attackers Bypass “Secure” Messaging

1. The QR Code Hijack: Real-Time Message Duplication

This is the technique that made Google’s Threat Intelligence team issue an urgent warning in February 2025.

Signal, WhatsApp, and Telegram all allow users to link additional devices to their accounts. You scan a QR code, authorise the connection, and messages synchronise across your phone, tablet, and computer. It’s convenient. It’s also a vulnerability.

Russian threat actors – including the infamous Sandworm group (APT44) – have developed an attack that works like this:

• The attacker creates a malicious QR code disguised as a legitimate Signal group invite, a security alert, or a device pairing instruction
• The victim scans the code, expecting to join a group or confirm a security check
• Instead, the QR code silently links an attacker-controlled device to the victim’s account
• From that moment on, every message the victim sends or receives is delivered to the attacker in real-time

The attack requires no malware. No device compromise. No breaking of encryption. The victim’s phone continues working normally – they have no idea their secure conversations are being duplicated to hostile infrastructure.

Google’s report revealed something even more alarming: Russian forces have used this technique on Signal accounts from devices captured on Ukrainian battlefields, linking them back to intelligence servers for follow-on exploitation. If it works on military targets, it works on corporate targets.

2. Zero-Click Exploits: No Interaction Required

The Landfall campaign, tracked by Google and other security researchers through late 2024 and early 2025, represents a different category of threat entirely.

The attack vector? A malformed image sent via WhatsApp.

The victim doesn’t need to click anything. They don’t need to open the image. They don’t need to do anything at all. Simply receiving the message triggers automatic exploitation of a vulnerability in how Samsung devices process certain image formats.

Once triggered, the Landfall spyware grants attackers access to:

• Real-time location data
• Complete photo libraries
• Call logs and contact lists
• All messages – encrypted or not
• Remote microphone activation

The encryption between sender and recipient remained mathematically intact throughout the attack. It simply didn’t matter – the attacker was reading messages after they’d been decrypted for display on the victim’s screen.

3. Accessibility Abuse: Reading Over Your Shoulder

In November 2025, security researchers at ThreatFabric documented a new Android malware family called Sturnus that takes a deceptively simple approach to bypassing end-to-end encryption.

It doesn’t try to intercept messages in transit. It doesn’t exploit cryptographic vulnerabilities. It simply watches the screen.

Android’s Accessibility Service was designed to help users with disabilities interact with their devices. It allows apps to observe and interact with screen content, read text aloud, and automate actions. Sturnus abuses this service to:

• Read message content directly from the screen after the legitimate app has decrypted it
• Capture full conversations from WhatsApp, Telegram, and Signal in real-time
• Exfiltrate contact information and message metadata
• Harvest banking credentials by watching login screens

The malware distributes itself through social engineering – phishing emails, malicious SMS messages, and fake app downloads. Once installed and granted accessibility permissions (often by users who don’t understand what they’re approving), every “encrypted” conversation becomes visible to the attacker.

4. AI Tool Poisoning: The Invisible Exfiltration

This is perhaps the most concerning development for enterprise security teams.

In April 2025, security researchers at Invariant Labs demonstrated a vulnerability in how AI assistants integrate with messaging platforms. Using a technique called “MCP tool poisoning,” they showed that an attacker can manipulate an AI assistant connected to WhatsApp to:

• Extract the user’s entire message history
• Exfiltrate data to attacker-controlled phone numbers via what appears to be normal messaging
• Bypass traditional DLP systems entirely – because the traffic looks like legitimate AI behaviour

As enterprises increasingly integrate AI tools with communication platforms to boost productivity, they’re inadvertently creating new attack surfaces that most security architectures aren’t designed to detect.

The Enterprise DLP Blindspot

Here’s the uncomfortable truth for security teams: messaging apps exist entirely outside your security perimeter.

Your DLP policies don’t apply. Your monitoring tools have no visibility. Your acceptable use policies have no enforcement mechanism. And the very encryption that’s supposed to protect communications also prevents you from inspecting them for sensitive data.

Meanwhile, a recent study found that approximately 25% of employees share confidential company information through messaging platforms, often without malicious intent. A sales team creates a WhatsApp group to share leads faster. A developer pastes code snippets to get help from a contact. An HR manager sends employee records to the wrong chat.

When that employee’s device is compromised – through any of the techniques above – the attacker gains access to months of conversation history. Customer data. Competitive intelligence. M&A discussions. Strategic plans. All exfiltrated without a single alert from your security stack.

And if that employee leaves for a competitor? They take the entire conversation history with them – on a device you don’t control, through a platform you can’t audit.

What Security Leaders Need to Do Now

The solution isn’t to ban messaging apps – that’s both impractical and ineffective. Employees will find workarounds, driving communication further underground. The solution is to extend your security perimeter to include the mobile device layer.

Immediate actions:

1. Audit linked devices: Require employees to regularly review the “Linked Devices” section in Signal, WhatsApp, and Telegram settings. Any unfamiliar device should be immediately removed.
2. Deploy mobile threat defence: MDM manages device configuration; it doesn’t detect threats. Purpose-built MTD solutions identify malicious apps, suspicious network behaviour, and device compromise indicators in real-time.
3. Establish data classification policies for mobile channels: Define what categories of information can and cannot be shared via messaging apps. Enforce through training and, where possible, technical controls.
4. Treat QR codes as phishing vectors: Train employees to verify any QR code before scanning – especially those purporting to be group invites, security alerts, or device pairing instructions.
5. Monitor accessibility permissions: Any app requesting Accessibility Service access should be scrutinised. Most legitimate apps don’t need it – and granting it to malware gives attackers complete visibility into device activity.

The Bottom Line

End-to-end encryption is a genuine security advancement. But it’s not a security solution – and the industry’s marketing has created a dangerous misconception that “encrypted” means “secure.”

State-sponsored threat actors have already adapted. They don’t attack the encryption; they attack the endpoints. And they’re succeeding – against military targets, government officials, journalists, and increasingly, corporate executives.

Your employees use messaging apps for business communication. That’s not going to change. What can change is whether your security strategy accounts for the reality that those “secure” channels represent one of the largest unprotected attack surfaces in your organisation.

The question isn’t whether your organisation is exposed. The question is whether you’ll see the attack coming.

Corrata provides comprehensive protection for mobile devices, detecting threats that bypass traditional security controls. Our solution identifies malicious network behaviour, dangerous apps, and device compromise indicators in real-time – giving you visibility into the mobile attack surface that messaging encryption hides from view. Contact us to learn how we can help close the mobile DLP gap.

The post The Encryption Illusion: Why Your “Secure” Messaging Apps Aren’t Protecting Your Business Data appeared first on Corrata.