Most security teams have started with discovery, building a list of which AI apps are installed across the fleet. That list is a useful first step, but it can’t tell you which app is acting right now, what it touched, or how to stop it.

This guide covers the risks specific to mobile, how to detect AI agents on iOS and Android, and how to build an audit trail your DPO and auditors can rely on. Later in this guide, we’re also upfront about where mobile visibility ends, so you can plan around it.

What are shadow AI agents?

Shadow AI is usually pictured as an employee pasting a document into an unapproved chatbot, and our earlier post on shadow AI on mobile looked at how much of that AI traffic is already moving across mobile fleets. Shadow AI agents go further: they read, decide, and act across company systems using the employee’s own access, with nobody reviewing each step.

The scale of the wider problem is already clear, and Gartner has predicted that by 2030 more than 40% of global organisations will suffer security and compliance incidents due to the use of unauthorised AI tools, a forecast reported by Infosecurity Magazine.

Agents are the sharpest edge of the broader AI governance challenge, because the risk sits in what the software does once it has access, rather than in whether someone typed a prompt.

Why AI agents are hardest to see on mobile

AI arrives inside ordinary apps

Keyboards, document scanners, transcription tools, and note apps increasingly call model APIs directly. None of them appear as “AI apps” on an inventory, and a silent update can add AI to an app that was harmless last week. A static scan of installed software will miss both.

Agents work at machine speed

An agent can read a mailbox, open a file, and upload it in under two seconds. A weekly usage report finds out after the data has already gone, which leaves security teams investigating incidents they had no chance to prevent.

An app that could act is different from one that is acting

Some tools flag every app with permissions that would let it behave as an agent. On Android, for example, accessibility permissions allow an app to read the screen and drive other apps, which is why apps that over-reach on permissions already carry risk. Flagging capability produces a list of suspects. Security teams need to know which app is acting at this moment, and they need a way to stop it.

Five agentic AI security risks to plan for

The risks below are where general AI agent security guidance meets the realities of a mobile fleet.

• Data leaves for unapproved AI services: An agent can pull email, files, or customer records and send them to a model or storage service your organisation has never assessed, which is the problem mobile data loss prevention is designed to address.
• Agents inherit corporate access: An agent working through an app the employee has signed in to Microsoft 365 can reach whatever mail and files that app has been granted, without IT approving anything new.
• Risk can change with an update: An approved app can start talking to a model after an update, so a one-off review of the app catalogue quickly goes out of date.
• Personal and corporate data mix: On BYOD devices, the same phone carries personal messaging, banking, and work email, which makes broad monitoring both intrusive and hard to justify to employees.
• There is no evidence trail: When an agent acts in seconds and leaves no record of what it touched, incident response, audits, and regulatory questions all start from guesswork.

Why an AI app inventory falls short

Discovery answers the first question security teams ask. Runtime control answers the questions that follow.

How to detect AI agents on iOS and Android

Agents leave a recognisable pattern in network behaviour. They loop rapidly between a model and company services, they act while the screen is off, and they work at a pace no human thumb could manage. Because detection looks at behaviour, it can catch an agent inside an app that was never labelled as AI.

Corrata Agent Shield detects and stops AI agents on mobile by reading that pattern on the device, tying each connection to the app that made it, and scoring every session Human, Assisted, or Autonomous in milliseconds.

To make this concrete, consider an illustrative session on an Android phone in a field sales team (the app and data are fictional). A note-taking app sends a short prompt to a model API, reads 48 KB of mail from Exchange, sends a larger prompt, reads a 1.8 MB file from SharePoint, and then attempts a 2.1 MB upload to unapproved storage. Those five actions take 1.4 seconds with accessibility switched on. Agent Shield scores the session Autonomous, blocks the upload, and pauses the session.

What to do when an agent is active

Blocking all AI rarely holds, because employees find workarounds on personal apps and devices. Proportionate responses keep approved AI useful while closing the routes that put data at risk.

• Copilot and your other sanctioned tools can keep working, while uploads to unapproved AI services are blocked or capped by size, app, and user group through the Corrata Advanced DLP controls that power Agent Shield’s guardrails.
• When an autonomous session reaches for email, files, or finance apps, Corrata can pause it and ask the employee on their phone whether it was them. One tap lets the session continue, and without that tap no data moves.
• A device running an unapproved agent can be marked non-compliant in Microsoft Intune, so conditional access cuts Microsoft 365 until the issue is resolved, without adding another console for your team to learn.

Building an AI agent audit trail

Every autonomous session in Agent Shield produces an Agent Receipt, a timeline showing which app acted, which AI service it used, which company systems it touched, how much data moved, and what action Corrata took.

Receipts can flow to your SIEM and to Intune, so they sit alongside the rest of your security evidence. For compliance teams, that record supports conversations with auditors, your DPO, and evidence gathering for the EU AI Act.

Governing AI agents without reading employees’ messages

Agent Shield works on metadata, analysed on the device. It knows an agent moved 2 MB to an unapproved service, and it has no view of what those 2 MB contained. There are no certificates to install, no TLS interception, and no broken certificate pinning, and only verdicts and receipts reach the console.

This approach, which we describe in more detail in our page on privacy by architecture, is built for works council and DPO review. It is BYOD friendly, personal app traffic can be excluded by policy, and Corrata is ISO 27001 certified and EU native, so your AI governance data stays in the EU.

What no mobile security tool can see

No tool has total AI visibility on mobile. AI that runs entirely on the device sends no traffic, the iOS sandbox stops any third party watching one app drive another, platform assistants such as Siri and Gemini run partly on Apple and Google infrastructure, and cloud agents in a remote browser never touch the phone. The Agent Shield page sets out where its visibility ends and how to plan around each gap.

Five steps to bring AI agents on mobile under control

1. Agree which AI tools are approved, and give employees a sanctioned route to use them so they have less reason to look elsewhere.
2. Identify every app on your fleet that communicates with a model, including AI added to ordinary apps through updates.
3. Monitor sessions for agent behaviour, since an installed app tells you far less than what that app is doing.
4. Set proportionate responses that range from asking the user to blocking uploads and cutting Microsoft 365 access.
5. Keep a receipt for every autonomous session, and explain to employees what you can and can’t see, which is central to employee buy-in on BYOD devices.

See it catch a live agent

The quickest way to judge any AI agent security claim is to watch it work. Book a demo and we’ll run an AI agent on a test phone while you watch Agent Shield detect it, score the session, and produce the receipt.

The post Agentic AI security risks on employee phones appeared first on Corrata.

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

What is the difference between MDM and MTD?

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

What MDM does

MDM is the tool IT uses to enrol, configure, and control a fleet of devices. Most MDM products have grown into unified endpoint management (UEM) platforms, such as Microsoft Intune and Omnissa Workspace ONE, which manage phones alongside laptops. Typical MDM tasks include enforcing a passcode and encryption, setting a minimum OS version, deploying and updating apps, pushing Wi-Fi, VPN, and email settings, separating work and personal data, and locking or wiping a device that is lost or belongs to someone who has left. On personal devices, that wipe is usually a selective wipe that removes only company data.

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

What MTD does

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

This post is for IT and security teams comparing Corrata vs Zimperium, or looking for a Zimperium alternative. The useful question is not which product has more features. It is where each product gets its information from, and what that means for the risks you care about. Every claim below, for both products, links to the vendor’s own product page.

What we compared, and what we did not

This comparison covers Zimperium Mobile Threat Defense (MTD) and Corrata Mobile Threat Defence Software. Zimperium’s Mobile Application Protection Suite (MAPS) is out of scope, as it protects apps a company publishes, not employee devices. The Mobile SOC Agent and Advanced Remote Security Diagnostics are included, though Zimperium sells both as paid additions to MTD.

Both products deploy through MDM and integrate with identity, SIEM, EDR and XDR platforms.

Corrata vs Zimperium: the short version

The short answer

Zimperium Mobile Threat Defense builds its picture from the device: OS state, app behaviour, app binaries and network safety. It runs on iOS, Android and ChromeOS, with cloud, on-premises, air-gapped and FedRAMP deployment, and an optional AI agent for incident triage.

Corrata builds its picture from the traffic: what the device sends, across all ports and key protocols, inspected on the device. It runs on iOS and Android, is EU-based, and never reads an employee’s messages or files.

If you need Chromebooks, on-premises or air-gapped deployment, or FedRAMP, Zimperium has those. If your questions are about AI and SaaS traffic, encryption quality, packet-level evidence or European data governance, Corrata is the fit.

Anyone weighing a Zimperium alternative should start with where each product gets its picture of the device from.

Zimperium gets its picture from the device. It watches what the OS is running, how apps behave, what is in the app binary, and whether a network is unsafe. That is why its app vetting and device checks are as broad as they are, and why it runs on ChromeOS and in air-gapped environments.

Corrata gets its picture from the traffic. Its patented on-device traffic inspection watches what the device sends, across all ports and key protocols, at the network level rather than the app level. That is why control does not depend on DNS visibility, why individual domains, servers, ports and IP ranges can be blocked, and why policy can target a single service rather than an app or a category.

Neither approach covers everything the other does. That is why several rows are draws. Here is how it plays out across six areas.

Phishing that arrives outside the browser

Most mobile phishing no longer arrives by email. It arrives by SMS, WhatsApp, iMessage, a QR code or a search result. Both products detect across those channels on the device, not at an email gateway.

Zimperium’s Mobile Phishing Protection claims detection of known and zero-day phishing across email, SMS, QR codes and in-app messaging, on iOS, Android and Chromebook.

Corrata’s Mobile Phishing Protection inspects traffic on the device in real time. Zero Day Protection blocks destinations with no reputation history rather than waiting for one to build. Phishing sites often live for only a few hours, which is where reputation checks struggle. We would rather block an unknown destination briefly than let it through while it is classified.

Data leaving the device, including AI chatbots

This is the fastest-growing gap. Staff paste company data into whichever AI assistant is open, and on mobile most security teams cannot see it. Both products address it. The difference is where control sits.

Zimperium controls it at the app. Its app vetting identifies AI SDKs, permissions and data flows, applies AI-specific web content filtering, and uses a policy engine to mark apps non-compliant and restrict access. Zimperium also says policy can cover where apps communicate geographically and support data sovereignty requirements. If your question is “which installed apps contain AI, and what can they access”, that is what the app-side model answers.

Corrata controls it at the traffic. Shadow AI and DLP controls access to unsanctioned AI and SaaS, monitors file uploads to unsanctioned LLMs, email and file-sharing services, and lets you allow, report, block, or monitor individual SaaS services.

A sanctioned service stays available while an unsanctioned one is blocked, whichever app sent the traffic. That includes a chatbot opened in a browser tab, which an app-level control sees only as browser traffic. Corrata’s own detection data found AI traffic on 84% of customer fleets over six weeks, growing about 40% a month, with 69% of AI domains never seen before.

Spyware, forensics and containment

Mercenary spyware is a niche concern for most organisations and a serious one for a few: legal, journalism, public sector, anyone of interest to a nation state. Dealing with it needs continuous visibility, a way to collect evidence from a suspect handset, and a way to contain the device quickly.

Both products monitor continuously, in different ways. Zimperium detects on-device exploits and device compromise, and lists on-device forensic analysis for threat hunting. The signal comes from the device and its apps. Corrata’s spyware protection constantly monitors device settings and network activity, across all ports and key protocols. The signal comes from what the device sends. A compromise that leaves no trace on the device, or hides inside a legitimate app, still shows up in its traffic.

For evidence, Zimperium offers a user-run forensic scan, footnoted as iOS only at this time, and a paid feature called Advanced Remote Security Diagnostics that collects Android security logs every 24 hours and guides users to upload Android bug reports and iOS system diagnostics. Packet capture is not listed. Corrata lets users can send diagnostics to admin to collect and analyse, including network packet captures. A packet capture shows whether a suspected implant is actively communicating, where to, and over what.

For containment, Zimperium disconnects on network threat detection and runs broader response through the MDM, UEM or identity integration. How precise that response is depends on the integration in place. Corrata automatically quarantines the device from sensitive systems while analysts review the data, with remediation applied automatically and no UEM policy needed.

Is the device talking to the right server, and can anyone else see it?

Zimperium states that MTD detects unsafe and rogue networks, warns on attempts to connect, and identifies malicious networks nearby. App vetting separately flags apps that use insecure communication.

Corrata approaches the same problem from a different starting point. The network a device joins is only the first link in a chain that runs through carriers, exchanges, and intermediaries before it reaches the server. A mobile network can be compromised, or can cooperate with a state actor. A hotel Wi-Fi can be clean while the connection beyond it is not. Weak cipher suites, outdated TLS versions, and apps sending sensitive data over encryption that should not be trusted happen on perfectly legitimate networks. On that view there is no such thing as a safe network, only connections that are protected end to end and connections that are not.

So rather than asking whether the network is trustworthy, Corrata checks whether each connection is: that the device is talking to the server it intends to, and that nobody in between can read or interfere with the traffic. Adversary-in-the-Middle Protection inspects the TLS handshake on the device and reports weak cipher suites, on every connection, on every network, with blocking as an administrator policy choice.

Employee privacy and permissions

Zimperium states that privacy settings are granular across Location, Application, Network and Device data, that a BYOD policy group can be set so information never leaves the device, and that users can adjust what the app transmits. Personal email, documents, contacts, calendar, passwords, pictures and videos are never collected, and the GDPR right to be forgotten is supported.

The practical difference is that Zimperium’s privacy outcome is a configuration. Location is a collectable category, and what a fleet transmits depends on how the admin and the user have set the policy. That suits mixed fleets. It also means the answer to “what does this agent see” depends on policy, not architecture.

Corrata does not read messages, scan files, record browsing history or require sensitive permissions. It sees connection metadata: domain and server names, IP addresses, ports, certificate metadata, app hashes and permissions. That is domain-level metadata, not full URLs, page content or search terms. Corrata explains the difference to staff as part of employee buy-in.

Headquarters, GDPR and deployment

Zimperium is headquartered in Dallas, Texas. Its MTD page lists cloud, on-premises, air-gapped and FedRAMP deployment. No EU hosting region is named on the product pages or solution briefs, so a European buyer should ask where their tenant would sit and what transfer mechanism applies.

Corrata is a European cybersecurity company headquartered in Dublin, ISO 27001 certified. Its on-device design is built to make compliance with strict data protection standards straightforward. For UK and Irish public-sector and financial-services buyers, a European processor under GDPR removes a step from procurement. 

Deployment is a draw. Zimperium offers zero-touch deployment and MDM, EMM and UEM integration. Corrata offers zero-touch deployment for managed and unmanaged devices, Intune and Workspace ONE integration, and email or SMS enrolment for BYOD or organisations without MDM.

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 how you detect and report incidents. Mobile is usually the part of the estate with the least to show, and DORA’s reporting deadlines are short.

Zimperium covers a good deal of this. Devices report into a console, alerts feed your SIEM, posture feeds conditional access, and the Mobile SOC Agent can produce an incident narrative for your reporting process. For regulated EU organisations, the open questions are where that data is processed and whether you can reconstruct what left a handset.

Corrata covers the same ground from the traffic side: control over data going to unsanctioned services including AI, device diagnostics, packet capture and quarantine for a suspect device, from a European processor, integrating with SEIM and your identity provider.

Corrata as a Zimperium alternative: which one do you need?

Zimperium Mobile Threat Defense is a credible choice, and this comparison is not an argument against it. 

Choose Corrata if:

• EU data governance is a priority and you want a European vendor
• You want one platform that scales from an SME fleet of up to 250 devices to a large enterprise estate, with the same level of protection at every size
• You need to see and control which AI and SaaS services the fleet uses, including from a browser
• You want spyware detection based on what the device sends, with packet captures from a suspect device as evidence
• You have a BYOD environment where “the agent cannot read messages or files, under any configuration” is the answer you need to give

Choose Zimperium if:

• You have a SOC or MSSP and want an AI agent that investigates and triages mobile incidents for them
• You want deep run-time analysis of individual apps, including which AI SDKs they embed
• You want automated collection of Android security logs across the fleet without user involvement
• You want privacy settings you can tune per device group, including what location and personal data is collected

Whichever list you recognise, a purpose-built mobile threat defence layer is what answers it. The category is also written as mobile threat defense.

Book a demo to see what Corrata finds on a handful of your own devices.

The post Corrata and Zimperium Mobile Threat Defense: How they compare on mobile appeared first on Corrata.

This is the new tactic that is employed by attackers.

Recruitment scams have always been around but now with the difficulty rising in the job market and job hunt, many people would do anything that would lead them closer into landing a job. This new scam is employed by malicious actors, where they mimic the Indeed job platform. The victims often are reached out to by the bad actors in the form of SMS messages, asking them to download an app called IndeedInterview to attend the interview or schedule it for a later date. 

Once installed on the device, the malware works to steal the credentials of your accounts. Even if the app is not installed on the device, just the mere act of clicking on the link is enough to let the bad actors know that this device / user / number is prone to clicking any links that come through the SMS. This campaign was active in the Middle East, but there are chances that they are employing these tactics in different regions of the world.

It is particularly targeted at mobile devices, since if a person were to access the website on their desktop it would navigate or prompt them to open the website on their phone. 

The application is not active at the moment, however the domain that was used in this campaign is still active. It has not changed the way it operates, however we have observed on certain networks that it does change the way it operates.

When the website is accessed on the desktop, it displays a QR code, asking the user to scan the code which opens the phishing website on the device, and in some cases it displays a fake job listing for a remote job in Canada with an option to email the “recruiters” with information about the CV.

Following this, it is likely that they would ask the users to download an application attached with the email or scan a QR code which will lead the user to a page where they can download the malware onto the device. 

We performed our own investigation into this based on the report from MalwareBytes.

Workflow of the attack

Date tested: Sep 25, 2026
Devices used: Samsung A15, Samsung Galaxy Z Flip
Android version: Android 16

Below is a screen recording of the workflow.

Technical Details 

There were many interesting things that were found through deeper investigation of this malware. Like any malware of recent times, it installs an innocuous file, following which a dropper is installed on the device. This is the main malicious payload that causes harm. 

The malware APK is completely obfuscated with an encryption making it difficult for it to be analysed through traditional tools like Android Studio. When we accessed the link, we were able to download multiple files of the malware. Each version of the malware that was downloaded onto the device, had a different hash value, different package name, and in some cases, even the icon colour of the malware was different. 

The attackers made use of an interesting technique called server side polymorphism. This means that whenever a victim tries to download malware onto the device, the code is rearranged internally on the server side, as well as changes the package name of the malware. 

This is used to evade detection as multiple services traditionally check for the SHA256 Hash values and packages name, which are not changed. This is also why Play Protect and many third party vendors were able to detect only one version of the malware when it was reported. 

At the time of our investigation, Play Protect was not able to detect the presence of the different versions of the malware. 

On the analysis of the APK file, we were also able to find the various possible package names as well as function names, to avoid easy analysis, and identification of each function present in the code. The malware asks for extensive permissions along with accessibility services permission. However this accessibility permission is specifically for the Dropper. 

Although the functionality of the malware is the same, which behaves like a spyware and exfiltrates the data from the device, the permissions that each version of the malware APK require is different. This is possibly done to evade detection as much as possible, as it would change the file size and hash value significantly.

An XML file called deviceStreaming.xml was found to have a list of devices, manufactures and models. The purpose of this file is that when a particular model / device is detected then the data exfiltration can happen. This potentially leads us to believe that this piece of malicious software has spyware capabilities.

We were also able to detect the possible versions of the package names and functions that could be employed by the malware. This was identified as they were not being in any location inside the file or calling any function. An extensive list of words consisting of jumbled up letters was found. For each version of the malware that was downloaded the list of words changes.

When the innocuous looking file is installed on the device, it asks you to log in, set up a VPN connection, and then update the app. The reason for the VPN connection is that all the traffic goes through the attackers VPN service with nothing to interfere with it. 

The dropper named “Updater” is then installed on the device. We observed that if dropper is not installed correctly or not given the necessary permissions, it is incredibly persistent. With unnecessary notifications as well as the vibrate effect on the device, it would annoy the victim into granting the permissions it is asking for. Both the devices that we completed the tests on were part of the list. 

Once this act is done, the phone performs a temporary update, and all the permissions are granted to the malware. This will be completely hidden from the main screen and it can be seen only in the Settings under Apps. It is very difficult to remove, for if you try to access the application, it immediately closes the screens. 

The malware is also quite clever, if it detects an emulator, the innocuous app completely crashes and does not run on the device. 

How to spot and avoid fake interview apps

• Whenever you have to install an app for an interview, double check if it is from a legitimate source such as Play Store, and confirm that the person who sent it to you is legitimate company. 
• We have noticed an increase in malwares asking for VPN connection, to evade detection and sending data safely to the C2 servers. 
• Applications downloaded from any source asking for accessibility permission should be proceeded with caution. 

Indicators of Compromise 

• Startcareer[.]org
• Api[.]flowerscantdie[.]com
• Drive-interview[.]cloud
• Api[.]interviewtoday[.]info

Currently all these domains are active, and should be dealt with caution.

About Corrata

Corrata provides mobile threat defence for iOS and Android, including protection against apps that over-reach on permissions or come from outside the official stores. 

See how Corrata approaches spyware detection on employee devices.

The post How a fake Indeed interview app hides spyware on Android phones appeared first on Corrata.

Malware is any software written to damage, disrupt or gain unauthorised access to a device or the data on it. The main types are viruses, worms, trojans, ransomware, spyware, mercenary spyware, adware, keyloggers, rootkits, backdoors, botnet malware, infostealers, banking trojans, cryptojacking malware, and fileless malware. They differ in how they spread, what they take and how visible they are once installed.

Most guides to malware describe a world of desktops and servers. That world has changed. Google’s Android security team reported that Play Protect identified more than 27 million new malicious apps from outside Google Play during 2025, up from 13 million the year before, and blocked 266 million risky sideloading attempts through its enhanced fraud protection, which now covers more than 2.8 billion devices across 185 markets.

The phone in an employee’s pocket is a primary target rather than an afterthought. Verizon’s 2026 breach report found the success rate of mobile social engineering up 40% year on year, with mobile named among the fastest-growing targets.

How many different types of malware are there?

Malware is classified by behaviour rather than by a formal standard, so published lists range from about seven categories to thirty. Most settle on around 15 core types, with newer families such as infostealers and mercenary spyware treated as distinct categories only in recent years.

Real samples combine behaviours: a single dropper delivered through a messaging app may install a banking trojan that also works as a keylogger and a botnet client.

The 15 types of malware at a glance

1. Viruses

A virus attaches itself to a legitimate file or program and spreads when that host is executed, so it needs a user to run something for the infection to progress. The term is often used loosely to mean all malware, but true viruses are now a small share of what security teams encounter. On phones, application sandboxing makes classic viral spread between apps impractical.

2. Worms

A worm copies itself across networks without user action, usually by exploiting a vulnerability in an exposed service. Worms cause some of the fastest-spreading incidents on record because propagation is automatic. They matter mainly on corporate networks and unpatched servers rather than on managed mobile fleets.

3. Trojans

A trojan presents itself as something useful, then delivers a hidden payload once installed. This is the dominant model in mobile malware. Attackers often use a two-stage approach, publishing a clean-looking utility that later fetches the real payload, which is one reason installing apps from outside the official stores carries a different level of risk. Kaspersky’s researchers described that pattern in the second quarter of 2026, when a trojanised PDF reader hosted on Google Play showed users a fake update request in order to drop the Anatsa banking malware.

4. Ransomware

Ransomware encrypts files or locks a device and demands payment for restoration. Most operators now steal data before encrypting so they can extort victims a second time by threatening publication. Verizon’s 2026 Data Breach Investigations Report, which analysed more than 22,000 confirmed breaches across 145 countries, found that 73% of ransomware victims had an associated infostealer infection or credential leak in the year before the attack, and that the median ransom payment fell to around $140,000 with 69% of victims declining to pay. Mobile ransomware remains rare by comparison: Kaspersky counted 570 mobile ransomware installation packages in a quarter that produced more than 304,000 malicious packages in total.

5. Spyware and stalkerware

Spyware monitors activity and exfiltrates what it finds, including messages, location, contacts and microphone audio. Stalkerware is the commercial variant, marketed as parental or employee monitoring and installed by someone with physical access to the device. Both are difficult to detect from the handset itself because they are built to leave no visible trace.

6. Mercenary spyware

Mercenary spyware is a separate class of surveillance implant developed by private vendors and sold to government buyers, and infection often requires no interaction from the target. Apple describes these attacks as vastly more sophisticated than ordinary cybercriminal activity and operates a threat notification system to warn individuals it believes have been targeted, sending a further round of alerts to users across 110 countries in August 2026. Citizen Lab researchers have forensically confirmed cases of journalists compromised by Paragon’s Graphite spyware, including one device attacked through a zero-click iMessage exploit.

Executives, legal teams and anyone handling sensitive negotiations sit closer to this threat than they tend to assume. The delivery methods have shifted over time, from zero-click messaging chains towards web-based exploitation, which we cover in our breakdown of Pegasus and the spyware families that followed it.

7. Adware

Adware injects advertising, redirects browsing and tracks behaviour for resale. It is treated as a nuisance rather than a breach, which is why it persists. The practical harm is data leakage, since adware SDKs bundled into free apps can send device identifiers, location and usage data to parties the organisation has no contract with.

8. Keyloggers

A keylogger records what the user types and returns it to an attacker, which is the simplest route to usable credentials. The mobile equivalent is abuse of accessibility permissions, which allow an app to read screen content and input across other applications. An app that requests accessibility access without an obvious reason should be treated as hostile, and the same applies to the other Android permissions malware relies on, including notification listener access and device admin rights.

9. Rootkits and bootkits

A rootkit modifies the operating system to conceal an attacker’s presence and survive normal clean-up, and a bootkit goes lower still by loading before the operating system does. Both are expensive to build and appear mainly in targeted intrusions. Stock iOS and Android devices resist them, though jailbroken or rooted handsets lose that protection.

10. Backdoors and remote access trojans

A backdoor creates a hidden entry point for future access. A remote access trojan gives an attacker interactive control, including reading files, capturing the screen and switching on the camera or microphone. On mobile they usually arrive inside apps installed outside the official stores, often after a call or message that persuades the user to bypass a security warning, and once installed a remote access trojan inherits every privilege the employee has.

11. Botnet malware

Botnet malware enrols the device into a network of compromised machines directed from a central server. Infected devices are then used for distributed denial of service attacks, credential stuffing, ad fraud or residential proxy services. Handsets are attractive for this because their traffic looks like ordinary consumer activity.

12. Infostealers

Infostealers harvest saved credentials, session cookies, authentication tokens and cryptocurrency wallets in a single pass, then exit. Because they capture live session tokens, they can defeat multi-factor authentication by bypassing the login step entirely. Stolen data is sold on in bulk, which is why an infostealer infection on one device often precedes an apparently unrelated intrusion months later. Kaspersky’s Q1 2026 reporting described a new version of the SparkCat crypto stealer found in apps on both Google Play and the App Store, with the iOS build using Apple’s Vision framework to read text from images held on the device.

13. Banking trojans and overlay malware

Banking trojans wait for a banking or payment app to open, then draw a convincing fake login screen over the top and capture the credentials entered. They are the largest category of mobile malware by volume. In the second quarter of 2026, Kaspersky found that Trojan-Banker samples accounted for 30.77% of detected malicious applications, with 93,574 mobile banking trojan installation packages identified in that quarter alone. The same overlay technique works against corporate single sign-on screens, which is why app risk on employee devices is a credential problem rather than a device hygiene problem.

14. Cryptojacking malware

Cryptojacking malware uses the device’s processor to mine cryptocurrency for someone else. There is no data theft, so it often runs undetected for long periods. On a phone the symptoms are heat, battery drain and throttled performance, which users tend to attribute to an ageing handset.

15. Fileless malware

Fileless malware never writes an executable to disk. It runs in memory and abuses tools already present on the system, such as scripting engines and administrative utilities, which allows it to pass signature-based detection. Defending against it depends on behavioural monitoring rather than file scanning.

Other categories worth knowing

Several further terms appear in malware taxonomies without forming large categories in their own right. Wipers destroy data outright and are used for sabotage rather than extortion. Scareware produces fake infection warnings to sell worthless software. Logic bombs stay dormant until a condition is met. Toll fraud malware silently signs mobile users up to premium-rate services. Droppers and loaders exist only to install something else, which is how an app that passed review can turn malicious later.

What are the dangers of the different types of malware?

Grouped by outcome rather than by family, the damage falls into five categories.

• Financial loss: Ransom payments, fraudulent transactions enabled by banking trojans, and premium-rate charges from toll fraud.
• Data loss and regulatory exposure: Infostealers and spyware remove personal and commercial data. Under GDPR, a notifiable breach brings supervisory authority involvement and potential fines regardless of how the data left.
• Operational disruption: Ransomware and wipers stop the business functioning. The cost sits in downtime and recovery rather than in the ransom itself, and organisations that have never tested whether they can operate with key systems offline tend to discover the answer during the incident.
• Loss of access control: Backdoors, keyloggers and infostealers hand over credentials and session tokens, turning one infected device into a route into every connected system.
• Surveillance: Spyware and mercenary spyware expose negotiations, legal strategy, client information and the movements of named individuals.

What are the different types of malware attacks?

The malware family describes what runs on the device. The attack describes how it arrives.

• Phishing and smishing: A message from a bank, courier or internal service prompting the user to install something or enter credentials. On mobile this arrives through SMS, WhatsApp, LinkedIn and QR codes as readily as through email, and most mobile phishing now lands outside the inbox entirely.
• Sideloading under social engineering: The attacker talks the user through installing an app from outside the store and dismissing the warnings. Google now blocks Play Protect from being switched off during an active phone call because criminals impersonating bank staff walk victims through that step.
• Malicious apps in official stores: Review processes catch most submissions, but dropper apps that fetch their payload after approval still get through.
• Exploitation of unpatched vulnerabilities: Devices running old operating system versions are compromised with no user action at all.
• Malvertising and drive-by downloads: Compromised ad networks deliver payloads to users who only visited a legitimate site, and the same evasion logic drives phishing hidden inside QR codes, where the link is an image that text-based scanning never reads.
• Supply chain compromise: A trusted software component or SDK is modified upstream, so malicious code arrives inside something the organisation chose to install.

Reducing the risk across devices

A layered approach works better than any single control:

• Keep operating systems and applications up to date, since a large share of serious incidents trace back to a small number of known vulnerabilities.
• Restrict installation sources on corporate devices and treat any request to bypass a security warning as a red flag.
• Review app permissions, with particular attention to accessibility services, notification access and device administrator rights.
• Enforce multi-factor authentication alongside controls that detect stolen session tokens, since infostealers are designed to skip the login prompt.
• Maintain offline, tested backups so ransomware becomes a recovery exercise rather than a negotiation.

The gap on mobile

The controls above assume you can see what is happening on the device. On phones that assumption usually fails. Application sandboxing prevents security software from scanning other apps, mobile device management reports configuration state rather than behaviour, and on personally owned devices the work profile deliberately hides the personal side from the organisation.

Attackers work inside that gap, which is covered in our guide to why mobile malware is hard to detect on employee phones and the practical steps in how to improve mobile malware detection on work phones. For a view of how the vendors in this space compare, see our guide to mobile threat defence software.

Corrata provides mobile threat defence for iOS and Android. See how detection and response works on employee devices.

The post 15 Different Types of Malware and What They Do appeared first on Corrata.

This guide covers why that gap exists and what to do about it, in the order the work should be tackled.

Why mobile malware is hard to detect

The sandbox prevents scanning

On iOS and Android, applications run in isolation and cannot read the files or memory of other applications. That design blocks most malware from spreading between apps, and it also blocks security software from doing what antivirus does on a laptop. No third-party app can scan the contents of another app, inspect the filesystem or watch processes it does not own. The desktop model of on-access file scanning has no equivalent on mobile.

MDM answers a different question

Mobile device management was built to configure devices and enforce policy rather than to detect threats. It will tell you which devices are enrolled, which operating system versions they run, whether a passcode is set and which managed apps are installed. It will not tell you that an installed app is exfiltrating contacts, that a user has just authenticated on a credential harvesting page, or that a device is talking to a command and control server. Knowing an app is present is not the same as knowing what it does.

The BYOD privacy boundary is deliberate

On personally owned devices the work profile exists specifically to keep the organisation out of the personal side. Google states plainly that the separation of work and personal apps means IT gets full control over work apps and data with no visibility into personal apps.

That boundary is correct for privacy and costly for detection, and the cost is measurable in timing. Verizon’s 2026 Data Breach Investigations Report found that among ransomware victims who had a prior credential or infostealer event, half saw that event occur within 95 days of the ransomware attack.

There is usually a window of weeks or months between the theft and the consequence, and whether anyone notices depends on being able to see the device where the credentials were taken. Attackers are not constrained by the boundary the organisation agreed to respect, so a phishing message arriving through personal WhatsApp can harvest corporate credentials that work perfectly well against corporate systems.

Attacks arrive through unmonitored channels

Email security gateways see corporate email. They do not see SMS, WhatsApp, Signal, LinkedIn messages, QR codes scanned from a poster, or links opened in a personal browser. On mobile those channels carry a large share of credential phishing, and most of it now lands outside the inbox entirely. The small screen hides the signals users are trained to look for, including the full URL and the sender’s real address.

Attackers have noticed that this works. Verizon’s 2026 report recorded a 40% rise in the success rate of mobile social engineering year on year, naming mobile devices among the fastest-growing targets. The same evasion logic drives phishing hidden inside QR codes, where the destination is an image that text-based scanning never reads. Phones also spend most of their time on mobile data or home wifi, so network controls sitting in the office never inspect that traffic.

Malware is built to survive app review

Attackers assume the store review process exists and design around it. A common pattern is a clean utility app that fetches its payload only after approval. Kaspersky’s researchers documented this in the second quarter of 2026, when a trojanised PDF reader distributed through Google Play showed users a fake update prompt in order to install the Anatsa banking malware.

Attackers also hide what the code does. The SparkCat crypto stealer, found in apps on both Google Play and the App Store, kept its malicious component encrypted so that nothing suspicious was visible to anyone reviewing it. Once running on an iPhone, it read text out of photos stored on the device, looking for saved recovery phrases.

Overlay attacks draw a fake login screen on top of a real banking or single sign-on app, leaving nothing on disk to find. Accessibility service abuse gives an app the ability to read screen content and simulate input, using one of several Android permissions that have entirely legitimate uses alongside their malicious ones. Volume compounds all of it: Google reported that Play Protect identified more than 27 million new malicious apps from outside Google Play in 2025, more than double the 13 million the year before, which is a large part of why installing apps from outside the official stores carries a different level of risk.

Users have no symptoms to report

On a laptop, an infection usually produces something the user notices. On a phone, the signs are heat, battery drain and slower performance, which people attribute to an ageing handset. Spyware is designed to produce no signs at all. Apple’s threat notification programme exists because mercenary spyware attacks are difficult to detect and prevent even for the platform vendor, with infection often requiring no interaction from the target.

How to improve malware detection for mobile

Step 1: Establish what you can currently see

Start with an honest inventory rather than a tooling decision. For each group of devices, record who owns it, whether it is enrolled, what data it can reach, and what your existing tools actually report. Separate four questions: which apps are installed, what those apps are doing, what the device is connecting to, and what the user is being sent. Most teams can answer the first and none of the rest. That gap is the scope of the work.

Step 2: Set the privacy boundary before you deploy anything

On personally owned devices, detection succeeds or fails on consent. Decide and document what will be monitored, what will not, who can see the data, and how long it is retained. Under GDPR this needs a lawful basis and, in most cases, a data protection impact assessment. Write it in language employees can read, and be specific about the personal side of the device. A programme that collects less and is trusted will get better coverage than one that collects more and gets resisted.

Step 3: Fix the configuration baseline

Detection is cheaper when there is less to detect. Set a minimum operating system version and enforce it through conditional access rather than through reminders. Restrict installation sources on corporate-owned devices. Ensure Google Play Protect stays enabled, which matters because Google’s enhanced fraud protection blocked 266 million risky sideloading attempts in 2025. Block enrolment of jailbroken or rooted devices, since those lose the platform protections the rest of your controls assume.

Step 4: Monitor the device’s network traffic

Since the platform prevents third-party software from scanning other apps, the practical detection surface on mobile is the connection rather than the file. Network traffic inspection performed on the device catches what file scanning cannot: connections to command and control infrastructure, credential harvesting pages opened from any app, and data leaving for destinations it should not reach. It works regardless of whether the phone is on the office network, home wifi or mobile data. This is the largest capability gap between a managed mobile estate and a monitored one.

Step 5: Watch permissions and behaviour, not just app names

Build alerting around the permissions malware needs in order to function:

• Accessibility services, which allow an app to read screen content and simulate input.
• Notification listener access, which lets an app read one-time passcodes as they arrive.
• Device administrator rights requested by an app with no management purpose.
• Draw over other apps, used for overlay attacks against banking and single sign-on screens.
• Installation from unknown sources, including any change to that setting.

Treat a request for any of these from an app outside your approved catalogue as an incident rather than a support ticket.

Step 6: Extend phishing detection to every channel

Most mobile compromise starts with a message rather than an app, so detection needs to cover SMS, messaging apps, QR codes, personal browsers and social platforms. Two behaviours deserve specific alerting: a user being walked through disabling a security control, and a user being talked into installing an app during a phone call. Google considered the second pattern common enough that Play Protect now cannot be switched off while a call is in progress.

Step 7: Route mobile alerts into the same queue as everything else

A mobile detection tool that emails a dashboard link to one administrator is not detection. Feed alerts into the SIEM, map them to your existing severity model, and name the team that owns triage. Define in advance what a confirmed mobile compromise triggers in your identity stack, because the credentials and session tokens taken from a phone are used against systems that have nothing to do with mobile.

Step 8: Write and rehearse the response playbook

Decide these points before you need them:

• How a device is isolated from corporate resources, and who authorises it.
• How sessions and tokens are revoked, given that infostealers capture live session tokens and bypass the login step.
• What evidence is preserved before any wipe, and whether a selective wipe destroys what you would need.
• How a BYOD device is handled when the organisation has no right to wipe the personal side.
• What happens when an employee receives an Apple threat notification, which warrants specialist help rather than a routine device reset.

Run the scenario at least once. The first time a team discovers it cannot revoke a session on a phone it does not own should not be during an incident.

Measuring whether it is working

Track a small set of numbers monthly: percentage of devices with work access covered by detection rather than just enrolled, percentage running a current operating system, phishing links blocked split by channel, sideloading and permission-change attempts flagged, and median time from alert to containment. Coverage is the one to watch first, since a capability deployed to 60% of the estate leaves the other 40% as the route in.

Corrata provides mobile threat defence for iOS and Android. See how detection and response works on employee devices.

The post Mobile Malware Detection on Work Phones appeared first on Corrata.

Most advice about spotting a scam says to look at the writing, check the spelling, watch for the odd phrasing, see whether the greeting fits, and so on. That advice worked for twenty years, and it worked for a reason that had nothing to do with detecting dishonesty. Scam messages were written at volume by people operating in a second or third language, and the errors were a by-product of cheap production.

The FBI stated the consequence in a December 2024 warning, noting that generative AI tools “correct for human errors that might otherwise serve as warning signs of fraud”.

The signal that advice depends on has been removed at the source. 

What are AI scams?

An AI scam is any fraud where generative AI produces or personalises the deception. It can be text from a language model, cloned voice, synthetic video, fabricated documents.

The crime is unchanged. What changed is the unit economics, which is the part that should interest you, because your controls were sized against the old ones.

A team at Harvard Kennedy School measured it. Generic scam mail achieved a 12% click-through rate against their participants. Emails written by human experts using established persuasion techniques reached 54%. Emails researched, written, and sent by an automated tool, with no human in the loop, also reached 54%. Cost per target, including reconnaissance: roughly four cents.

Spear phishing used to be rationed. Research time only paid off against a valuable target, so most of your inbound was generic and most of your workforce was protected by their own unimportance. That is no longer true. Every person on your org chart is now worth a tailored approach, and the org chart is public.

One implication for how you triage: A message of a quality that once indicated a well-resourced actor no longer tells you anything about attribution.

Types of AI scams your controls need to survive

Business email compromise: Still the costliest category. The FBI’s 2025 Internet Crime Report puts losses above $3 billion. No payload, no malicious link, nothing for a gateway to match on. The control is your payment approval process, not your mail filter.

Voice cloning: Used to stage urgency, or to clear telephone-based verification. The same report was the first in twenty-five years to break out AI as a category, logging around $893 million, and the Bureau notes this understates the position because victims rarely recognise AI involvement.

Deepfake video: Microsoft’s 2025 Digital Defense Report recorded a 195% global rise in AI-generated identity forgeries, now convincing enough to defeat liveness checks. If any approval in your environment rests on seeing a face, that approval is weaker than your documentation says.

Service desk impersonation: In both directions, to obtain a credential or a reset.

How to prevent AI scams when the message is unreadable

Accept first that you cannot detect AI-generated text by reading it, and neither can your staff. The Harvard researchers concluded that what separates an excellent fraudulent message from an excellent legitimate one is mainly the sender’s intention.

So move the judgement off the writing and onto the request. Four questions worth embedding in process rather than training:

• Does this move money, change payment details, share a credential or grant access?
• Is it applying time pressure, and would delay actually cost anything?
• Is it routing around the normal process?
• Does it match what this person normally asks for?

And four controls that hold, because none of them depend on anyone judging a message correctly.

• Verify through a channel you established, never one supplied in the message. This is the single control that survives a cloned voice, a spoofed sender and a live deepfake at once.
• Use phishing-resistant MFA, passkeys and hardware keys. SMS codes are relayable in real time.
• Bank details, payroll, and credentials must be confirmed by a second person through a second route.
• Assume the attacker has the org chart. Familiarity is not authentication. If your training implies otherwise, that is now a liability.

None of that is new to you. What is new is that these have moved from good hygiene to load-bearing, because the perceptual layer above them has gone.

Where the residual exposure sits

IBM’s 2026 Cost of a Data Breach report has phishing as the most common initial attack vector for the fourth consecutive year. Its voice and SMS variants carried the highest average breach cost of any initial vector, at $5.29 million. The most expensive way into an organisation now arrives on a phone.

Your stack was built around email and the corporate network. A lure delivered by text message, QR code, messaging app or browser link lands on a device with no gateway in front of it deciding what is allowed through, on the endpoint most likely to be personal, checked in a queue and read quickly. You probably have MDM there. MDM manages configuration. It does not inspect what arrives.

There is a second problem, and it applies to the tooling you do have. Reputation and blocklist approaches lag a destination generated once for one recipient. Corrata’s own detection data shows the decay rate: across customer mobile fleets, 69% of the AI service domains observed had never been seen before. Those were legitimate services, not attack infrastructure, which is what makes the point cleanly. A list that cannot keep pace with software that is not hiding will not keep pace with a lure built to be new.

Corrata inspects traffic on the device itself, at the network layer where traffic from every app converges. Coverage does not depend on which channel the lure arrives through. Detection works from what a connection is doing rather than from a catalogue of what has been seen before, and it reads traffic characteristics rather than message content, so the workforce is covered without anyone reading their messages.

Conclusion

The messages improved because a cost constraint disappeared. Your perceptual defences were built on that constraint, and no amount of additional vigilance restores a signal that no longer exists.

Two things follow. Your procedural controls and AI governance have to carry more weight than they were designed to. And the surface where the most expensive of these lures now lands is the one you have the least visibility into.

Book a demo to see what is currently reaching your mobile fleet.

The post AI Wrote the Scam Text, and it is Better Than the Last One appeared first on Corrata.

The phone in your pocket holds your work email, your login codes, your files and your calendar. So does every phone your staff carry. Two EU laws now shape how those phones must be looked after, even though neither one mentions phones at all.

Here is what the two laws are, and what they mean for mobile.

What is NIS2?

NIS2 is Directive (EU) 2022/2555. It is the EU’s main cyber security law, replacing an earlier version from 2016.

It does two things: It widens the list of sectors that have to meet a cyber security standard, and it raises that standard for all of them.

Annex I of the directive covers essential sectors such as energy, transport, banking, health, water and digital infrastructure. Annex II covers important sectors such as post, waste, food, manufacturing and some digital services. Size limits then apply, though a few types of firm are in scope whatever their size.

NIS2 is a directive rather than a regulation, so it reaches firms through each country’s own law. The duties come from the directive. Details like who you register with and who you report to are set at home, and the timing varied from one country to the next.

Article 21 lists ten basic measures that firms have to take. The ones that land on mobile are risk policies, incident handling, supply chain security, access control and asset management, encryption, staff training and multi-factor login. The rest cover business continuity, building and maintaining software safely, and checking that your own measures work. Article 20 adds that the board has to sign all of that off, and that senior managers can be held liable in person if the firm falls short.

Does NIS2 cover mobile phones?

Yes, indirectly. NIS2 places duties on organisations rather than devices, but Article 21 requires in-scope firms to manage risks across the systems they use, including asset management, access control and multi-factor authentication. A phone that accesses work systems or approves logins is part of that estate, whether the company owns it or not.

What is DORA?

DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act. It applies to a wide range of financial entities and also establishes requirements and an oversight framework for ICT third-party service providers.

DORA is a regulation rather than a directive, so it applies direct with no national law in between. It has applied since 17 January 2025.

Where NIS2 asks a wide set of sectors to reach a baseline, DORA asks a narrower set to prove they can take a hit and keep running. It covers ICT risk management, incident reporting, resilience testing, supplier risk and threat intelligence sharing. DORA is accompanied by detailed sector-specific technical standards and reporting/classification rules, making its requirements more granular for financial entities.

Does DORA apply to mobile devices?

Yes, where a phone or tablet reaches a financial entity’s systems or data. DORA never mentions mobile devices, but Article 8 requires financial entities to identify and classify the ICT assets their business functions rely on. A phone used for work email, files or login approvals is one of those assets, so DORA’s requirements on protection, detection and incident reporting apply to it.

How NIS2 and DORA reach the phone

Neither law has a mobile section. Phones come in because both laws are written about the whole ICT estate, and phones are part of that estate. Five things follow.

Phones are part of the ICT risk picture: Both laws require organisations to understand and manage the ICT assets and systems they rely on. A work phone that accesses company email or systems therefore needs to be accounted for in the organisation’s risk and security controls. The same can apply to a personal phone used for work.

Most logins now go through a phone: Access control is one of the ten measures of Article 21, and the phone is where access is granted, by push prompt or by passkey. That puts the handset in the login path rather than at the edge of it.

Mobile software creates supply chain risk: NIS2 requires firms to address security risks in their relationships with suppliers and service providers. For mobile that can include app developers, cloud and backend providers, and the technology suppliers an app depends on. It is worth remembering how much of a mobile app is other people’s code, since a lot of what ends up on the handset never came through a supplier contract at all.

Both laws run on a clock, and a phone is often the last thing to be noticed: NIS2 requires an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, an interim report if requested, and a final report within one month of the notification.

DORA is tighter still. First notice of a major incident is due within 4 hours of classifying it as major, and within 24 hours of detecting it at the latest. If a mobile attack is not detected until the user calls the help desk, the organisation may already have lost valuable time in detecting, assessing and responding to an incident.

Mobile uptime counts as resilience: DORA is about keeping services going. Where a mobile app supports a business service or a critical or important function, its availability can form part of the ICT resilience picture DORA requires the firm to manage.

Which NIS2 and DORA requirements apply to mobile devices?

Neither law has a mobile section, so the obligations come from articles written for the whole ICT estate. These are the ones that land most directly on phones and tablets.

Who carries the risk under NIS2?

Most cyber rules land on the company. NIS2 also lands on people, and that is the part worth reading twice.

Article 20 asks the board to approve the risk measures, keep an eye on how they get put in place, and do enough training to judge cyber risk for themselves. Senior managers can be held personally liable if the firm falls short, and in serious cases an authority can bar a chief executive from running the company for a while. What that looks like in practice depends on how your own country wrote the directive into law.

The big figures you see quoted, up to at least €10 million or 2% of worldwide turnover for essential entities, and €7 million or 1.4% for important entities, are administrative-fine ceilings that Member States must provide for in national law; they are not automatic fines.

A board signs off the risk picture it gets shown. Most board packs cover the network and the laptops properly. Mobile usually appears as one line saying the devices are managed, which describes how they are set up rather than what is happening on them. If the picture you approved had a mobile-shaped hole in it, you approved something that was not accurate. Your name is on that approval.

What NIS2 and DORA do not require

Neither law tells you to buy anything. There is no NIS2 approved product list and no DORA mobile standard. Both ask for measures that fit the risk, a way to spot incidents, a way to handle them, and proof that all of it is in place.

Nor do the laws reach into a personal phone that never touches work. The trigger is the link to the business, not the hardware.

Why teams look at mobile threat defence next

Nothing above says you have to buy a tool. But both laws ask for something most mobile setups cannot currently do, so it is worth being clear about where the gap usually sits.

Most firms already run mobile device management. MDM does a specific job, and does it well. It sets the passcode rule, checks the OS version, pushes the apps you have approved, and wipes a handset that goes missing. That covers a good part of the asset and access work in Article 21.

What most MDMs do not do is watch for an attack. They do not look at where a phone is connecting or what it is being asked to do. A handset can sit green in the MDM console while it loads a phishing page, talks to an attacker’s server, or runs an app that is quietly leaking data. The console reports the device as compliant, because by its own measure it is.

That gap matters, because the incident duties in both laws are about spotting and handling threats rather than about configuration. Mobile-specific detection can close that control gap by showing threats on the handset that device-management controls alone may not reveal, and the mobile threat defence providers active in 2026 differ mainly in where that detection runs and what it collects.

There is a second argument that has nothing to do with audits. An attack that is detected and blocked early may never develop into a reportable incident. Early detection therefore reduces both operational impact and the risk of discovering a serious incident late in the reporting window. 

The takeaway

NIS2 and DORA never use the word phone, but still land on it. NIS2 lifts the cyber security floor across a wide set of sectors. DORA makes financial firms show they can keep running through trouble. In both cases, the phone in your pocket is part of the estate being asked about, because it holds the logins, the data, the access, and often the second factor too.

Corrata is an EU-native company. We help security teams in regulated sectors see mobile threats on iOS and Android, and keep the records that support compliance efforts.

Book a demo to see how Corrata supports mobile risk work under NIS2 and DORA.

The post NIS2, DORA and Mobile Phones: What Each Law Requires appeared first on Corrata.

European data sovereignty is the principle that data generated in the EU should be governed by EU law and held by organisations answerable to it.

What sovereignty adds to a compliance discussion is the question of reach. A contract can name a hosting region, but can’t always limit which authorities can require the operator to produce the data, because that follows from where the operator is established and who owns it. Two suppliers can host in the same European data centre and still sit under different laws.

Mobile is the least protected surface in most firms, and increasingly where AI-built attacks land first. Phishing arrives by text, chat apps, and QR codes, not just work email. Fake apps appear in official stores and through sideloading. Desktop tools miss most of it.

The reason lies in how the platforms are built. Phone operating systems keep apps in a sandbox, so security tools cannot inspect processes, memory, or files the way desktop agents do. The limit is tightest on iOS. Android narrows it rather than removing it. Vendors work from what remains visible: network behaviour, app data, and signals such as jailbreak status and patch level.

What separates products is where the analysis happens. Cloud designs send traffic to a gateway, which gives the vendor the means to read content and browsing history, and some do so by opening up TLS. On-device designs check traffic on the phone and can work from connection data alone. Same goal, very different data footprint.

Where Data Sovereignty Meets Mobile Security

Mobile security has to handle personal data. Detection works by watching what a phone does, and those records point to a phone that points to a named person. Connection data, app lists, and device signals are all personal data under GDPR, whether or not anyone intends it.

Design sets how much data, and how private it is. A design that routes traffic through a gateway can handle browsing history and message content. A design that checks traffic on the phone can send almost nothing. Both find threats, but only one holds a record of what your staff do all day.

So sovereignty limits design rather than describing a vendor. The question is not whether a supplier calls itself European, but how much personal data its design makes it hold, and whose law reaches that data. A small footprint under EU law and a large one under foreign law are different risks, and that gap is built rather than contracted.

Data sovereignty belongs in a mobile security review because it does not improve detection. It sets what you take on to get it.

Understanding GDPR Compliance

Sovereignty frameworks set direction, but GDPR is what regulators act on and auditors test. Its transfer rules turn jurisdiction into a legal question. Personal data can only leave the EU by an approved route, such as a Commission decision that the destination country offers adequate protection, or standard contractual clauses. That route is separate from the grounds you need to process the data at all, and both have to hold.

Any telemetry leaving a device is personal data, because network metadata tied to a device tied to a named employee identifies a person. How much there is, and how revealing, depends on the architecture, so architecture and GDPR compliance cannot be assessed apart. Four requirements carry most of the weight:

• Data minimisation: On mobile, architecture sets the ceiling. Policy works inside it and cannot lower it.
• Special category data: Telemetry can reveal special category data by inference, and European courts have held that data which indirectly discloses sensitive information counts.
• Purpose limitation: Data gathered to detect threats must not drift into staff monitoring.
• Lawful basis and transparency: Employees must be told what is collected from their devices and why.

Monitoring staff devices at this level normally needs a formal impact assessment before rollout. Consent is rarely workable at work, because staff cannot freely refuse. Some countries also require consultation with worker representatives.

The Role of Tech Sovereignty in Data Protection

Tech sovereignty means building independent European capability across cloud, AI, and security infrastructure, so organisations rely less on providers answerable to non-EU jurisdictions. Concentration risk drives it as much as privacy. Three US providers hold around 70% of the European cloud market, and European providers around 15% (Synergy Research Group). Digital sovereignty is the wider agenda, and tech sovereignty is its infrastructure component.

Mobile is where European tech sovereignty is thinnest. Two non-European companies own the operating systems, the default app stores and the push services security alerting depends on.

EU rules have opened up alternative ways to distribute apps, but that changed who can ship software rather than who owns the platform.

Patch delivery is more fragmented still, spread across OS vendors, handset makers and chip suppliers, almost none of them European. Carriers add another layer of variation. Small European platforms exist, but none offers what a large deployment needs on management, app availability and patching.

Because that platform layer is fixed, the security layer is where the remaining sovereignty decisions sit, which makes them more consequential rather than less.

The EU AI Act and Data Sovereignty

The EU AI Act is risk-based product regulation, not a sovereignty instrument, and it imposes no data localisation requirement.

Classification follows what a system is for and where it is used rather than the technology inside it, judged against risk to health, safety and fundamental rights. A few rules do target specific techniques, but purpose does most of the work.

In-scope systems fall into four tiers: unacceptable risk, prohibited under Article 5; high risk, carrying obligations from risk management through to conformity assessment; limited risk, requiring disclosure under Article 50, which can also apply to a high-risk system; and minimal risk, carrying no tier-specific duties. High risk is the Act’s own term. The other three labels are conventional rather than statutory.

The high-risk rules were due to apply from August 2026, but were put back to December 2027 for standalone systems, and to August 2028 for AI built into regulated products. 

General-purpose AI models sit apart with their own obligations. Contrary to a widely repeated claim, the Act does not require all AI to be explainable, since transparency is proportionate to risk.

For mobile security, the tier follows purpose rather than marketing. AI that identifies malicious infrastructure generally sits in the lower tiers. Employment and worker management is an Annex III high-risk domain, and it reaches systems meant to monitor and assess how staff perform and behave. A tool pointed at employees rather than at threats becomes a heavier compliance object, and the exemption for low-risk uses closes once a system profiles individuals. That mirrors GDPR purpose limitation.

Mobile Security Requirements under GDPR

Where a gateway performs TLS interception, which requires a trusted certificate on the device, the data in scope extends to visited URLs, browsing history, and message content. Where inspection covers only unencrypted signals such as DNS queries and server name indication, the footprint is smaller but still leaves the device.

Some of that connection data is being encrypted too. Newer standards hide the name of the site being contacted from anything watching the network. That is a reason to check on the device, where the request starts, rather than at a point in the network.

This matters because of what mobile data reveals. An installed application inventory alone can indicate health conditions, religious or philosophical beliefs, political opinions, sexual orientation, and trade union membership by inference, and all of those are Article 9 special categories. BYOD sharpens the problem, since the same tooling observes an employee’s personal device. Processing intimate data about people who cannot easily refuse is defensible when the footprint is minimal and the jurisdiction clear, and considerably harder when neither holds.

Challenges in Achieving Data Sovereignty in Mobile Applications

Detection needs telemetry, and telemetry about a device is personal data, so there is no version of mobile security with no footprint at all. Corporate ownership can matter as much as hosting location, so a European hosting region does not on its own settle which law reaches the data. Where analysis happens is decided early in a product’s life and is rarely adjustable at deployment, so it is better treated as a fixed property than as a setting.

None of these has a contractual fix. They are answered by narrowing what leaves the device and by being clear about which company holds what remains.

Conclusion

European data sovereignty is not something a mobile security product can be certified into. The platform layer is not European and will not become European, so the decisions that remain sit in the security layer: how much personal data the product needs to leave the device, and which company holds it once it has. Both are set by design rather than by contract. That is what makes them worth settling during evaluation, while the answer still affects which product you choose.

The post European Data Sovereignty and Mobile Security Requirements appeared first on Corrata.