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.
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.
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.