Application control: AppLocker & Software Restriction Policies

Every mechanism elsewhere in this level assumes a program is already running and asks what it's allowed to touch once it is. Application control asks the question one step earlier: should this executable, script, or installer have been allowed to launch in the first place? It's a policy layer bolted directly onto process and DLL creation, evaluated before the image loader finishes doing its job.

Two generations of the same idea

Software Restriction Policies (SRP) came first: a comparatively simple rule engine matching a launching image against path, file-hash, or certificate-based rules, applied through Group Policy. AppLocker is its modern replacement — richer rule types, finer targeting (by user or group, not just machine-wide), and critically, an audit-only mode that logs exactly what a policy would have blocked without actually blocking it. That audit mode matters more than it sounds: rolling out an enforcement policy blind, on a fleet of machines running software you don't have perfect inventory of, is how you turn a security improvement into an outage. Audit-only lets you see the blast radius first.

Rule collections: separate policies for separate categories of "code that runs"

AppLocker doesn't treat "anything that executes" as one bucket. It organizes rules into independent rule collections — executables, scripts, Windows Installer packages, packaged (MSIX/UWP-style) apps, and DLLs — each with its own rule set and its own enforcement toggle. A policy can allow ordinary EXEs freely while tightly restricting which DLLs are allowed to load, or lock down installer packages without touching scripts at all. This granularity is deliberate: the risk profile of "a user double-clicks a downloaded EXE" is genuinely different from "a signed application loads a plugin DLL," and a one-size-fits-all rule would be too blunt for one case or too loose for the other.

Within a collection, rules typically match one of three ways:

• Publisher rules match a code-signing certificate, optionally pinned to a specific product name or version range — the most maintainable option, since it survives routine updates without needing new rules each release.
• Path rules match a file-system location — simple, but only as strong as the ACLs protecting that location, since anything an attacker can write into an allow-listed folder inherits that folder's trust.
• Hash rules match a specific file's exact hash — precise, but brittle, since any update to the file breaks the rule.

AppID: the component actually doing the identification

Underneath both SRP and AppLocker sits Application Identification (appid.sys in the kernel, coordinated by the AppIDSvc service) — the component that actually computes a launching image's publisher, hash, and path identity in the first place. SRP and AppLocker are policy layers consuming what AppID determines; AppID itself doesn't decide allow or deny, it just answers "what is this file, identity-wise" so the policy engine has something concrete to evaluate rules against.

Enforcement is cooperative, not a single checkpoint

There's no one central gate every executing thing passes through. Enforcement happens at several distinct points that cooperate: ordinary process creation, DLL load time (if the DLL rule collection is enabled — which carries a real performance cost, since far more DLLs load than EXEs launch, which is why it's off by default), and inside the script-hosting engines themselves (PowerShell, mshta.exe, the Windows Script Host), each of which has to consult policy before running a script body rather than relying on some OS-wide interception of "script execution" as a single concept.

A worked example: a path rule that blocks a common malware-delivery pattern without touching signatures at all

A simple AppLocker path rule denying execution from %USERPROFILE%\Downloads\* and %USERPROFILE%\AppData\Local\Temp\* stops a large share of the most common malware-delivery pattern — a user downloading and double-clicking an executable attachment or installer — without needing any certificate or hash data whatsoever. The tradeoff is just as concrete: legitimate portable tools that people genuinely run from those same folders get blocked too, which is exactly the kind of false-positive cost audit-only mode exists to surface before enforcement goes live.

A common mistake

Treating application control as a substitute for antivirus, or for patching, conflates two different problems. AppLocker and SRP only answer "should this image be allowed to start" — they say nothing about whether an already-allowed, validly signed binary is behaving maliciously once it's running, which is squarely what runtime detection and the exploit mitigations and access-check machinery elsewhere in this level are for. It's also not bulletproof against a motivated attacker: anyone who can write into an allow-listed path, or who compromises a trusted signing certificate, routes around rule-based policy entirely — which is exactly why hash and path rules are generally considered weaker than publisher rules in any serious threat model.

Where this connects

• Executable loading & runtime and The DLL loader, PEB, and module lists are the exact load-time events AppLocker's executable and DLL rule collections hook into.
• Exploit mitigations (CFG, ACG, ASLR, CIG) is what constrains an already-allowed process after application control has already let it start.
• The Service Control Manager manages AppIDSvc the same way it manages any other Windows service.