AppLocker still ships in Windows 11, still works, and still ranks as one of the most searched Windows lockdown tools, but Microsoft has stopped adding features to it. As of October 28, 2026, the company’s documentation says AppLocker receives security fixes only, while App Control for Business is the preferred application control system. That changes how you should build an AppLocker Windows 11 policy today: start in audit mode, keep the rule set small, and plan the exit path to App Control.
This tutorial walks through 13 steps in about 50 minutes. You will create default rules, add publisher rules for the software you trust, run the policy in audit mode, read the evidence from Event Viewer and PowerShell, then switch to enforcement with a rollback plan. Microsoft’s App Control debugging and troubleshooting guide is the page to bookmark once you start that migration, and the later sections show how to run an App Control audit policy next to AppLocker.
If you already forward endpoint telemetry through a Sysmon setup that flags ransomware behavior, AppLocker adds the other half of the picture. Sysmon records what ran. AppLocker decides what is allowed to run in the first place. Together they give you prevention and detection on the same machine.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What AppLocker Does on Windows 11 in October 2026
AppLocker lets you control which apps and files users can run. Per Microsoft’s documentation, that covers executable files, scripts, Windows Installer files, DLLs, packaged apps, and packaged app installers. Microsoft introduced it with Windows 7, and it remains available on Windows 11, Windows 10, and Windows Server 2016 and later. Rules can key off the publisher in a digital signature, the file path, or a file hash.
Two details shape every decision in this guide. First, Microsoft classes AppLocker as a defense-in-depth feature, not a defensible security boundary. That means a determined attacker with the right access can bypass it, and Microsoft will not treat every bypass as a vulnerability. Second, by default an AppLocker policy only applies to code launched in a user’s context. Microsoft documents a rule collection extension that extends policy to non-user processes such as those running as SYSTEM, which we cover in the advanced tips.
Windows 11 itself moved recently. Windows 11 version 26H2 became generally available on September 29, 2026. The latest listed build is 26300.9818, which arrived with the October 28 preview update (KB5127936). The October baseline update shipped as build 26300.9711 (KB5127648). Older Windows 11 releases, including 24H2 Home and Pro, may no longer receive updates, so check every machine in your fleet and upgrade it before you build policy on it.
Microsoft’s wording on AppLocker’s future is direct. The company says it is no longer investing in AppLocker. No source we checked reports a retirement, discontinuation, or rename. So AppLocker is supported, patched, and frozen. That is a reasonable state for a small shared PC, a lab, a kiosk, or a mixed fleet that still carries older Windows versions. It is a weaker choice for a new enterprise rollout.
AppLocker vs App Control for Business: Which One to Use
App Control for Business is the current name for what Microsoft first called Windows Defender Application Control (WDAC). The old name still appears in older blog posts and in some tooling, so expect to see both while you search for answers. Microsoft’s own comparison page says customers who can use App Control instead of AppLocker should do so, because App Control keeps getting improvements and wider support in Microsoft’s management platforms.
| Attribute | AppLocker | App Control for Business |
|---|---|---|
| Microsoft status (Oct. 28, 2026) | Security fixes only | Preferred application control system |
| Policy scope | Per user or per group rules possible | Device-wide, no per-user rules |
| Introduced with | Windows 7 | Windows 10 |
| Kernel-mode policy | Not supported | Supported |
| Trailing wildcards in paths | Not processed | Processed |
| Servicing classification | Defense in depth | Designed as a security feature |
| Management options | Group Policy, PowerShell, Intune custom OMA-URI, Configuration Manager | Intune, Configuration Manager, Group Policy, scripts |
| Main audit log | AppLocker event logs | CodeIntegrity Operational log |
Microsoft lists two cases where AppLocker still fits better. One is a mixed environment where you need the same controls on Windows 10 and older versions. The other is a shared computer where different users or groups need different policies. Microsoft also describes running AppLocker as a complement to App Control, so you enforce App Control at the strictest level your organization tolerates and then use AppLocker to fine-tune per-user restrictions.
The practical rule: if you manage a single Windows 11 PC, a family computer, or a small office with shared logins, AppLocker gets you results in under an hour. If you manage a fleet through Intune or Configuration Manager, build the same audit habit with App Control from day one. Both paths use the same discipline of audit first, then enforce, which is why this guide teaches that discipline with AppLocker and then shows the App Control equivalent.
Prerequisites and Versions You Need
Gather these before you touch a policy. Use a virtual machine or a spare PC for the first run. A bad enforced policy can block software you need, and the cleanest recovery path is a snapshot.
| Requirement | Version or detail | Why it matters |
|---|---|---|
| Windows 11 | Version 26H2 (GA Sept. 29, 2026), latest listed build 26300.9818 | Current feature release, fully supported for Home and Pro |
| Older Windows 11 | 25H2 also supported, 24H2 Home and Pro out of support since Oct. 13, 2026 | Do not build policy on an unsupported build |
| Edition | Pro, Enterprise, or Education | Provides the Local Security Policy editor (secpol.msc) |
| Rights | Local administrator | Required to set policy and start the service |
| Shell for AppLocker cmdlets | Windows PowerShell 5.1 (inbox) | The AppLocker module loads natively here |
| Optional shell | PowerShell 7.6 LTS | PowerShell 7.4 and later logs App Control audit restrictions |
| Test account | One standard (non-admin) local user | Default rules let administrators run everything |
| Safety net | VM snapshot or restore point | Lets you undo a policy that blocks too much |
Microsoft’s current documentation says AppLocker policies are supported across editions on Windows 10 version 2004 and newer when KB 5024351 is installed, with older-version limits that depend on how you deploy. Windows 11 Home does not include the Local Security Policy editor, so Home users should follow the PowerShell route in steps 4 through 8 instead of the graphical console. Test enforcement on your exact edition before you rely on it.
PowerShell 7.4 or later is needed if you want the App Control audit analytic log described later, where it records would-be language restrictions in event 16387.
Why Application Allowlisting Pays Off Before You Start
Most endpoint compromises need to run something new. A dropped executable, a script in a temp folder, a renamed installer. Allowlisting breaks that step by default. When a standard user cannot launch a binary from Downloads or AppData, a large share of commodity malware simply stops working, even if it slips past antivirus. That is the case for spending 50 minutes here.
Allowlisting also pairs with other hardening. If you already followed a guide to secure Windows RDP against brute-force attacks, an attacker who guesses a weak password still faces an allowlist that blocks their tooling. For wider planning, our overview of cybersecurity prevention for your business shows where allowlisting fits among the other layers.
One caution before the steps. Microsoft warns that audit data does not prove an application is approved, and it does not show that every code path ran during your test window. Treat the audit period as evidence, not proof, and keep reviewing after you enforce.
Phase 1: Prepare the Machine (Steps 1 to 3)
Step 1: Confirm your Windows build and edition. Open Windows PowerShell as administrator and read the version data. You want a supported feature release and a note of the exact build, because you will compare it later if a servicing update changes behavior.
Get-ComputerInfo -Property WindowsProductName, WindowsVersion, OsBuildNumber
$PSVersionTable.PSEdition
(Get-Command Get-AppLockerPolicy).SourceExample output on a Windows 11 26H2 machine (your values will differ):
WindowsProductName : Windows 11 Pro
WindowsVersion : 26H2
OsBuildNumber : 26300
Desktop
AppLockerIf the last line prints nothing, the AppLocker module is not available in your shell. Reopen Windows PowerShell 5.1 rather than PowerShell 7 and try again.
Step 2: Back up the current policy and create a restore point. Export whatever policy exists today, even if it is empty. This file is your rollback target in step 12.
New-Item -ItemType Directory -Path C:\AppLockerLab -Force | Out-Null
Get-AppLockerPolicy -Local -Xml | Out-File C:\AppLockerLab\policy-before.xml -Encoding utf8
Enable-ComputerRestore -Drive "C:\"
Checkpoint-Computer -Description "Before AppLocker" -RestorePointType MODIFY_SETTINGSWindows limits how often it creates restore points, so Checkpoint-Computer may skip with a warning if one was made recently. On a virtual machine, take a hypervisor snapshot instead and skip the last two lines.
Step 3: Start the Application Identity service and set it to automatic. AppLocker does nothing without this service, which is the single most common reason a correct policy appears to be ignored. Microsoft documents the service (appidsvc) as running under the LocalServiceAndNoImpersonation account.
sc.exe config appidsvc start= auto
sc.exe start appidsvc
Get-Service appidsvc | Select-Object Name, Status, StartTypeName Status StartType
---- ------ ---------
appidsvc Running AutomaticUse sc.exe here instead of Set-Service. On current Windows builds the service is protected, and Set-Service often fails with an access denied error even in an elevated shell.
Phase 2: Build the AppLocker Rules (Steps 4 to 7)
Step 4: Create the default rules. Default rules keep Windows and your installed programs working. They allow everyone to run files under the Windows folder and Program Files, and they allow local administrators to run anything. AppLocker defines four collections you will use: Executable, Windows Installer, Script, and Packaged app. A fifth collection for DLLs exists, but it adds load and is easy to misconfigure, so leave it off until you have audited a while.
On Pro, Enterprise, or Education, press Win+R, run secpol.msc, expand Application Control Policies, select AppLocker, and click Create Default Rules under each collection. Home users and anyone scripting this should import the XML below instead. Save it as C:\AppLockerLab\defaults.xml.
<AppLockerPolicy Version="1">
<RuleCollection Type="Appx" EnforcementMode="AuditOnly">
<FilePublisherRule Id="a9e18c21-ff8f-43cf-b9fc-db40eed693ba" Name="(Default Rule) All signed packaged apps" Description="Allows Everyone to run signed packaged apps." UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
<BinaryVersionRange LowSection="0.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<FilePathRule Id="921cc481-6e17-4653-8f75-050b80acca20" Name="(Default Rule) Program Files" Description="Everyone, Program Files" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions><FilePathCondition Path="%PROGRAMFILES%\*" /></Conditions>
</FilePathRule>
<FilePathRule Id="a61c8b2c-a319-4cd0-9690-d2177cad7b51" Name="(Default Rule) Windows folder" Description="Everyone, Windows" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions><FilePathCondition Path="%WINDIR%\*" /></Conditions>
</FilePathRule>
<FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) Administrators" Description="Administrators, all files" UserOrGroupSid="S-1-5-32-544" Action="Allow">
<Conditions><FilePathCondition Path="*" /></Conditions>
</FilePathRule>
</RuleCollection>
<RuleCollection Type="Msi" EnforcementMode="AuditOnly">
<FilePublisherRule Id="b7af7102-efde-4369-8a89-7a6a392d1473" Name="(Default Rule) Signed installers" Description="Everyone, signed MSI" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*">
<BinaryVersionRange LowSection="0.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePathRule Id="5b290184-345a-4453-b184-45305f6d9a54" Name="(Default Rule) Windows Installer cache" Description="Everyone, Installer folder" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions><FilePathCondition Path="%WINDIR%\Installer\*" /></Conditions>
</FilePathRule>
<FilePathRule Id="64ad46ff-0d71-4fa0-a30b-3f3d30c5433d" Name="(Default Rule) Administrators, all installers" Description="Administrators" UserOrGroupSid="S-1-5-32-544" Action="Allow">
<Conditions><FilePathCondition Path="*.*" /></Conditions>
</FilePathRule>
</RuleCollection>
<RuleCollection Type="Script" EnforcementMode="AuditOnly">
<FilePathRule Id="06dce67b-934c-454f-a263-2515c8796a5d" Name="(Default Rule) Scripts in Program Files" Description="Everyone" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions><FilePathCondition Path="%PROGRAMFILES%\*" /></Conditions>
</FilePathRule>
<FilePathRule Id="9428c672-5fc3-47f4-808a-a0011f36dd2c" Name="(Default Rule) Scripts in Windows" Description="Everyone" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions><FilePathCondition Path="%WINDIR%\*" /></Conditions>
</FilePathRule>
<FilePathRule Id="ed97d0cb-15ff-430f-b82c-8d7832957725" Name="(Default Rule) Administrators, all scripts" Description="Administrators" UserOrGroupSid="S-1-5-32-544" Action="Allow">
<Conditions><FilePathCondition Path="*" /></Conditions>
</FilePathRule>
</RuleCollection>
</AppLockerPolicy>Every collection carries EnforcementMode=”AuditOnly”. That is deliberate. Per Microsoft, audit-only mode lets affected apps run while recording the activity in the AppLocker event log, so the policy cannot lock you out while you learn what it would do.
Step 5: Validate and apply the policy in audit mode. Test-AppLockerPolicy checks a policy file against a sample file and a user before you apply anything. Then Set-AppLockerPolicy writes the policy to the local machine.
Test-AppLockerPolicy -XmlPolicy C:\AppLockerLab\defaults.xml -Path C:\Windows\System32\notepad.exe -User Everyone
Set-AppLockerPolicy -XmlPolicy C:\AppLockerLab\defaults.xml
gpupdate /force
Get-AppLockerPolicy -Effective | Select-Object -ExpandProperty RuleCollections | Select-Object RuleCollectionType, EnforcementModeFilePath PolicyDecision MatchingRule
-------- -------------- ------------
C:\Windows\System32\notepad.exe Allowed (Default Rule) Windows folderSet-AppLockerPolicy without an LDAP path targets the local policy. If you see an access denied error, your shell is not elevated.
Step 6: Add publisher rules for software that lives outside the default folders. Many apps install per user into AppData, including browsers, chat clients, and game launchers. Default rules do not cover those paths, so enforcement would block them. Generate publisher rules from the installed folder instead of allowing the whole AppData tree. Publisher rules follow the digital signature, so they survive app updates.
$apps = "$env:LOCALAPPDATA\Programs"
Get-AppLockerFileInformation -Directory $apps -Recurse -ErrorAction SilentlyContinue |
New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Optimize -IgnoreMissingFileInformation -Xml |
Out-File C:\AppLockerLab\extra.xml -Encoding utf8
Set-AppLockerPolicy -XmlPolicy C:\AppLockerLab\extra.xml -Merge
Get-AppLockerPolicy -Local -Xml | Select-String -Pattern "FilePublisherRule" | Measure-Object | Select-Object CountThe -Optimize switch collapses many files from one publisher into a single rule. The Hash fallback covers unsigned files, but hash rules break when the file changes, so review each one before you keep it. After the merge, Windows may reset a collection’s mode. Step 7 re-applies audit mode to every collection.
Step 7: Re-assert audit mode and create a standard test user. Read the local policy, set every collection to AuditOnly, and write it back. Then create a standard account. Default rules let administrators run anything, so an admin session will never show you what a normal user would hit.
$xmlPath = "C:\AppLockerLab\current.xml"
Get-AppLockerPolicy -Local -Xml | Out-File $xmlPath -Encoding utf8
[xml]$x = Get-Content $xmlPath -Raw
foreach ($rc in $x.AppLockerPolicy.RuleCollection) { $rc.EnforcementMode = "AuditOnly" }
$x.Save($xmlPath)
Set-AppLockerPolicy -XmlPolicy $xmlPath
$pw = Read-Host "Password for applocker-test" -AsSecureString
New-LocalUser -Name "applocker-test" -Password $pw -Description "AppLocker audit user"
Add-LocalGroupMember -Group "Users" -Member "applocker-test"Confirm the new account is not in the Administrators group with Get-LocalGroupMember -Group Administrators. Only a standard user shows the blocks that matter.
Publisher, Path, or Hash: Choosing the Right AppLocker Rule Type
Every rule you add in steps 6 and 11 falls into one of three types. Picking the wrong one is the most common reason a policy works on day one and breaks a month later. Microsoft’s documentation describes all three: publisher rules use attributes from the digital signature, path rules use the file location, and hash rules match one exact file.
| Rule type | Matches on | Survives app updates | Best use | Main risk |
|---|---|---|---|---|
| Publisher | Signer, product name, file name, version | Yes, if the vendor keeps signing | Browsers, office suites, launchers, line-of-business apps | Too broad if you allow every product from a large vendor |
| Path | Folder or file location | Yes | Program Files, the Windows folder, locked-down shares | Any user-writable path lets malware run from there |
| Hash | One exact file | No, every new build needs a new rule | Unsigned tools that rarely change | Breaks on every update, grows the policy quickly |
Start with publisher rules because they follow the signature and need the least upkeep. Narrow them the same way Microsoft’s rule model allows: name the publisher, then the product, then a file name or version range when the vendor ships many tools under one certificate. A rule that trusts a vendor’s entire catalog also trusts the vendor’s admin utilities, and you may not want standard users running those.
Use path rules only for locations a standard user cannot write to. The default rules for the Windows folder and Program Files meet that test. A path rule for a folder in the user profile, a temp directory, or a shared drive where everyone has write access fails it, because an attacker only needs to drop a file there. When in doubt, ask whether a standard user could copy a file into that folder. If yes, do not allow it by path.
Keep hash rules for the leftovers. A scanner utility from a small vendor, an unsigned internal tool, or a legacy installer might have no signature. Record the file name and the reason in the rule description so the next person who reviews the policy knows why it exists. Review every hash rule at each patch cycle, since a changed file silently stops matching and the user sees a block.
You can also write exceptions. Microsoft gives an example of a rule that lets all users run all Windows binaries except the Registry Editor (regedit.exe). Exceptions keep a broad allow rule honest. Use them sparingly, because every exception is another line to test when Windows updates.
Phase 3: Run Audit Mode and Read the Evidence (Steps 8 to 10)
Step 8: Generate test activity as the standard user. Sign in as applocker-test, or launch a shell as that user from your admin session. Run the things a normal day involves, then run a few things that should not be allowed. The goal is a mix of allowed activity and deliberate violations, so you can see both in the logs.
runas /user:applocker-test powershell.exe
# Inside that shell, as the standard user:
Copy-Item C:\Windows\System32\calc.exe $env:USERPROFILE\Downloads\calc-copy.exe
& "$env:USERPROFILE\Downloads\calc-copy.exe"
Set-Content -Path $env:USERPROFILE\Desktop\hello.ps1 -Value 'Write-Output "script ran"'
powershell.exe -ExecutionPolicy Bypass -File $env:USERPROFILE\Desktop\hello.ps1In audit mode both launches succeed. A copied executable in Downloads and a script on the Desktop fall outside every default allow rule, so each should produce an audit event saying the file would have been prevented under enforcement. Open one normal app from Program Files too, so you can confirm that allowed launches stay quiet or show as allowed.
Step 9: Find the events in Event Viewer. Open Event Viewer and go to Applications and Services Logs, then Microsoft, Windows, AppLocker. You will see separate logs per collection. The table below maps each log to what it holds, including the Code Integrity and PowerShell logs you will use if you add App Control.
| Log | Path in Event Viewer | What it records |
|---|---|---|
| EXE and DLL | Microsoft, Windows, AppLocker, EXE and DLL | Executable and DLL allow, audit, and block decisions |
| MSI and Script | Microsoft, Windows, AppLocker, MSI and Script | Installer and script decisions. Event 8028 flags script or MSI files that would fail enforcement |
| Packaged app | Microsoft, Windows, AppLocker, Packaged app logs | Store-style app execution and deployment decisions |
| Code Integrity (App Control) | Microsoft, Windows, CodeIntegrity, Operational | Event 3076 for audit would-block hits, 3077 for enforced blocks, 3089 for signature details, 3099 for policy load |
| PowerShell analytic | PowerShellCore, Analytic | Event 16387 on PowerShell 7.4 and later, for restrictions App Control enforcement would apply |
The PowerShell analytic channel is opt-in and separate from the AppLocker script log. Microsoft also cautions that a missing channel is not an empty result, so confirm the event provider is registered before you read silence as a clean audit.
Step 10: Query the audit events with PowerShell. Event Viewer is fine for a glance, but PowerShell turns hundreds of events into a ranked list. This query pulls audit-mode messages from the EXE and DLL and the MSI and Script logs, extracts the file path, and counts launches per file.
$logs = "Microsoft-Windows-AppLocker/EXE and DLL", "Microsoft-Windows-AppLocker/MSI and Script"
$since = (Get-Date).AddDays(-7)
$audit = foreach ($log in $logs) {
Get-WinEvent -FilterHashtable @{ LogName = $log; StartTime = $since } -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match "would have been prevented" } |
ForEach-Object {
[pscustomobject]@{
Time = $_.TimeCreated
Log = $log.Split("/")[1]
File = ($_.Message -split " was allowed to run")[0]
User = $_.UserId.Value
}
}
}
$audit | Group-Object File | Sort-Object Count -Descending |
Select-Object Count, Name | Format-Table -AutoSize -WrapCount Name
----- ----
3 C:\USERS\APPLOCKER-TEST\DOWNLOADS\CALC-COPY.EXE
1 C:\USERS\APPLOCKER-TEST\DESKTOP\HELLO.PS1Read this list as a to-do list. A guide on application allowlisting from ABT makes the same point about App Control audit events: each one is either an application your organization depends on that needs a rule, or something that should not be there at all. Sort each line into one of those two buckets before you write a single new rule.
How long should the audit period run?
For a personal PC, a week that includes a month-end task or two is enough. For a shared or business machine, run at least two full work cycles, and make sure rare workflows such as quarterly reports, driver updates, and annual tax software have run. Microsoft’s own warning applies here: audit data cannot prove that every code path was exercised. If a tool runs once a quarter, schedule a deliberate test of it.
Phase 4: Turn Audit Data into Rules, Then Enforce (Steps 11 to 13)
Step 11: Convert legitimate audit hits into rules. Get-AppLockerFileInformation can read audited events straight from a log and feed them to New-AppLockerPolicy. Review the output before merging. Anything in a user-writable folder that you cannot name should stay blocked.
Get-AppLockerFileInformation -EventLog -LogPath "Microsoft-Windows-AppLocker/EXE and DLL" -EventType Audited -Statistics |
Sort-Object Count -Descending | Select-Object -First 15
Get-AppLockerFileInformation -EventLog -LogPath "Microsoft-Windows-AppLocker/EXE and DLL" -EventType Audited |
New-AppLockerPolicy -RuleType Publisher -User Everyone -Optimize -IgnoreMissingFileInformation -Xml |
Out-File C:\AppLockerLab\suggested.xml -Encoding utf8
notepad C:\AppLockerLab\suggested.xmlOpen suggested.xml and delete any rule for a file you do not recognize. Keep publisher rules over hash rules whenever the file is signed. Then merge what remains with Set-AppLockerPolicy -XmlPolicy C:\AppLockerLab\suggested.xml -Merge and repeat step 7 to confirm every collection still reads AuditOnly. Run another audit cycle. Two or three loops through steps 8 to 11 is normal.
Step 12: Switch to enforcement, with the rollback ready. Do this when a full audit cycle produces no events you cannot explain. Change every collection to Enabled, apply, and keep a second admin session open so you can revert without signing out.
$xmlPath = "C:\AppLockerLab\enforce.xml"
Get-AppLockerPolicy -Local -Xml | Out-File $xmlPath -Encoding utf8
[xml]$x = Get-Content $xmlPath -Raw
foreach ($rc in $x.AppLockerPolicy.RuleCollection) { $rc.EnforcementMode = "Enabled" }
$x.Save($xmlPath)
Set-AppLockerPolicy -XmlPolicy $xmlPath
gpupdate /force
# Rollback, if needed:
# Set-AppLockerPolicy -XmlPolicy C:\AppLockerLab\policy-before.xmlAppLocker rules do not apply in Safe Mode, which gives you a last-resort recovery path if a bad policy blocks even your admin tools. Boot to Safe Mode, run the rollback command, and restart.
Step 13: Verify the block and schedule a review. As applocker-test, repeat the Downloads executable and the Desktop script from step 8. Both should now fail. The executable shows a message that the program is blocked by group policy, and the script is blocked or drops into a restricted language mode. Then confirm the block events landed in the logs and an allowed app still starts.
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/EXE and DLL" -MaxEvents 20 |
Where-Object { $_.Message -match "was prevented from running" } |
Select-Object TimeCreated, Message | Format-List
Copy-Item C:\AppLockerLab\enforce.xml C:\AppLockerLab\policy-enforced-$(Get-Date -Format yyyyMMdd).xmlKeep the dated copy of the enforced policy somewhere outside the machine, such as a private repository or a secured file share. Put a calendar reminder on the same cycle as Patch Tuesday. Software updates change publishers and paths, and each new product you install needs a rule or an explicit decision to block it.
Complete Working Project: One Script for Build, Audit, Report, Enforce, and Rollback
The 13 steps work, but repeating them by hand across several PCs invites mistakes. This script wraps the same logic into five modes. Save it as C:\AppLockerLab\Invoke-AppLockerLab.ps1 and run it from an elevated Windows PowerShell 5.1 session. It never enforces unless you ask, and it refuses to enforce while unexplained audit events remain unless you pass -Force.
#Requires -RunAsAdministrator
[CmdletBinding()]
param(
[ValidateSet('Build','Report','Enforce','Rollback','Status')]
[string]$Mode = 'Status',
[string]$WorkDir = 'C:\AppLockerLab',
[string[]]$ExtraAppFolders = @(),
[int]$Days = 7,
[switch]$Force
)
$ErrorActionPreference = 'Stop'
$null = New-Item -ItemType Directory -Path $WorkDir -Force
$backup = Join-Path $WorkDir 'policy-before.xml'
$defaults = Join-Path $WorkDir 'defaults.xml'
$working = Join-Path $WorkDir 'working.xml'
$logs = 'Microsoft-Windows-AppLocker/EXE and DLL',
'Microsoft-Windows-AppLocker/MSI and Script'
function Set-LocalMode {
param([ValidateSet('AuditOnly','Enabled')][string]$Value)
Get-AppLockerPolicy -Local -Xml | Out-File $working -Encoding utf8
[xml]$x = Get-Content $working -Raw
foreach ($rc in $x.AppLockerPolicy.RuleCollection) { $rc.EnforcementMode = $Value }
$x.Save($working)
Set-AppLockerPolicy -XmlPolicy $working
}
function Get-AuditHits {
foreach ($log in $logs) {
Get-WinEvent -FilterHashtable @{ LogName = $log; StartTime = (Get-Date).AddDays(-$Days) } -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match 'would have been prevented' } |
ForEach-Object {
[pscustomobject]@{
Time = $_.TimeCreated
Log = $log.Split('/')[1]
File = ($_.Message -split ' was allowed to run')[0]
User = $_.UserId.Value
}
}
}
}
switch ($Mode) {
'Build' {
if (-not (Test-Path $defaults)) { throw "Put the default rules XML at $defaults first (step 4)." }
sc.exe config appidsvc start= auto | Out-Null
sc.exe start appidsvc 2>$null | Out-Null
if (-not (Test-Path $backup)) { Get-AppLockerPolicy -Local -Xml | Out-File $backup -Encoding utf8 }
Set-AppLockerPolicy -XmlPolicy $defaults
foreach ($folder in $ExtraAppFolders) {
$extra = Join-Path $WorkDir ('extra-' + ($folder -replace '[^A-Za-z0-9]','_') + '.xml')
Get-AppLockerFileInformation -Directory $folder -Recurse -ErrorAction SilentlyContinue |
New-AppLockerPolicy -RuleType Publisher,Hash -User Everyone -Optimize -IgnoreMissingFileInformation -Xml |
Out-File $extra -Encoding utf8
Set-AppLockerPolicy -XmlPolicy $extra -Merge
}
Set-LocalMode -Value AuditOnly
Write-Host "Built and applied in AuditOnly mode. Backup: $backup" -ForegroundColor Green
}
'Report' {
$hits = @(Get-AuditHits)
$csv = Join-Path $WorkDir ("audit-{0:yyyyMMdd-HHmm}.csv" -f (Get-Date))
$hits | Export-Csv $csv -NoTypeInformation
$hits | Group-Object File | Sort-Object Count -Descending |
Select-Object Count, Name | Format-Table -AutoSize -Wrap
Write-Host ("{0} audit events in the last {1} days. CSV: {2}" -f $hits.Count, $Days, $csv)
$suggest = Join-Path $WorkDir 'suggested.xml'
Get-AppLockerFileInformation -EventLog -LogPath $logs[0] -EventType Audited -ErrorAction SilentlyContinue |
New-AppLockerPolicy -RuleType Publisher -User Everyone -Optimize -IgnoreMissingFileInformation -Xml |
Out-File $suggest -Encoding utf8
Write-Host "Review suggested rules before merging: $suggest"
}
'Enforce' {
$open = @(Get-AuditHits).Count
if ($open -gt 0 -and -not $Force) {
throw "$open unexplained audit events in the last $Days days. Run -Mode Report, add rules, or pass -Force."
}
Get-AppLockerPolicy -Local -Xml | Out-File (Join-Path $WorkDir 'pre-enforce.xml') -Encoding utf8
Set-LocalMode -Value Enabled
Write-Host 'Enforcement is ON. Roll back with -Mode Rollback.' -ForegroundColor Yellow
}
'Rollback' {
if (-not (Test-Path $backup)) { throw "No backup at $backup." }
Set-AppLockerPolicy -XmlPolicy $backup
Write-Host 'Original policy restored.' -ForegroundColor Green
}
'Status' {
Get-Service appidsvc | Select-Object Name, Status, StartType
([xml](Get-AppLockerPolicy -Local -Xml)).AppLockerPolicy.RuleCollection |
Select-Object Type, EnforcementMode, @{n='Rules';e={ @($_.ChildNodes | Where-Object { $_.LocalName -like 'File*Rule' }).Count }}
}
}Run it in this order: .\Invoke-AppLockerLab.ps1 -Mode Build -ExtraAppFolders "$env:LOCALAPPDATA\Programs", use the PC for a week, then -Mode Report, then -Mode Enforce. Status shows the service and the mode of each collection at any time.
PS C:\AppLockerLab> .\Invoke-AppLockerLab.ps1 -Mode Status
Name Status StartType
---- ------ ---------
appidsvc Running Automatic
Type EnforcementMode Rules
---- --------------- -----
Appx AuditOnly 1
Exe AuditOnly 3
Msi AuditOnly 3
Script AuditOnly 3Run an App Control for Business Audit Policy Alongside AppLocker
Because Microsoft prefers App Control for new deployments, it makes sense to start its audit habit now, even if AppLocker stays your enforcement layer for a while. Audit mode in App Control means a policy with the Enabled: Audit Mode option, which logs what would be blocked without blocking anything. The commands below start from a Microsoft example policy that already ships in Windows and deploy it as an audit-only policy. Run them in an elevated shell on a test machine.
$dir = "C:\AppControl"
New-Item -ItemType Directory -Path $dir -Force | Out-Null
Copy-Item "$env:windir\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml" "$dir\audit.xml"
Set-CIPolicyIdInfo -FilePath "$dir\audit.xml" -PolicyName "Audit-Baseline" -ResetPolicyID
Set-RuleOption -FilePath "$dir\audit.xml" -Option 3 # Enabled: Audit Mode
ConvertFrom-CIPolicy -XmlFilePath "$dir\audit.xml" -BinaryFilePath "$dir\audit.cip"
CiTool.exe --update-policy "$dir\audit.cip"
CiTool.exe --list-policiesUse the PC normally, then open Event Viewer and go to Applications and Services Logs, Microsoft, Windows, CodeIntegrity, Operational. Filter for event 3076 to see files the audit policy would block. Related 3089 events add signature details, and 3099 confirms that a policy loaded. On enforcement, the main block event is 3077.
Get-WinEvent -FilterHashtable @{ LogName = "Microsoft-Windows-CodeIntegrity/Operational"; Id = 3076 } -MaxEvents 200 |
ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq "File Name" | ForEach-Object "#text" } |
Group-Object | Sort-Object Count -Descending | Select-Object -First 10 Count, NameTo turn audit evidence into rules, Microsoft’s training material points at New-CIPolicy with the -Audit switch. That switch reads audit evidence to generate rules. It does not flip an existing policy into audit mode, which trips up many readers. On a representative machine the files must still exist on disk, because the cmdlet needs them to build rules.
New-CIPolicy -FilePath "$dir\candidate.xml" -Audit -Level FilePublisher -Fallback Hash
ConvertFrom-CIPolicy -XmlFilePath "$dir\candidate.xml" -BinaryFilePath "$dir\candidate.cip"PowerShell takes part in both systems. Microsoft says PowerShell detects both AppLocker and App Control system-wide policies. Under App Control enforcement, untrusted scripts run in ConstrainedLanguage mode, while policy-approved scripts run in FullLanguage. PowerShell cannot query the enforcement status of an App Control policy directly, so check the Code Integrity log or CiTool.exe instead of asking PowerShell.
7 Common AppLocker Pitfalls That Waste an Afternoon
1. Testing only as an administrator. The default rules let local administrators run anything. If you test from an admin session, the audit log stays empty and you conclude the policy is harmless. Always test as a standard user, which is why step 7 creates one.
2. Enforcing before auditing. This is the classic lockout. A policy that looks correct on paper still blocks the updater for your VPN client or the helper process a printer driver launches from a user folder. Audit mode costs a week and saves a recovery session.
3. Leaning on hash rules for updating software. A hash rule matches one exact file. When the vendor ships the next version, the hash changes and the app breaks on enforcement day. Use publisher rules for signed software and keep hash rules for the few unsigned tools that rarely change.
4. Allowing a whole writable folder. It is tempting to add an allow rule for C:\Users\*\AppData\*, because it makes every complaint disappear. It also gives malware the exact staging area it wants. Allow specific signed publishers instead and leave the writable trees closed.
5. Forgetting game launchers and per-user installers. Programs that install and update inside the user profile are the first things a strict policy blocks. A gaming PC running the EA app alongside other launchers needs publisher rules for each one, or the updaters will fail silently after you enforce. If a PC is mainly for gaming, weigh whether allowlisting is worth the upkeep.
6. Treating AppLocker as a security boundary. Microsoft calls it defense in depth. Pair it with patching, least privilege, and endpoint detection, and do not assume it stops a determined attacker who already has administrator rights.
7. Skipping the backup. Without the exported policy from step 2, rollback means rebuilding rules from memory. Export before every change and keep dated copies.
AppLocker Troubleshooting: 10 Problems and Fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| Policy applied but nothing is blocked or logged | Application Identity service is stopped | Run sc.exe config appidsvc start= auto, then sc.exe start appidsvc |
| Set-AppLockerPolicy fails with access denied | Shell is not elevated | Reopen Windows PowerShell as administrator |
| Get-AppLockerPolicy is not recognized | Running PowerShell 7 or a stripped session | Use Windows PowerShell 5.1 |
| secpol.msc is missing | Windows 11 Home has no Local Security Policy editor | Use the XML and PowerShell route from steps 4 to 7 |
| Everything blocked after enforcement | Default rules missing from a collection | Roll back, re-import defaults.xml, and audit again |
| Admin cannot start tools after a bad policy | Rules enforced with no allow rule for administrators | Boot to Safe Mode, where AppLocker rules do not apply, and restore policy-before.xml |
| Script blocked or runs with limited features | Script rules apply, and PowerShell falls back to a restricted language mode for untrusted scripts | Add a publisher or path rule for the script, or sign it |
| Store apps will not open | Packaged app collection has no allow rule | Keep the signed packaged apps rule from defaults.xml |
| App works until its next update | Hash rule tied to the old file | Replace the hash rule with a publisher rule |
| Teams in a virtual desktop fails to load media components | Policy blocks SlimCore MSIX packages, which Microsoft’s Teams VDI documentation reportedly flags | Add an exception for those packages in AppLocker and App Control |
| Event logs overwrite too fast | Default log size is small for a busy audit | Raise it with wevtutil sl “Microsoft-Windows-AppLocker/EXE and DLL” /ms:268435456 |
Microsoft’s own advice for any block you cannot explain is to look in the event log first. For App Control, the debugging guide linked earlier walks through reading Code Integrity events. For AppLocker, the file path in the event message plus the rule collection tells you which rule to add or which exclusion to remove.
Advanced Tips for a Production Rollout
Ring the rollout. Deploy audit mode to your own device, then a pilot group, then everyone. Each ring should run a full work cycle before the next one starts. This matches how Microsoft describes testing in a lab before production.
Extend policy to SYSTEM processes. By default AppLocker only governs code launched in a user’s context. Microsoft documents rule collection extensions that apply policy to non-user processes, including those running as SYSTEM. This closes a gap, but it raises the risk of breaking services, so audit that mode for longer than you audit the default.
Deploy through your management tool. AppLocker policies can ship through Group Policy or Intune custom OMA-URI settings, and Configuration Manager can distribute software and policy as well. Create rules on a staging machine, test them, then export the XML and import it into the Group Policy Object. App Control deploys through Intune, Configuration Manager, Group Policy, or scripts.
Feed the logs into your detection pipeline. Forward the AppLocker and Code Integrity logs to a central collector so blocks become alerts. Pair them with process telemetry from the Sysmon pipeline linked earlier, and you can correlate a blocked binary with the parent process that tried to launch it.
Pick a PowerShell version on purpose. Windows PowerShell 5.1 remains the inbox shell and is the right home for AppLocker cmdlets. For App Control audit work, PowerShell 7.4 or later adds support for App Control policies in audit mode and records would-be restrictions in event 16387.
Set an exit plan to App Control. Every AppLocker rule you write is a requirement list for a future App Control policy. Keep the audit CSV exports, because they show which publishers and paths your organization genuinely depends on. When you move, start App Control in audit mode, compare event 3076 hits against your AppLocker list, and retire AppLocker collections one at a time. Our cybersecurity coverage tracks how these controls evolve.
Keeping the Policy Healthy After Enforcement
Enforcement day is the start of upkeep, not the end of the project. Policies drift as users install tools, vendors change signing certificates, and Windows ships new servicing builds. Microsoft documented new feature releases and monthly updates throughout October 2026, including the 26H2 baseline update on October 13 and the preview update on October 28, so a monthly check fits the way Windows now ships.
Build a short routine and stick to it. Each month, run the Report mode of the project script and read the CSV. A block event means either a user hit a wall they should not have, or a new legitimate tool arrived without a rule. Decide which one it is, document the decision in the rule description, and move on. Do the same for the first week after any feature update, since file paths and signers can change.
Track the help desk side as well. When a block frustrates someone, they will ask for a quick exception, and quick exceptions are how a tight policy turns into a loose one. Agree on a path for requests before enforcement, name who approves them, and require a publisher or product name rather than a folder. ABT’s allowlisting guide makes a similar point about planning a support path before you move a group to enforcement, because the help desk needs to know where to look and who can add a rule the same day.
Finally, watch Microsoft’s direction. The company updated its AppLocker and App Control documentation on October 20 and again on October 28, 2026, and the message in both is consistent: App Control is where new capability lands. Revisit your plan every quarter. If your management tools already support App Control policies, the cost of switching drops each time Microsoft improves them, and the audit data you collected with AppLocker tells you exactly what a first App Control policy has to allow.
AppLocker on Windows 11: Frequently Asked Questions
Is AppLocker deprecated in Windows 11?
No. As of October 28, 2026, AppLocker is neither retired nor discontinued. Microsoft says it gets security fixes only and that App Control for Business is the preferred application control system, so treat AppLocker as stable but not growing.
Does AppLocker work on Windows 11 Home?
Home lacks the Local Security Policy editor, so the graphical route is out. Microsoft’s documentation lists support across editions for newer Windows 10 builds with KB 5024351, but behavior varies by deployment method. Test enforcement on your own device, and use the PowerShell route from this guide if you try it.
What is the difference between AppLocker and App Control for Business?
AppLocker can target individual users and groups and is classed as defense in depth. App Control applies device-wide, supports kernel-mode policies, and Microsoft designed it as a security feature. App Control was formerly called Windows Defender Application Control (WDAC).
Can AppLocker block PowerShell scripts?
Yes. The Script collection covers script files, and PowerShell detects AppLocker and App Control policies. Untrusted scripts either fail or run with restricted language features. Test your own admin scripts in audit mode before you enforce.
How do I turn AppLocker off if I get locked out?
Boot to Safe Mode, where AppLocker rules do not apply, and run Set-AppLockerPolicy with the backup you exported in step 2. If you have a second admin session open, you can run the same command without rebooting.
How long should I leave AppLocker in audit mode?
Run at least one full work cycle on a personal PC and two on a shared or business device. Microsoft cautions that audit evidence does not cover every code path, so also test rare tools by hand.
Where do I find AppLocker logs?
Open Event Viewer and browse to Applications and Services Logs, Microsoft, Windows, AppLocker. App Control events live under CodeIntegrity, Operational. Query either with Get-WinEvent as shown in step 10.
Should I use AppLocker or App Control on a new deployment?
Use App Control when you can. Choose AppLocker when you need per-user rules on shared PCs or one policy across Windows 10 and older systems. You can also run both, with App Control as the strict baseline and AppLocker for user-specific exceptions.
