User-installed software is software that end users install on their own devices or managed systems without central deployment. It can introduce unsupported tools, licencing issues and malware exposure. Defenders should control installation rights, monitor for unapproved applications, and review whether users need local admin privileges or a managed software catalogue instead.
What user-installed software actually is
User-installed software is software that an end user adds to a device or managed endpoint without going through central software deployment. That makes it different from approved line-of-business applications, because it may sit outside standard catalogues, packaging, testing, support and patching processes. The core issue is not the installation event itself, but the control gap it creates around provenance, licensing, compatibility and security oversight.
On unmanaged devices, user-installed software is simply part of normal system use. On managed systems, it becomes a governance question: whether the organisation allows local installation, under what conditions, and how much trust is placed in the user to choose safe tools. The answer usually depends on whether the device is meant to be locked down, whether the user needs flexibility for their role, and whether alternative delivery methods such as a managed software catalogue are available.
At a technical level, user-installed software can be benign productivity tooling, browser add-ons, development utilities, or consumer apps. It can also be unwanted, unsupported, or malicious. The security concern is that once local installation is allowed, the software may create new auto-start entries, background services, persistence mechanisms, network connections, update channels, or data access paths that were never reviewed centrally.
Why it creates control, support, and exposure problems
The main operational problem is that user-installed software expands the endpoint’s attack surface faster than the organisation can usually inventory or validate it. Unsupported applications can bypass standard hardening, conflict with approved tools, or introduce hidden dependencies that make incident response and patching harder. If the software is tied to a user’s convenience rather than a business need, it is often the first place where local exceptions begin to accumulate.
Licensing is another material issue. Software installed outside procurement or software asset management processes can breach usage terms, complicate audits, and create shadow IT that the business does not know it is running. In regulated or tightly managed environments, the larger risk is that an apparently harmless utility can become an unmanaged execution path for data movement, credential capture, or unapproved cloud connectivity.
User-installed software is especially relevant where installation rights are broad. If users retain local admin privileges, they can often install or modify software that should have been centrally controlled. That is why endpoint control and privilege review belong together: the software question is often really a privilege question, and the fastest way to reduce the risk is to remove standing installation authority where it is not genuinely needed. NIST SP 800-53 Guide is useful here because it connects access control, software integrity and baseline tailoring to the practical question of what should be allowed on a managed system.
How organisations usually contain it
Good control starts with deciding whether users may install anything at all, or only from an approved catalogue. If installation is permitted, it should be limited to trusted sources, approved package types, and clearly defined device groups. The goal is not to ban every user-facing tool, but to separate ordinary flexibility from software that can alter the endpoint’s trust boundary.
Most organisations also need some form of monitoring for unapproved applications. That can mean application inventory, endpoint detection, software allowlisting, or periodic review of locally installed packages. The right control depends on environment maturity, but the underlying requirement is the same: if software can be added locally, there must be a way to see it and decide whether it is acceptable.
Where installation rights cannot be removed immediately, the safer interim pattern is to pair local freedom with strict visibility and a clear exception process. That reduces the chance that a one-off convenience decision becomes a permanent unmanaged toolchain. Central software catalogues work best when they are easier to use than side-loading, because the practical alternative to user-installed software should be convenient enough that users do not need to circumvent controls. NIST SP 800-53 Rev 5 Security and Privacy Controls is a good external reference for the access control, configuration management and system integrity controls that underpin that approach.
Risk and Threat Considerations
User-installed software becomes risky when it is treated as low stakes local convenience rather than as a potential trust boundary on the endpoint. The same installation path that gives someone a productivity tool can also introduce unwanted persistence, unreviewed update mechanisms, data exfiltration routes or malware delivered as a seemingly legitimate app.
Failure mechanism: Users install software from unapproved sources, or install tools that require elevated privileges, and the organisation loses visibility into what code is running, what it can access, and whether it is supported or patched. That failure is amplified when local admin rights are widespread or when endpoint controls do not inventory installed applications reliably.
Impact: The result can be malware exposure, licensing breach, support failure, incident response blind spots, and a larger blast radius if the software interacts with sensitive systems or stored credentials. If the software is malicious or compromised, it may also become a foothold for follow-on compromise through persistence or credential access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | User-installed software needs asset visibility and inventory control. |
| AC-6 — Least Privilege | Local install rights depend on privilege scope and admin access. | |
| SI-3 — Malicious Code Protection | Unapproved software can introduce malware and unwanted executables. | |
| Recommendation — Maintain an accurate inventory of installed applications and review deviations from the approved baseline. Restrict local administrative privileges to reduce unsanctioned software installation. Apply anti-malware controls to detect and block malicious or untrusted software. | ||
Practitioner Guidance
What to verify: Start by checking whether the software is actually required for the job, whether it is sourced from an approved catalogue or repository, and whether it needs local admin rights to function. If the answer to any of those is unclear, treat the installation path as a control issue rather than a preference issue.
Decision rule: If a user-installed application can modify system state, reach sensitive data, or run with elevated privileges, it should be subject to the same approval and visibility standard as centrally deployed software. If it cannot be justified that way, remove the install path and replace it with a managed alternative.
What practitioners underestimate: The risk is often not the software category itself, but the accumulation of exceptions. A small number of allowed local installs can quietly become a parallel software estate that is harder to patch, harder to audit, and easier to abuse than the approved application set.
Practitioner takeaway: The practical test is whether user choice changes the device’s security boundary, if it does, software installation should be governed like any other privileged change.
Related resources from NHI Mgmt Group
- Why do scheduled tasks create persistent risk when paired with user-installed software?
- User-installed Software
- When should organisations prioritise workload identity controls over more user-focused IAM work?
- How should security teams secure hybrid and remote work without adding too much user friction?