App Control for Business
App Control for Business, known as Windows Defender Application Control until Microsoft renamed it, decides which code may execute according to a policy an organisation writes. It is enforced by the same kernel Code Integrity engine as Smart App Control, and it takes effect early in boot, before nearly all other operating system code and well before any security agent starts.
That places it in an unusual position for this reference. Most defenses here are a decision stored in kernel memory that a kernel primitive can simply edit. This one can be configured so that the decision is cryptographically signed and checked, and that configuration is the single most attacker-resistant control in the corpus.
| Layer | User. The protected asset is user-mode code execution. |
| Enforced by | Kernel. Code Integrity, before the image is mapped, from early boot. |
| Policy on disk | \Windows\System32\CodeIntegrity\SiPolicy.p7b, or under \Microsoft\Boot\ on the EFI system partition. |
| Also governs | Kernel drivers, through the same engine. See the driver blocklist. |
The configuration is the whole story
Four states matter, and they are not degrees of the same thing. They are different security properties.
No policy. The default on almost every machine. App Control is opt-in and enterprise-driven, so absence is the norm rather than a misconfiguration.
Audit mode. The policy is deployed and evaluated, violations are logged, and nothing is blocked. Audit policies are explicitly not UEFI locked. Audit is where most deployments live longest, because building an allowlist that does not break a fleet is genuinely hard.
Enforced, unsigned policy. Blocking, but the policy file is just a file. An administrator, or malware holding administrator, can replace or delete it and reboot.
Enforced, signed policy, with UEFI Secure Boot. After the first reboot the anti-tampering protection engages. The installed policy names the certificates permitted to sign future updates, so a replacement that is not signed by an authorised certificate is rejected. Tampering with or removing the policy causes a bugcheck rather than a silent downgrade.
Only the fourth state resists a local administrator. The gap between the third and the fourth is larger than the gap between having no policy and having one.
Bypass inventory
What a defender sees
The routes that matter produce very different amounts of evidence.
- Policy file replaced or deleted. Loud on a machine you are watching, and it requires a reboot to take effect, which is a second signal. Alert on the file, not just on the setting.
- A trusted binary spawning unusual children, or reading script content from an unusual place. This is the route with no policy violation to log, because nothing was violated. It has to be caught behaviourally.
- Bugchecks on a signed-policy fleet. A tamper attempt against a signed policy is designed to fail loudly. Treat an unexplained bugcheck on a locked-down machine as a security event rather than a stability one.
- Machines with no policy, or stuck in audit. Not an alert, an inventory question. It is worth knowing what proportion of a fleet is actually enforcing, because that number is usually lower than people assume.
Where this sits among the others
Four features in this corpus answer "may this code run", and they differ by who holds the authority:
- App Control for Business asks a policy your organisation wrote, and can sign.
- Smart App Control asks Microsoft's reputation service.
- AppLocker asks a rule set enforced later and more weakly.
- The vulnerable driver blocklist is a policy in this same family, applied to kernel drivers rather than user-mode code. It is why the BYOVD technique has a shelf life, and why CVE-2026-68820 went around it by using a driver that ships with Windows and can never be blocked.
The signed configuration is the interesting one for this whole reference, because it is the only place in the user layer where the answer to "what does a kernel primitive buy" is not obviously everything. Every other user-layer defense here stores its decision somewhere the kernel can reach and edit. This one stores a signature check as well, and whether that survives a kernel primitive is an open question rather than a settled one.