Smart App Control
Smart App Control decides whether a user-mode program is allowed to run, based on Microsoft's reputation intelligence rather than on a policy an administrator wrote. It is the consumer-facing sibling of App Control for Business, and it rides the same kernel Code Integrity engine, so the decision is made in kernel memory before the image is mapped.
It arrives in this reference for a specific reason. FudModule v3.1, the rootkit Lazarus deployed through CVE-2026-68820, tampers with Smart App Control's policy state directly. That makes it the first user-layer defense in this corpus with a documented in-the-wild kernel-side attack against it.
| Layer | User. The protected asset is user-mode code execution. |
| Enforced by | Kernel. The Code Integrity engine, before the image is mapped. |
| Introduced | Windows 11 22H2. |
| States | Evaluation, On, Off. |
The thing to understand first
Most machines do not have it on, and that is by design rather than by neglect.
A new Windows 11 install starts Smart App Control in Evaluation mode, where it blocks nothing and watches how the machine is used. After roughly a month it turns itself On or Off depending on what it observed. A machine that runs unsigned or unusual software gets Off, and Off is where it stays. Upgrades from Windows 10 arrive Off. Managed enterprise fleets generally run App Control for Business instead.
Historically a machine that reached Off could only get back by resetting Windows, which meant almost nobody did. The March 2026 servicing update relaxed that, so On and Evaluation can now be re-selected without a reset.
The practical consequence is the one that matters for a threat model. On a given target, the most likely reason Smart App Control does not stop something is that it was never enforcing in the first place. An absent gate beats a bypassed gate every time, and no exploit is required to walk through one.
What it actually blocks
When it is On, it is strict in a way most application control is not. There is no per-app exception, no allowlist an administrator can extend, and no "run anyway" prompt. Code either satisfies Microsoft's signing and reputation checks or it does not execute. That strictness is why it is usually Off: it is not tunable enough to survive a machine that does anything unusual.
Bypass inventory
What a defender sees
The first three routes are each observable, and the ordering is worth noting because it is the inverse of how interesting they are.
- A policy state change with no servicing event. The strongest signal, and the one FudModule produces. Smart App Control's enforcement state should only move when Windows updates it or an administrator changes it. A transition with neither is a kernel-side edit.
- An administrator turning it off. Supported, logged, and trivial to alert on.
- The feature sitting in Off. Not an alert, but it belongs in an inventory. Knowing which of your machines are actually enforcing is the difference between a control and a checkbox.
The fourth route produces nothing. Code that satisfies signing and reputation checks is code the feature was designed to run, so there is no event to collect.
Relationship to the other application-control defenses
Smart App Control, App Control for Business and AppLocker overlap and are frequently confused. The short version: they answer the same question with different authorities. Smart App Control asks Microsoft's reputation service, App Control for Business asks a policy your organisation wrote and can sign, and AppLocker asks a rule set enforced later and more weakly.
For an attacker holding a kernel primitive the distinction mostly collapses, because all three record their decision somewhere the kernel can reach. The exception is a signed App Control policy, where the signature is validated rather than trusted, which is the one configuration in this family that does not simply fall to a byte.