What is bloatware and is it a security risk?

Bloatware is software you did not choose and do not need, often preinstalled on a new device or bundled into a larger package. It matters for security because every extra program is code that can have flaws, needs patching and may collect data.

What counts as bloatware?

The word has two common uses:

• Preinstalled apps. Trial versions, vendor utilities and partner apps that come on a new phone, laptop or server image.
• Feature bloat. Software packages that bring in many components or dependencies you never use, such as a large library included for one function.

Not everything preinstalled is bad. Some vendor tools handle firmware updates and drivers, and removing them can break things. The test is simple: does this software have a purpose that someone in your organization can name?

Why is it a security problem?

NIST's glossary defines attack surface as the set of points on the boundary of a system where an attacker can try to enter, cause an effect or extract data. Each extra application adds points to that set.

• More code, more flaws. Unused programs still have vulnerabilities, and attackers target widely installed ones.
• Patching burden. Software nobody owns is software nobody updates.
• Background services. Many extras install services that listen on network ports or start with the system, and run with high privileges.
• Data collection. Some bundled apps send usage or device data to their makers or partners.
• Trusted position. A preinstalled app is often trusted by the system, which makes a flaw in it more valuable to an attacker.
• Supply chain. In developer terms, a bloated dependency tree means a larger set of third party code you did not review.

A constructed example

A company buys 400 laptops and clones the vendor's default image to each. The image includes a vendor support utility with a local service that accepts commands from a web page. Months later, a flaw in that utility is disclosed and fixed in an update. Because the utility was never in the company's software inventory, nobody pushes the update, and 400 machines run the vulnerable version. The company did not choose the program, but it owned the exposure.

A clean base image, built from the operating system and only the approved tools, would have removed the issue.

How do you handle it?

For devices.

1. Build a standard image from a clean operating system install, not from the vendor's default one.
2. List what is installed on a sample machine and decide for each item: keep, remove or investigate.
3. Remove or disable the rest through your device management tool.
4. Keep drivers and firmware tools that you need, and update them.
5. Re-check the list after major operating system updates, which can reinstall apps.

For software projects.

1. Produce a dependency inventory, including indirect dependencies.
2. Look for packages included for one small function, and replace with a few lines of your own code where safe.
3. Remove dependencies that are no longer imported.
4. Use build tools that show what ends up in the final artifact, and trim it.
5. Use minimal base images for containers and remove build tools from runtime images.

How to check or apply this

• Compare a fresh machine's installed list with your approved list. Every difference is a decision to make.
• Count listening network ports on a typical device and ask who owns each.
• For one application, compare the number of direct and indirect dependencies, and ask whether that count is acceptable.
• Add an "unused dependency" check to the pipeline.
• Review privacy settings and telemetry in tools you keep.

Removing software has its own risks: take a snapshot first, test on a pilot group and keep a path to reinstall.

Safeguard's dependency scanning and reachability analysis help on the project side, by showing which libraries your code actually uses and which findings sit in code that is never called.

Quick check

Sources

• NIST CSRC Glossary, attack surface
• NTIA, Software Bill of Materials
• NIST SP 800-190, Application Container Security Guide

Last reviewed: 18 October 2026.