Pre-installed applications are software that comes already installed on a device, operating system image, or managed endpoint before the user first uses it. They are typically added by the device maker, platform owner, or administrator, and may have default permissions, update channels, and removal limits that affect control over the system.
What Pre-Installed Applications Are
Pre-installed applications are part of the software baseline that ships with a device or managed endpoint before first use. They may be consumer utilities, vendor services, enterprise agents, or platform components, and their presence matters because they establish an initial trust and control posture before the user or administrator makes any changes.
Why They Matter for Device Security
Pre-installed applications can shape the attack surface from the first boot. Some have broad permissions, background services, auto-start behaviour, or update channels that are controlled outside the normal app-store model, which means their security depends heavily on the vendor’s build hygiene, signing practices, and update governance.
They also create a control boundary issue: the organisation may think it has a clean or standard image, but the device may already contain software that consumes resources, contacts external services, or exposes administrative interfaces. For that reason, security teams often treat pre-installed software as part of the trusted computing base until it is inventoried and assessed.
Common Security and Operational Implications
The practical impact is not that every pre-installed application is dangerous, but that they can introduce hidden dependencies and inconsistent control. A pre-installed management tool, updater, browser extension, or OEM service may be necessary for functionality, yet it can also increase persistence opportunities, complicate patching, or limit the ability to remove software that is not required for the business.
On managed endpoints, the issue is often governance rather than novelty. If pre-installed applications are not included in the asset baseline, configuration standard, and patch review process, they can drift away from organisational policy and become an overlooked route for data collection, privilege use, or lateral movement inside the endpoint.
How to Assess and Govern the Baseline
Organisations should understand exactly which applications are present in the default image, which ones are vendor-required, and which ones are optional. That assessment is best tied to asset inventory, software allowlisting, secure configuration review, and the device management process so the baseline is documented rather than assumed.
Where pre-installed software cannot be removed, the usual response is to constrain it, monitor it, and keep it updated through approved channels. The key question is whether the application is essential to operations or merely convenient, because convenience software often survives long after it stops being justified.
What to Watch For in Practice
Security teams should pay close attention when pre-installed applications run with elevated permissions, establish network reachability by default, or bypass the organisation’s normal software approval workflow. Those are the conditions that turn a benign baseline component into a control problem.
It is also worth watching for pre-installed software that persists after re-imaging, reappears through vendor updates, or cannot be cleanly audited. In those cases, the organisation may not fully control the endpoint it believes it owns, which is a security issue as much as an administration issue.
Risk and Threat Considerations
Pre-installed applications can create an early foothold for supply-chain weakness, overprivileged software, or unreviewed network access. The risk is highest when the application is trusted by default, difficult to remove, or updated outside the organisation’s normal validation process.
Failure mechanism: A pre-installed application ships with excessive permissions, hidden services, or externally reachable components that remain active before security teams can assess or harden the endpoint.
Impact: Attackers or unwanted software can abuse that trusted baseline to persist, collect data, expand access, or weaken endpoint integrity even on systems that appear freshly deployed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02 — Assets are inventoried | Pre-installed apps belong in the endpoint software inventory. |
| PR.PS-01 — Configuration management | Baseline software is governed through secure configuration and image control. | |
| Recommendation — Inventory default applications as part of endpoint asset management. Control the approved device image and baseline software set. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Pre-installed applications should be tracked as system components. |
| CM-6 — Configuration Settings | Default software and its permissions are governed by baseline configuration. | |
| Recommendation — Maintain an inventory of all pre-installed software on managed endpoints. Document and enforce approved baseline software and settings. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Pre-installed applications are software assets that must be known and controlled. |
| Recommendation — Track pre-installed software and remove or restrict unapproved applications. | ||
Practitioner Guidance
Why practitioners should care: The baseline image is part of the security boundary, so pre-installed applications should be treated as governed software, not harmless background noise. If they are not catalogued and reviewed, they can undermine standard hardening assumptions.
Governance implication: Assign ownership for the default application set, define which packages are required versus optional, and keep that list aligned with image management and endpoint security policy. Pre-installed software should be reviewed with the same discipline as other controlled platform components.
Related resources from NHI Mgmt Group
- Why do pre-filled applications still create fraud risk?
- Why do GenAI applications and agents fail trust expectations after passing pre launch checks?
- What is the difference between pre-deployment and post-deployment red teaming for LLM applications?
- How should teams decide when to build custom evaluators instead of using pre-built ones for LLM applications?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org