How to Stop Employees from Installing Software on Windows

Employees can install unauthorized software on your Windows machines even without local admin rights. Modern app packaging has outpaced the controls most IT admins set up years ago, and the gap is wider than most organizations realize.

The foundational step is removing local admin from all standard users. That single change blocks the majority of installation attempts. Shadow IT is endemic in most organizations, and uncontrolled app installs are a primary driver; stripping admin rights cuts off the most common path employees use to add them.

But removing local admin has a documented gap: apps like Spotify, Zoom, and Chrome install into the user profile directory by default. They require no UAC prompt and bypass Windows Installer controls entirely. You need layered controls to close that gap; GPO alone won't do it.

This article covers 7 methods from the baseline (standard accounts) through enterprise-grade (App Control for Business via MDM), a comparison table showing what each method catches and misses, a decision framework for your specific environment, and a note on the Windows 11 24H2 AppLocker issues IT admins need to know about before deploying.

TL;DR

Why Standard Users Can Still Install Software (And What You're Actually Controlling)

If you already understand the per-user install loophole and have removed local admin from all users, skip ahead to the methods section.

Windows has two installation models. Machine-wide installs write to C:\Program Files and HKLM registry locations — they require elevation, and a standard user account can't complete them. This is the model most people picture when they think about blocking software installs. It's also only half the picture.

Per-user installs write to %AppData%\Local or %AppData%\Roaming. They don't need a UAC prompt. Windows doesn't treat them as system-level installs, so standard account privileges are enough to run the installer. As one practitioner put it: if the software only affects the user's own profile, Windows doesn't require elevation to install it.

Apps like Spotify, Zoom, and Chrome package themselves this way by default. That's why practitioners on Spiceworks kept finding Spotify on machines where users had no local admin — the software installs to the user profile, not the machine. Standard account restrictions don't touch it.

You're actually trying to control two separate things: blocking the installation act and blocking execution of software that's already been installed. These require different tools. Knowing how to block installing apps on Windows means understanding that distinction first — then choosing the methods that address both problems for your environment.

7 Methods to Stop Employees from Installing Software on Windows

Think of these as a layered stack, not a menu where you pick one. Each method addresses a different part of the problem. No single method catches everything. Start with the simplest and add layers based on your environment and risk tolerance. Methods can and should be combined.

Method 1: Remove Local Admin (Standard User Accounts)

This is the mandatory starting point for how to block standard users from installing programs at the machine-wide level. Every other method below assumes you've already done this.

What it does: prevents installs to Program Files and HKLM registry. What it doesn't do: stop per-user installs (Spotify, Zoom, Chrome).

How to do it: Computer Management → Local Users and Groups, remove the user from the Administrators group. At scale, use GPO → Restricted Groups to enforce this across the domain.

• Pros: free, immediate, no infrastructure required
• Cons: doesn't stop per-user installs into the user profile directory

Getting executive and C-suite buy-in before removing local admin is the step that most rollouts skip, and the one that causes the most reversals.

Method 2: Windows Installer GPO Restriction

GPO path: Computer Configuration → Administrative Templates → Windows Components → Windows Installer → Turn off Windows Installer

There are three values. Set it to For non-managed apps only (value 1). This blocks user-initiated MSI installs while preserving IT-pushed software. Do not set it to Always — that disables Windows Installer for all accounts, including your own admin account when you need to push software.

Also enable Prohibit User Installs (Computer Configuration → Administrative Templates → Windows Components → Windows Installer → Prohibit User Installs) to block the per-user MSI installation branch entirely.

• Pros: free, low maintenance, works on all editions
• Cons: only covers MSI-based installs (does nothing for per-user packaged apps)

If the GPO applies but users can still install apps, check whether those apps use per-user packaging. The Windows Installer restriction only covers MSI installs to system directories.

Method 3: UAC Configuration

GPO path: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

Set Behavior of the elevation prompt for standard users to Automatically deny elevation requests. Set Detect application installations and prompt for elevation to Enabled. This is how do I block a user account from installing software that requires elevation; the request gets denied silently.

Registry equivalent: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System → ConsentPromptBehaviorUser = 0

• Pros: blocks elevation attempts without a visible prompt, applies without domain infrastructure (local policy works)
• Cons: does nothing for per-user installers that don't request elevation at all

Method 4: Software Restriction Policies (SRP)  (Windows 10 Only)

GPO path: Computer Configuration → Windows Settings → Security Settings → Software Restriction Policies

Use Path Rules or Hash Rules with a security level of Disallowed. SRP gives you executable-level blocking on Windows 10 domain machines without needing AppLocker licensing.

One hard limitation: as of the std.rocks GPO guide (updated June 9, 2025), SRP silently ignores policy on Windows 11. It doesn't generate errors — it just does nothing. If you're running a mixed Windows 10/11 fleet, organizations are frequently getting caught mid-migration when SRP suddenly stops applying on upgraded machines.

• Pros: built into Windows 10, no extra licensing
• Cons: dead on Windows 11, hash rules break on app updates, no replacement path within SRP itself

Method 5: AppLocker

First, correct a common misconception: since a February 2023 cumulative update, AppLocker policy enforcement applies to all Windows 10 and 11 editions including Pro. The Enterprise-only enforcement requirement no longer applies. Many IT admins on Pro licenses have been skipping AppLocker because of outdated information.

GPO path: Computer Configuration → Windows Settings → Security Settings → Application Control Policies → AppLocker

Before you configure any rules: set the Application Identity Service (AppIDSvc) to start automatically via GPO. AppLocker silently does nothing if AppIDSvc isn't running — it defaults to Manual start and this is the most common cause of "I configured AppLocker but nothing is being blocked."

To close the per-user install loophole, create Executable Rules targeting %USERPROFILE%\AppData and Downloads. Use Publisher rules, not Path rules. Path rules are fast to set up but will block both Spotify and legitimate corporate apps that correctly install to user-writable directories. Publisher rules match by code-signing certificate, so you can block unknown/unsigned executables from those paths while allowing known, signed business apps.

AppLocker's default rules are Allow rules — they permit execution from Program Files and the Windows directory. Without also enabling enforcement mode and adding deny rules for user-writable paths, the default rules do nothing to restrict users. Use "Deny / Authenticated Users" in deny rules, not "Deny / Everyone" — the latter blocks admins too.

AppLocker receives security fixes only, with no new feature development — Microsoft directs long-term investment to App Control for Business. Managing the transition from AppLocker to App Control for Business across a mixed fleet is one of the operational cases where MDM policy orchestration reduces the manual overhead.

Critical warning as of July 2025: Creating AppLocker EXE rules on Windows 11 24H2 breaks the Start Menu, Settings app, and Microsoft Teams. No cumulative update available as of July 14, 2025 resolved this. Hold off on AppLocker EXE rules for 24H2 machines, or move to App Control for Business instead.

• Pros: granular user/group-level control, free on all supported editions since February 2023
• Cons: 24H2 EXE rule breakage (as of July 2025), maintenance-mode only, requires AppIDSvc management

If AppLocker rules appear in Event Viewer but nothing is being blocked, check that AppIDSvc is set to Automatic and is actively running — not just installed.

Method 6: App Control for Business (Formerly WDAC)

App Control for Business is the forward-looking choice. Microsoft actively develops it while AppLocker receives security fixes only. As of Windows 11 24H2, it supports blocking unsigned scripts and MSI files and can enforce PowerShell Constrained Language Mode. In August 2025, App Control for Business reached general availability in Intune, with Managed Installer policy moving to group-targeted assignment — meaning you can now pilot restrictions on specific device groups before a full rollout.

The core difference from AppLocker: App Control for Business is default deny. Everything not explicitly approved is blocked. AppLocker is default allow — you're blocklisting. Default deny is the stronger posture.

Deploy in Audit mode first. Audit mode logs what would be blocked without actually blocking it. Practitioners who skip Audit mode and go directly to Enforcement consistently report production failures — remote support software blocked at the DLL level, Intune-delivered apps failing post-install, error code 65000 with no actionable detail. Run Audit mode for at least 90 days in complex environments before switching to Enforcement.

Managed Installer automatically trusts apps deployed through Intune, which reduces the ongoing rule-maintenance cost that makes full whitelisting impractical for small teams.

• Pros: kernel-level control, default deny, actively developed, blocks unsigned scripts, reputation-based trust via Intelligent Security Graph
• Cons: complex to deploy, requires Audit mode runway, Intune or ConfigMgr for scalable management, error messages can be opaque

If App Control for Business blocks apps deployed through Intune's Managed Installer, verify that the Managed Installer policy was applied before the app was installed — App Control evaluates trust at install time, not retroactively.

One second-order consequence to plan for: once you enforce App Control for Business, any app update that changes the publisher's signing certificate will cause that app to block. Build an update-testing step into your patch workflow before you flip enforcement on.

Method 7: Mobile Device Management

MDM is the layer that manages all of the above at scale. For how to restrict a user from downloading apps on Windows across a fleet, this is the most operationally sustainable path — enforcement travels with the device, not the network.

Key Intune CSPs to configure:

• BlockNonAdminUserInstall → value 1 (blocks non-admin installs; applies to Windows 10 Enterprise/Education 2004 and later)
• MSIAllowUserControlOverInstall → Block
• MSIAlwaysInstallWithElevatedPrivileges → Block

In Intune, create a Windows Configuration Profile → Device Restrictions → set "Apps from store only" to Store Only, "User control over installations" to Block, and "Install apps with elevated privileges" to Block.

One gap that surprises admins: blocking the Microsoft Store UI does not block the winget CLI. Standard users can run winget install to install per-user packages from the command line even when the Store is fully blocked via policy. Block winget by creating a registry key at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\winget.exe. The Intune CSP EnableWindowsPackageManagerCommandLineInterfaces is an emerging option but not yet widely validated as of mid-2025.

MDM platforms like Trio MDM let you enforce allow/block software policies across your entire Windows fleet from a single console, with per-device-group targeting so you can pilot restrictions before rolling them out company-wide. For centralized windows device management, MDM also gives you an auditable record of every software change — something GPO alone doesn't provide.

• Pros: centralized enforcement, auditable, scales without per-machine GPO work, app catalog reduces help desk load
• Cons: BlockNonAdminUserInstall CSP requires Enterprise/Education 2004+; MDM works best as the policy orchestration layer paired with AppLocker or App Control for Business — which is exactly the layered stack this guide recommends

Which Method Fits Your Setup

The table above shows how each method handles block a specific program from being installed in windows and what each one misses. Use the decision tree below to match your environment to the right combination.

The Gaps GPO Alone Won't Fix

Even a well-configured GPO stack leaves three gaps open. Uncontrolled installation vectors are a direct contributor to insider risk; each of these gaps creates a path that unauthorized software or inadvertent data exposure can exploit.

The goal when you need to stop employees from installing software on Windows isn't a single policy, it's a layered set of controls that catches what any individual method misses.

Gap 1: The per-user installer loophole. This is the most common practical failure. Apps packaged for user-profile installation bypass every Windows Installer restriction you set. AppLocker Executable Rules targeting %USERPROFILE%\AppData is the specific fix, but only if you use Publisher rules rather than Path rules.

Gap 2: Winget CLI bypass. Blocking the Microsoft Store UI and blocking winget are two separate controls. If you've blocked the Store but users are still installing apps via the command line, winget is almost certainly the channel. Block it by creating a registry key under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\winget.exe.

Gap 3: Portable applications. Apps that run without installing — from a Downloads folder or USB drive — are not stopped by any installer-level control. To address the USB vector, add Computer Configuration → Administrative Templates → System → Removable Storage Access as a complementary GPO. This doesn't get mentioned in most guides on this topic, but it closes the portable-app bypass for devices that otherwise look fully locked down.

If unauthorized software does reach a device and creates a security incident, having MDM in place means you can remote lock windows pc or trigger a remote wipe windows 10 without physical access — a containment capability GPO alone cannot give you.

Before You Flip the Switch: The Organizational Layer

The biggest reason software restriction projects stall is that IT announces the policy before leadership has committed to it in writing. Technical controls get reversed when executives opt out — and they will if they weren't part of the decision.

Get executive sign-off first. Practitioners who have successfully removed local admin company-wide consistently name this as the prerequisite. Have the CEO communicate the change at an all-hands — leadership visibly subject to the same policy removes the most common objection.

Have HR/Legal own the Acceptable Use Policy. The AUP should not be an IT document. HR and Legal draft it with IT input, and employees sign it as a condition of employment. When a policy violation occurs, HR can act on a document they own. Violations against an IT-written policy get routed back to IT to "fix technically" instead.

Plan for legitimate exceptions using EPM. Developers and contractors often need elevation for specific tasks. Blanket local admin removal without a just-in-time elevation option creates real productivity friction and political resistance. Microsoft Intune's Endpoint Privilege Management handles this — users can request time-limited elevated sessions for approved tasks. That exception management sits naturally inside a broader unified endpoint management framework that governs both standard users and privileged exceptions from a single policy layer.

How Trio MDM Helps You Control Software on Windows

Trio MDM gives IT admins practical tools to stop employees from installing software on Windows at the policy level, not just the device level.

The Software Policy feature lets you build application allow/block controls at the device or device group level. Policies pull from the Trio software library or from apps already installed on enrolled devices — so you're working from your actual fleet inventory, not a theoretical list. That means policy enforcement starts from reality, and updates as your fleet evolves without requiring GPO edits. The Trio App Catalog provides a curated, maintained set of applications admins can deploy to Windows devices directly — reducing the rule-maintenance burden that full whitelisting typically creates.

For Windows devices, Trio MDM supports simultaneous MDM and RMM agent enrollment. MDM handles policy enforcement; the RMM agent fills the areas MDM alone can't reach — real-time monitoring, remote configuration, and enforcement gaps that appear at the OS level. All software activity is tracked in event logs: software added, updated, assigned, and removed — giving you a documented record of every change across your fleet.

You can start your free trial with no minimum device requirement, or book a demo to see the software policy and app catalog features in your own environment before committing.