Approved Software List

What an approved software list does

An approved software list is the policy-backed inventory that defines which applications are permitted on managed endpoints and systems. It gives IT and security teams a clear standard for what can be installed, supported and monitored, so the estate is easier to control than with ad hoc user choice.

The list is usually paired with application allowlisting, software packaging standards and endpoint management, so the control is not just advisory. In practice, it becomes a reference point for build images, onboarding, exception handling and software requests, especially where unmanaged tools would create support, compliance or security noise.

Why organisations use it

The main value of an approved software list is consistency. Standardised software reduces variation across devices, lowers support overhead and makes it easier to secure common configurations. It also helps organisations steer users toward supported browsers, productivity tools, admin utilities and security agents rather than leaving each endpoint to drift independently.

That standardisation matters because unauthorised software often introduces hidden dependencies, weaker update practices or unreviewed data flows. A controlled list helps prevent tool sprawl, shadow IT and duplicate applications that can widen the attack surface or create avoidable operational complexity.

An approved software list also works as a governance boundary. When a tool is not on the list, the organisation has to decide whether to add it, block it or permit a one-off exception. That decision-making discipline is often more important than the list itself, because it forces ownership and review before software becomes part of the environment.

How it is maintained and enforced

In mature environments, the list is maintained as a living control, not a static document. Security, operations and service owners review requests against supportability, risk, licensing, compatibility and data-handling requirements, then publish the approved set through endpoint management or software distribution tooling.

Enforcement usually happens through a combination of image baselines, restricted installation rights, application control and device management policy. Where the environment is tightly governed, users cannot simply install software because they have local admin rights or access to an app store; they can only use what the control plane allows.

A useful approved list is specific enough to be actionable but broad enough to remain usable. If it is too narrow, people work around it. If it is too broad, it stops meaningfully filtering software risk. The practical balance is to allow the applications the organisation can support, secure and audit with confidence.

What changes from a security perspective

The security benefit is not just fewer installs. An approved software list improves visibility into what is actually running, which helps patching, vulnerability management, audit readiness and incident response. When teams know the sanctioned baseline, it is easier to spot outliers, unsupported versions and software that should not be present at all.

It also narrows the space in which attackers can hide. Unapproved remote tools, browser plugins, sync clients and administration utilities can be used to bypass controls or preserve access after compromise. A well-run approval process reduces the chance that those tools become normalised inside the estate.

Where software controls are combined with documented exceptions, the list also creates a better record for investigations. If a system is compromised, teams can compare installed software against the approved baseline to identify suspicious additions, unsupported utilities or persistence mechanisms that deserve closer review.

Risk and Threat Considerations

An approved software list reduces exposure, but it can fail if the inventory is incomplete, exceptions are poorly governed or users have a second route to install software outside standard management. In those cases, the organisation may believe it has control while unapproved tools continue to enter the environment.

Failure mechanism: Weak enforcement, unmanaged endpoints, excessive local rights or stale approval records allow risky software to bypass the control, creating blind spots for patching, logging and incident investigation.

Impact: Unapproved software can expand attack surface, introduce unsupported dependencies, enable persistence or remote access, and complicate containment when a device is compromised.

Practitioner Guidance

Why practitioners should care: Treat the approved software list as an operational control, not a catalogue. Its value comes from being current, enforceable and tied to change review, asset inventory and endpoint policy.

What to watch for: The most common failure is drift between the list and reality, especially on laptops, engineering workstations and exception-heavy teams. If installed software is not regularly reconciled against the approved baseline, the control loses credibility.

Practitioner takeaway: Keep the list aligned to what you can actually support and enforce, then measure exceptions as an exception process, not as a permanent workaround.

Related resources from NHI Mgmt Group

• How should security teams govern approved software distribution on managed devices?
• What breaks when users install software outside the approved catalog?
• What breaks when organisations rely on approved remote support software as a trust signal?
• What breaks when macOS users trust signed or approved software by default?