Windows AppLocker is a security feature that allows administrators to manage application access. By creating rules based on file path, file publisher, file hash, or signing certificate, you can choose which apps to block or allow on your Windows endpoints. Swif’s Windows AppLocker Policy makes it easy to set up these rules in a few clicks and deploy them to your managed devices.
Requirements
Windows Pro 10+
Windows Enterprise 10+
Windows Education 10+
Windows SE 10+
IoT Enterprise / IoT Enterprise LTSC 10+
Any device you target with this policy must run one of the above Windows editions and be enrolled in Swif.
Creating and Deploying a Windows AppLocker Policy in Swif
1. Create a New Policy
In the Swif Admin Console, go to Device Management > Policies.
Click + Create Policy (or a similar button, depending on your portal layout).
Select Windows AppLocker Policy as the policy type.
Enter a Policy Name (e.g., “Block Specific Apps”) and a Policy Description (for reference).
2. Specify Rule Collections
Under Settings, you’ll see a section called Rule Collections. A “rule collection” is a category of files that you want to control:
Exe: Standard Win32 executables (
.exe).Script: Scripts, such as PowerShell (
.ps1), VBScript (.vbs), JavaScript (.js), etc.Appx: Modern Windows apps distributed as
.appxpackages (e.g., Microsoft Store apps).Dll: Dynamic Link Libraries.
Msi: Microsoft Installer packages (
.msi), used for installing traditional Windows programs.
Click Add to create a new rule collection.
Choose the Rule Collection Type (e.g.,
Exeif you want to block a specific.exe).You can add multiple rule collections if you want to control multiple file types under the same policy.
3. Define Rules
Inside each rule collection, you create rules that specify Allow or Deny for certain files:
Click + Add next to Rules.
From the Action dropdown, select Deny or Allow depending on your goal.
Deny: Blocks the specified applications from running.
Allow: Whitelists the specified applications so they can run, even if other rules might block them.
Add match conditions for the files you want to target. You can combine multiple conditions if needed:
File Path: Block or allow everything under a certain directory path (e.g.,
C:\\Program Files\\Example\\App.exe).File Publisher: Use certificate publisher info (e.g., “O=Microsoft Corporation”) to block or allow all apps signed by that publisher.
File Hash: Target a specific file’s cryptographic hash. This is useful if the path or publisher might change, but you want to block an exact file.
Tip: If you’re not sure which condition is best, File Publisher is handy for broad restrictions (like blocking all executables from an unknown publisher), while File Hash or File Path is ideal for precise targeting (blocking just one malicious .exe).
4. Finalize and Review
After adding your rules, click Continue (or Next) at the bottom.
Select which devices or device groups you want this policy to apply to.
Review the policy settings in the summary screen.
Click Finish or Save to deploy the policy.
Here’s an additional section you can add to the Windows Application Blocking Policy help article to explain Rule Conditions clearly:
Rule Conditions in Windows Application Blocking
When creating application blocking rules, Swif.ai leverages the same AppLocker rule conditions used in Windows. These conditions define how applications are identified and controlled. Understanding them helps administrators create precise policies that balance security with flexibility.
1. Publisher Condition
Identifies an application based on its digital signature.
You can specify:
Publisher (e.g., Microsoft, Adobe)
Product name (e.g., Microsoft Office)
File name (e.g., Word.exe)
File version or version range
Best for: Allowing or blocking all applications from a specific vendor, or only specific signed versions.
Example: Block all versions of
Zoom.exesigned by Zoom Video Communications, Inc.
2. Path Condition
Identifies an application by its location in the file system.
Can apply to:
Local paths (e.g.,
C:\Program Files\ExampleApp\app.exe)Removable media (e.g.,
E:\*)Network shares (e.g.,
\\Server\Share\*)
Best for: Blocking apps that are run from non-standard directories such as Downloads or removable drives.
Example: Block all executables from
%USERPROFILE%\Downloads\*.
3. File Hash Condition
Identifies an application by a cryptographic hash of its file.
Hash is unique to the file’s exact binary contents.
Best for: Blocking a specific file that is not digitally signed or may change locations.
Limitation: If the file is updated or patched, its hash changes and the rule no longer applies—requiring an updated policy.
Example: Block a specific malicious executable by its SHA-256 hash.
Choosing the Right Rule Condition
Publisher → Flexible and auto-updates with vendor’s new versions (if allowed).
Path → Simple and useful for blocking executables from unsafe locations.
File Hash → Precise targeting of individual files, especially unsigned ones.
Rule Conditions Comparison
Condition | How It Works | Best Use Case | Pros | Cons |
Publisher | Matches based on the app’s digital signature (vendor, product, file, version). | Enforcing policies for trusted vendors (e.g., Microsoft Office, Adobe). | - Auto-applies to new versions from same publisher.- Easier long-term maintenance. | - Requires app to be digitally signed.- Some small vendors may not sign apps. |
Path | Matches based on the file system location of the app (local, removable, network path). | Blocking apps in risky locations like Downloads or USB drives. | - Simple to configure.- Covers entire folders or drives. | - If app is copied to a new path, the rule no longer applies. |
File Hash | Matches based on a cryptographic hash of the file’s binary contents. | Blocking a specific executable (e.g., a known malicious file). | - Works even if the app is unsigned.- Very precise targeting. | - Needs updating whenever the file changes (patches/updates alter the hash).- High maintenance. |
👉 Tip: Use Publisher rules for most production apps, Path rules for location-based controls, and File Hash only when targeting unique or unsigned binaries.
Example: Blocking a Specific EXE by File Path
Suppose you want to block the app C:\Users\<username>\Downloads\MalwareSample.exe.
Create a Windows AppLocker Policy named “Block MalwareSample.”
In Rule Collections, choose Exe.
Add a new rule:
Action: Deny
File Path:
C:\Users\*\Downloads\MalwareSample.exe
Save and deploy to your Windows devices. Once applied, Windows will prevent that
.exefrom executing.
Example: Blocking All Script Files from a Non-Microsoft Publisher
You can also protect your organization from unknown PowerShell scripts or .vbs scripts:
Create a Script rule collection.
Add a rule with:
Action: Deny
File Publisher: anything that doesn’t match “Microsoft” (or specify a known safe publisher).
This effectively denies scripts unless they’re signed by the trusted publisher.
Alternatively, you can do the inverse: Allow only scripts signed by a recognized publisher, then block everything else using a Deny rule.
Example: Blocking all apps but allowing one app
Rule Condition Type: Appx
Rule 1:
Rule Name: DenyAll
Apply To Administrators: True
Action: Deny
File Publisher:
Conditions > Publisher Name:
*Conditions > Product Name:
*Conditions > Binary Name:
*
Rule 2:
Rule Name: AllowCalculator
Apply To Administrators: True
Action: Allow
File Publisher:
Conditions > Publisher Name:
*Conditions > Product Name:
Microsoft.WindowsCalculatorConditions > Binary Name:
*
Managing or Updating Rules
To modify the rules in an existing policy:
Go to Device Management > Policies.
Find your Windows AppLocker Policy and click Edit.
Add or remove rule collections, or update the Rules (Deny/Allow, file conditions).
Re-deploy the updated policy to the desired devices.
Troubleshooting & Tips
Policy Precedence: If multiple AppLocker policies apply to the same device, the most restrictive rule tends to block the application. Make sure to keep track of all active rules.
Testing: Before rolling out to a large group, apply the policy to a test device. Verify that only the intended apps are blocked or allowed.
Maintaining a Baseline: For maximum security, you could create a broad Deny rule for many file types (e.g., unknown executables), then add Allow rules for whitelisted software (e.g., your official productivity apps). However, this can be complex to maintain if users need to install new software regularly.
Windows Editions: This policy requires Windows Pro 10+, Windows Enterprise 10+, etc. If a device is running Windows Home, the policy cannot enforce AppLocker.
Updating/Installing Apps: Blocking an
.msior.exewill prevent both running the app and updating it, since Windows typically uses the same file for installations or updates. If you need to allow updates for certain software, consider an Allow rule for that publisher or file path.
Conclusion
Swif’s Windows AppLocker Policy provides a straightforward way to control which applications can run on your organization’s Windows devices. By setting Allow or Deny rules based on file paths, publisher info, or file hashes, you can block unwanted executables, scripts, or installers—just as you already can with Swif’s macOS application blocking feature.
If you need further help configuring Windows AppLocker policies or troubleshooting blocked apps, don’t hesitate to contact Swif Support.
Swif Policy glossary – see All Windows policies article for context.