Pre-installed apps can ship with capabilities that would be harder to detect or reject in a public app store workflow. That creates a wider attack surface because manufacturers may bundle software that cannot be fully removed, updated consistently, or constrained by the same user-facing safeguards. The result is persistent access risk on the device.
Why pre-installed apps are a different security problem
Pre-installed Android apps sit closer to the device trust boundary than apps installed later from a store. That matters because they may inherit manufacturer, carrier, or OEM privileges, arrive before the user has any realistic choice, and bypass the ordinary discovery and review path that would otherwise expose risky behavior. The security question is not just whether the app is present, but whether it is placed outside the normal accountability loop.
When that happens, a preloaded app can become part of the device’s baseline attack surface. Even if it is not overtly malicious, it can still carry permissions, integrations, or defaults that would have been rejected, challenged, or at least more heavily scrutinized in a public app marketplace. The concern is structural: the app is trusted earlier and often removed from the user’s practical control later.
That changes how defenders should think about the endpoint. A store app is usually treated as user-installed software with a visible provenance trail; a pre-installed app often behaves more like embedded platform software, where the real question is whether its access is proportionate to its purpose and whether its update path is reliable. The result is a wider and stickier trust surface on the device.
Where the risk comes from in practice
The first risk is persistence. If an app cannot be fully removed, or if disabling it leaves privileged components behind, the exposure remains even after the user tries to reduce it. That makes the app harder to contain than ordinary third-party software and can leave sensitive capabilities reachable for the life of the device.
The second risk is inconsistent patching. Store-distributed apps typically ride a clearer update pipeline, while pre-installed apps may depend on OEM firmware updates, carrier release cycles, or opaque vendor coordination. If those updates lag, the app can remain exploitable long after users think the device is current.
The third risk is hidden permission inflation. Preloads may be granted broad system access, default integrations, or implicit trust relationships that are not obvious to the user. For mobile defenders, that is a familiar pattern: software that is close to the OS and outside normal consumer review tends to deserve stronger scrutiny than software that is simply available in an app store.
What this means for device assurance and governance
Security review is not only about malicious code, it is about whether the control model is consistent. If pre-installed apps are exempt from the same review standard as store apps, the device inherits a double standard: one class of software is filtered through marketplace policy, the other is accepted because it shipped with the handset. That undermines assurance because the most trusted software may be the least visible to the user.
For enterprise and regulated environments, the practical consequence is that app provenance and update governance matter as much as app functionality. A preloaded app with network reach, account access, or device-admin-style influence should be treated as a durable trust dependency, not a convenience feature. If that dependency cannot be observed, constrained, or removed, it should be regarded as a residual risk on the endpoint.
For a broader mobile threat lens, this is the same kind of asymmetry captured in mobile app secret exposure and hardcoded trust problems, where software ships with capabilities users do not meaningfully negotiate and cannot easily verify. See IOS app secrets leakage report for a related example of how embedded software assumptions can increase user exposure.
How teams should judge the difference
What to verify: treat pre-installed apps as trusted only if you can verify their permissions, update path, removal state, and dependency on system privileges. If those properties are not inspectable, the assurance case is weaker than for a store app with a normal distribution trail.
What to prioritise: focus first on any preload that can access accounts, network services, sensors, device administration, or sensitive data flows. Those are the apps most likely to turn a convenience preload into a durable exposure.
Common mistake: assuming that “pre-installed” means “platform-vetted.” In practice, preloaded software may be vetted to a different standard, updated differently, and constrained less tightly than user-installed software.
Practitioner takeaway: the important distinction is not whether an app came from a store, but whether its privilege, updateability, and removability are held to the same security bar as everything else on the device.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Preinstalled apps need security review before release and preload. |
| Recommendation — Require security testing and evaluation before allowing preloaded apps onto devices. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Preinstalled apps expand software inventory and require governance on endpoints. |
| Recommendation — Inventory all preloaded apps and remove or disable unnecessary software. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of Technical Vulnerabilities | Preloaded apps can ship with exploitable flaws that need ongoing vulnerability management. |
| Recommendation — Track and remediate vulnerabilities in preinstalled apps under the same process as other software. | ||
| OWASP ASVS | V13 — Configuration | Device app defaults and privilege-bearing settings shape exposure and trust. |
| Recommendation — Review default app configurations and restrict privileged settings before deployment. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Preloaded software with broad embedded access is analogous to overbroad default trust. |
| Recommendation — Audit default privileges and deployment assumptions that let preloaded software exceed its intended scope. | ||
Related resources from NHI Mgmt Group
- What happens when third-party vendors are not held to the same security standards as the organisation?
- What happens when contact tracing or workplace tracking apps are rushed into production without enough security review?
- Why do prototype apps often fail enterprise security review?
- How should security teams govern access when AI agents and humans share the same apps?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
