Block Specific Apps for Standard Users with AppLocker in Windows 10 and 11

This guide configures a local AppLocker policy through Local Security Policy (secpol.msc). It is aimed at a shared PC with a trusted administrator account and one or more standard-user accounts.

Important: AppLocker is application control, not a magic lock against administrators. A person with local administrator rights can change local AppLocker policy, start or stop the related service, or otherwise alter the PC. Keep restricted users as standard users.

Click to expand...

Before you begin​

You need:

• A Windows 10 version 2004 or later PC, or any supported Windows 11 PC.
• An administrator account.
• A test account that represents the person or group being restricted.
• The application file or installer you intend to block, if you plan to create a publisher rule.

Microsoft’s current AppLocker documentation says that, following KB5024351, Windows 10 version 2004 and later plus all Windows 11 editions can enforce AppLocker policies. Local rules can be managed in Local Security Policy, while centrally managed PCs should ordinarily use Group Policy or MDM instead.

Know which file type you are blocking​

AppLocker separates policies into rule collections. The collection matters; blocking an .exe does not automatically block an .msi installer or a PowerShell script.

For the usual “do not let this person launch this program” scenario, start with Executable Rules. If the concern is installation, create a matching rule under Windows Installer Rules for MSI-based installers as well. Plenty of installers are ordinary .exe files, because apparently even setup programs enjoy making life interesting.

Step 1: Start the Application Identity service​

AppLocker relies on the Application Identity service (AppIDSvc). If it is not running, AppLocker rules are not enforced.

On Windows 10 and Windows 11, Microsoft notes that Application Identity is a protected process, so changing its startup type through the ordinary Services console may not work as expected.

• Open Windows Terminal (Admin), PowerShell (Admin), or Command Prompt (Admin).
• Run:
  sc.exe config appidsvc start= auto
• Start the service:
  sc.exe start appidsvc
• Confirm it is running:
  sc.exe query appidsvc
  Look for STATE showing RUNNING.

You can also open Task Manager, select the Services tab, locate AppIDSvc, right-click it, and choose Start.

Why this matters: Microsoft’s AppLocker documentation is unambiguous here: stopping Application Identity prevents AppLocker policies from being enforced. A beautifully crafted deny rule with a stopped service is just decorative bureaucracy.

Step 2: Open the local AppLocker console​

• Press Win + R.
• Type:
  secpol.msc
• Select OK and approve the UAC prompt.
• In the left pane, expand:
  
  Code:

  Application Control Policies
  > AppLocker

You should now see the available rule collections, including Executable Rules, Windows Installer Rules, Script Rules, and Packaged app Rules.

If this PC is joined to an organization, pause before changing anything. Microsoft explains that local AppLocker rules are merged with applicable Group Policy rules, and GPO enforcement settings take precedence over local settings. In plain English: a corporate policy may be part of the story even when you are editing the local machine.

Step 3: Create the default allow rules first​

This is the safety rail that keeps a narrow blocking policy from becoming an accidental “block nearly everything” policy.

The moment a rule collection contains rules, AppLocker behaves as an allow-list for that collection: apps must match an allow rule and must not match a deny rule. Microsoft explicitly warns that default rules are starter rules, but they are the correct foundation for a local, targeted deny-policy setup.

For Executable Rules:

• Right-click Executable Rules.
• Select Create Default Rules.

Windows creates three standard executable allow rules:

• Allow local Administrators to run all executable files.
• Allow Everyone to run executable files in the Windows folder.
• Allow Everyone to run executable files in Program Files.

Repeat this only for collections you plan to configure. For example:

• Create default rules under Windows Installer Rules if you will block an MSI package.
• Create default rules under Script Rules only if you intend to manage script execution.
• Do not casually enable DLL Rules. DLL control is more demanding because applications may require many supporting DLLs, and an incomplete allow-list can cause confusing failures.

A crucial caution about default rules​

Microsoft describes the defaults as a template for initial testing, not a complete hardened policy. In particular, the broad Windows-folder allow rule can include locations where standard users may be able to write files, such as parts of C:\Windows\Temp. That is one reason this guide uses narrow deny rules for a shared-PC scenario instead of claiming the defaults constitute a high-security allow-list.

Step 4: Create a targeted deny rule​

You have three practical ways to identify the app:

For most signed applications, choose a publisher rule. It can survive routine application updates if you set its scope carefully. For a one-off downloaded installer or internal executable that will not move, a path rule can be acceptable—but only if the target user cannot write to or alter that location.

Option A: Block a signed application with a publisher rule​

• Under Executable Rules, right-click an empty area and select Create New Rule.
• Select Next on the introduction page.
• On Permissions:
• Select Deny.
• Select Select beside User or group.
• Enter the specific local user, or choose a local group used for restricted accounts.
• Select Next.
• On Conditions, choose Publisher and select Next.
• Select Browse, then choose the program’s signed .exe file.
• Use the scope selector to choose what to block:
• Publisher blocks software broadly from that publisher. Use this sparingly.
• Product name is usually a more focused choice.
• File name targets the specific executable.
• File version can target a particular range, but may require maintenance after updates.
• Select Next.
• On Exceptions, add an exception only if you have a well-tested reason.
• Give the rule a clear name, such as:
  Deny Contoso Remote Tool for Shared-PC Users
• Select Create.

Publisher rules work only when the target file is digitally signed. Microsoft’s AppLocker guidance confirms that publisher conditions use a file’s digital signature and can be scoped by publisher, product, filename, and version.

Option B: Block an app or installer by path​

Use this for a file in a location controlled by administrators, such as a locked-down folder under Program Files.

• Under the relevant collection—usually Executable Rules or Windows Installer Rules—select Create New Rule.
• Set the action to Deny and select the restricted user or group.
• Choose the Path condition.
• Enter or browse to the target file or folder.
• Name the rule clearly and create it.

Example target:

C:\Program Files\ExampleApp\ExampleApp.exe

Do not treat a path rule as a robust way to ban a portable executable from a user who can copy it elsewhere. Microsoft specifically cautions that path-based deny rules are easier to evade: the file can simply be moved to a different location. Likewise, never create broad allow rules for folders writable by standard users, such as user profiles or general download folders.

Step 5: Test in Audit Only mode​

Before enforcing rules on a PC someone actually needs to use, run the relevant collection in Audit only mode.

• In the left pane, right-click AppLocker and select Properties.
• Open the Enforcement tab.
• Find the collection you changed—for example, Executable Rules.
• Check Configured.
• Select Audit only.
• Select OK.
• Sign in as the restricted user and try to launch the target app.
• Also test normal workflow applications: browser, Office apps if present, line-of-business tools, printers, and any software that the account needs.

Audit mode evaluates the policy but does not block the launch. It writes the result to the AppLocker event logs, which is vastly preferable to discovering that you have blocked payroll, VPN access, or the browser five minutes before a meeting.

Step 6: Review AppLocker events​

Open Event Viewer and browse to:

Applications and Services Logs
> Microsoft
> Windows
> AppLocker

The most useful channels are usually:

• EXE and DLL
• MSI and Script
• Packaged app-Deployment
• Packaged app-Execution

In audit mode, Microsoft documents Event ID 8003 for an executable or DLL that would have been blocked if enforcement were active. Once you enforce the rule, Event ID 8004 indicates that an executable or DLL was prevented from running.

Review the filename, user, and rule information. If an essential program would be blocked, revise the rule before continuing.

Step 7: Turn on enforcement​

When testing shows the rule is scoped correctly:

• Return to Local Security Policy.
• Right-click AppLocker and choose Properties.
• Open the Enforcement tab.
• For the applicable collection, ensure Configured is checked.
• Change Audit only to Enforce rules.
• Select OK.

Enforcement takes effect immediately for the local policy. Test again with the restricted account. A blocked executable should fail to launch, and Event Viewer should record the decision.

Remember: deny wins. If a file matches both an allow rule and a deny rule for the user, the deny rule takes precedence. That is helpful when a default rule permits Program Files but you need to deny one particular executable inside it.

Troubleshooting checklist​

The app still runs​

Check these in order:

• Application Identity is running.
  Run sc.exe query appidsvc.
• You used the right collection.
  An MSI needs a Windows Installer rule; a PowerShell script needs a Script rule; a packaged Store app needs a Packaged app rule.
• The collection is enforced.
  In AppLocker Properties, verify it is set to Configured and Enforce rules.
• The rule targets the right user or group.
  Test while signed in as that exact account. User-based policy is the whole point here.
• The rule identifies the actual launched file.
  Some shortcuts launch a helper executable, updater, or app launcher rather than the file you first selected.
• A domain policy is involved.
  On managed machines, local and Group Policy rules can combine, and Group Policy enforcement settings take precedence.

The rule blocks too much​

Switch the affected collection back to Audit only or delete/disable the overly broad rule. Then reduce its scope:

• Prefer a product or filename publisher condition instead of blocking an entire publisher.
• Replace a folder-level deny rule with one for the specific executable.
• For an exact, rarely updated file, consider a file hash rule—but expect to replace it after every update.

What this setup does—and does not—solve​

A local AppLocker deny rule is excellent for a shared household, kiosk-like workstation, lab PC, or small office machine where specific standard accounts should not run designated software. It is not a substitute for endpoint security, patching, account management, or a centrally managed application-control strategy.

For a larger fleet, move the policy into Active Directory Group Policy, Microsoft Intune, or another managed deployment workflow. For a single shared PC, however, this is a practical and well-supported way to stop a specific application at launch—without spending the afternoon playing whack-a-mole with shortcuts.