Preinstalled Android malware can compromise a smartphone before it is even used for the first time. Integrated into the firmware—that is, the system software provided with the device—it may have elevated privileges and resist conventional uninstallation. For a company, the price of purchase is therefore not enough to evaluate a device: its provenance, software support, and MDM management must also factor into the decision.
How can malware be installed before the phone is purchased?
A preinstalled Android malware can be added to the firmware during the device’s manufacture, customization, or distribution. The malicious program becomes alors a system application, sometimes signed with a key from the platform. The user receives an already compromised device without downloading a file or accordenting to any autorhorization themselves.
Firmware is the collection of software components that allow the phone to boot and run Android with its hardware. It notably includes the operating system, drivers, and manufacturer adaptations. An application present in this layer is not subject to the same restrictions as an application downloaded from Google Play.
The Midnight Mimosa case illustrates this risk. According to the investigation published by Bitdefender on October 8, 2026, the activity observed between 2024 and 2025 involved entry-level Android devices from several brands, based on MediaTek platforms. The malicious component was integrated into the firmware before first use.
Bitdefender says it observed thousands of unique devices in more than 150 countries between 2024 and 2025, including France. However, this telemetry has not been confirmed by an independently published dataset. As of October 2026, responsibility for the modification and the exact stage of the supply chain remain unknown.
Why doesn’t uninstalling an application remove the threat?
Uninstalling a visible application is not enough when the preinstalled Android malware resides in a protected system partition. The persistent component may reinstall malicious payloads, grant them permissions, or load remote code. A factory reset may also restore the compromised firmware instead of cleaning it.
In Midnight Mimosa, the main component was a persistent system application signed by the platform. According to Bitdefender in 2026, it could install or remove software packages, grant permissions, and load remote code without user intervention. At least 32 disguised payload applications were identified for the 2024–2025 period.
The observed functions included hidden advertising, click fraud, and using the phone as a residential proxy. A residential proxy routes a third party’s traffic through the phone’s internet connection, making it appear as a legitimate address to the services being visited. This can consume battery power and data, but above all, it can associate the business with traffic it did not initiate.
Names such as com.android.system.lite, com.android.sys.prot, com.android.sys.gmsprot and com.android.sys.bcprot were observed between 2024 and 2025. These indicators are not sufficient as a detection method: the names varied depending on the firmware versions. This is a common pitfall. The absence of a known name does not prove that the device is safe.
This mechanism differs from a downloaded Android malware that bypasses banking protections. In this second scenario, removing the application and correcting the installation vector may be sufficient. With a system implant, the entire software image must be called into question.
Does Android Verified Boot protect against compromised firmware?
In 2026, Android Verified Boot checks the integrity of boot components and protected partitions through a chain of trust rooted in hardware. This protection detects an unauthorized modification, but it does not guarantee that firmware correctly signed by the vendor contains no malicious component from the outset.
Android attestation can transmit the boot key, the device’s lock state, the verified boot state, and the fingerprint of the system being checked. The result answers a specific question: Is the device running the expected, signed image? It does not necessarily answer another question: Was that image safe when it was created?
A malicious package integrated into correctly signed vendor firmware can therefore appear to be a trusted element. This is the situation in which the obvious solution—simply checking that the bootloader is locked—becomes insufficient. Attestation must be cross-referenced with the model, origin, patch level, and the manufacturer’s update policy.
Google Play Integrity provides an additional signal. According to Google’s 2026 documentation, the verdict MEETS_STRONG_INTEGRITY requires an authentic and certified device. On Android 13 or later, it also requires the system and vendor partition security patches to be less than one year old.
None of these checks provides an absolute guarantee against preinstalled Android malware. Their value lies in accumulating signals and automatically blocking devices that fall outside policy, as with managing software updates in the enterprise.
How should a business choose Android smartphones?
A defensible purchasing policy in 2026 limits the fleet to explicitly approved models, purchased from documented resellers and supported by a known end-of-updates date. Each device must be enrolled in an MDM tool before use, then rejected if it fails integrity or patch-level requirements.
MDM, or Mobile Device Management, is a centralized administration service for smartphones and tablets. In 2026, Android Enterprise makes it possible to inventory hardware and software, enforce Google Play Protect, check integrity, restrict application sources, and remotely lock or wipe a device.
The following table compares the most useful checks before a business purchase.
| Control | Risks covered | Limit to be aware of | Recommended decision |
|---|---|---|---|
| Documented reseller | Opaque supply chain | Does not by itself prove firmware integrity | Reject vendors without traceability |
| End-of-patch date | Unpatched vulnerabilities | A promise must be monitored over time | Record the deadline in the MDM inventory |
| Android Verified Boot | Unsigned system modification | Accepts a correctly signed vendor image | Require a locked and verified boot process |
| Google Play Integrity | Uncertified or outdated device | Does not perform an exhaustive firmware analysis | Block devices outside policy |
| Android Enterprise Management | Unmanaged applications and settings | Requires enrollment before use | Enroll the device as soon as it is prepared |
Frankly, a very inexpensive smartphone is not justified for sensitive professional use if its manufacturer does not clearly publish the duration of support. The initial savings can be absorbed by manual preparation, incidents, early replacement, and the inability to access business tools.
In the projects we undertake, we often see the team choose the model first and then look for ways to manage it. The order should be the reverse: define the MDM, integrity, and support duration requirements, then select the devices that meet them. The same logic applies to the data protection and sensitive features of a mobile application.
An actionable policy consists of five verifiable rules:
- autorize only a short list of models and versions approved in 2026;
- purchase from identified resellers and retain the order references;
- record the promised end date for firmware updates;
- enroll each device in the MDM before handing the device to the collaborator;
- automatically block professional access in the event of an integrity failure or an insufficient cororrection level.
What should you do when a professional smartphone appears compromised?
A smartphone suspected of containing preinstalled Android malware must be isolated from professional data and services without delay. The company can then collect the available logs, generate a remote diagnostic report, and lock or wipe the device. If the firmware is in doubt, deleting the visible application is not sufficient remediation.
The priority is to revoke the sessions, certificates, and access tokens used by the device. It is also necessary to check whether the same model, software version, or batch exists elsewhere in the fleet. On the agency side, the instinct should be to preserve the information useful for analysis before wiping, without allowing the device to continue communicating with business systems.
According to Google's Android Management documentation in 2026, supported measures include blocking access, collecting security data or a remote bug report, as well as locking and wiping. If the firmware is suspect, three options are safer: return it to the supplier, reinstall a clean image obtained from a reliable source, or permanently remove the device.
Reinstallation is reasonable only if the image used is distinct from the compromised image and its provenance can be established. Public accounts reported in 2026 indicated that some suspicious packages reappeared after deletion, and even after an official update in one case. No corresponding public explanation from the manufacturer had ever been found.
Caution remains necessary regarding Midnight Mimosa. Independent technical confirmation remains rare in October 2026, and most of the available information comes from Bitdefender's investigation. The indicators are serious enough to justify checks, but not to accuse a brand, subcontractor, or entire model without evidence.
Defining the purchase, enrollment, and removal of devices in advance avoids most improvised decisions after an incident. An outside perspective can also help connect Android Enterprise rules to mobile application access and the teams' actual constraints.
FAQ about preinstalled malware on Android
Does a factory reset remove an Android virus?
A factory reset generally deletes user applications and data, but it may restore malware present in the firmware. In the event of system compromise, a verified clean image or removal of the phone is necessary.
How can you tell if an Android phone is certified by Google?
Certification can be checked in the Google Play Protect information, while Google Play Integrity allows a service to verify a device’s integrity in 2026. However, certification does not constitute a complete analysis of the firmware’s content.
Does Google Play Protect detect malicious system apps?
Google Play Protect analyzes apps and may flag dangerous behavior, but a privileged system app that is correctly signed may be more difficult to neutralize. A company must supplement Play Protect with attestation, MDM, and a policy for approved models.
What signs may indicate that a phone is being used as a residential proxy?
Unexplained consumption of data, battery, or network resources may warrant analysis, but does not constitute proof. Network logs, package inventories, and security data collected by the MDM provide more actionable indicators.