Smart App Control vs Application Control in a cloud-native world
Smart App Control is a new feature in Windows 11 22H2 that allows only certain trusted, verified and reputable executables, DLL files and MSI installers to run. Anything not trusted will be blocked from running. This leaves us with a very high security posture.
Microsoft says this feature is intended for consumers and small businesses – and recommends larger organizations and enterprises to use Defender Application Control, which uses the same technology in the background, and has been available since the launch of Windows 10.
This blog post covers Smart App Control versus Defender Application Control in a cloud-native world, where Windows devices are connected only to Azure AD and Intune.
Background
One thing to start with – forget AppLocker as it is too weak and has too many flaws. We need something more secure that also includes anything running on the machine, regardless of user space vs kernel space and also applies to local administrators. At the same time, it must be hard to circumvent which is true for both Smart App Control and Application Control. AppLocker is too easy to circumvent, for instance by using a trusted process by AppLocker to load a malicious DLL file. See a number of examples on AppLocker bypasses here.
High-level overview
Smart App Control | Application Control | |
---|---|---|
Target audience | Consumers and small businesses. | Organizations and enterprises. |
Modes | On (Block), Evaluation (Audit), Off. | Audit or Block mode. |
Exceptions | No exceptions possible – you are 100% in hands of Microsoft control and deciding what is trusted and reputable. | You can create exceptions; however, it involves a certain amount of administration and manual work. |
Enablement | Only for fresh deployment/installations, or resets of Windows 11 22H2. | Any given time – whenever you choose to deploy it. |
Goal is to set On (Block) mode, but first Evaluation (Audit) mode
Whenever enabling a technology that will effectively block stuff, it is highly recommended to first assess the situation obtaining intel about what would happen if we set a feature like this in On or Block mode.
So, our goal is without a doubt to first audit and collect information that we can use to evaluate how enabling either Smart App Control or Application Control in block would work. This is the focus to come, when we look at options on enabling audit/evaluation mode.
At the same time, we need to weigh in that running in audit mode gives us no raised security, it will only collect information. The sooner we can enable Block or On mode, the better.
Options to enable via Intune
Smart App Control | Application Control (AppLocker CSP) | Application Control (ApplicationControl CSP) | |
---|---|---|---|
Technology | Registry value1. | Endpoint Protection configuration profile (uses AppLocker CSP in background). | Using Custom OMA-URI configuration profile using ApplicationControl CSP. |
Mode of allow control features | Default Allow Microsoft binaries + Intelligent Security Graph (reputable binaries) + Microsoft recommended driver block rules + Microsoft recommended block rules (with exception of what is noted here) | Default Allow policy in Audit or Block mode. “Optional” to use Intelligent Security Graph (reputable binaries), but if you want it to work and not block you from working you MUST use Intelligent Security Graph. | Custom policy which might contain any number and type of rules, including Intelligent Security Graph. |
Managed installer | No, not available. | No, not available. | Yes, this is possible. You can set Intune agent as Managed Installer to trust everything that comes through Intune. However, Managed Installer can only be applied via a custom created AppLocker XML file which must be applied with an AppLocker PowerShell command, plus the Application Control must use option 13 which is the “Managed Installer” enable switch. |
Reboot | No, not when applied but requires a reboot to take effect. | When applied it forces a reboot of the computer, both in audit and block mode. This breaks ESP (Enrollment Status Page) when using Autopilot. | No, not when applied, but needs a restart to take effect (unless you specify option 16 when creating the policy). |
1 Registry value to configure Smart App Control is found in HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy. The DWORD value named VerifiedAndReputablePolicyState can be set to 0 = Off, 1 = On or 2 = Evaluation.
AppLocker CSP vs ApplicationControl CSP
The big difference is that the AppLocker CSP always requires a forced reboot, which means we cannot use it in practice when doing Autopilot and using the Enrollment Status Page. That leaves us with manual configuration of Application Control via ApplicationControl CSP, which is the most secure option where you are in total control. The only problem is that this involves many manual steps, and this surely needs a user interface (in Intune).
“WDAC policy deployment via the AppLocker CSP will continue to be supported, all new feature work will be done in the ApplicationControl CSP only”
https://learn.microsoft.com/en-us/windows/client-management/mdm/applicationcontrol-csp?source=recommendations
Example policies and check if policy is applied
You can check what policies are applied, if any on your computers, by looking at two places in the file system. If only one single policy is applied, which is the case if using Application Control with AppLocker CSP, it will be found in the below directory and names SIPolicy.p7b:
C:\Windows\System32\CodeIntegrity\CIPolicies
However, if multiple policies are applied, which is the case if you applied Smart App Control or using ApplicationControl CSP with base and supplemental policies, they will be found in:
C:\Windows\System32\CodeIntegrity\CIPolicies\Active
You can also start msinfo32.exe and see the current configuration.

Analyzing potential impact of Smart App Control or Application Control
Regardless of if you enable Smart App Control in Evaluation mode or Application Control in audit mode, you can and must follow-up in Microsoft 365 Defender portal (https://security.microsoft.com). This is where you find everything you need to get an overview of the current situation.
Timeline
If you go to a specific device in the Defender portal (https://security.microsoft.com), you can explicitly see the actions by Application Control (and Smart App Control).

KQL – Advanced hunting
To be able to get the big picture in a larger organization we need to use advanced hunting to get all the information we can about the audit events.
Smart App Control or Application Control in Evaluation / Audit mode
Use the following KQL query to list everything that would be blocked if switching the Smart App Control to On or Application Control policy to Block mode.
DeviceEvents
| where ActionType == "AppControlCodeIntegrityPolicyAudited"
Smart App Control or Application Control in On / Block mode
Use the following KQL query to list everything that is noticed by users that is blocked when running in On or Block mode.
DeviceEvents
| where ActionType == "AppControlCodeIntegrityPolicyBlocked"
To execute these KQL queries, head over to security.microsoft.com and go to Hunting > Advanced hunting and run the query and note the results, see below example:

Getting from audit / evaluation mode to Block / On
Getting from Evaluation mode to On when using Smart App Control is technically easy – but the limitation is that you cannot create any exceptions if necessary. This basically means that you will be forced to live with some things being blocked, provide other means of delivering that app such as via Cloud PC, or simply disabling Smart App Control. In the best of worlds, having Smart App Control in On mode from day 1, let it be only for some or almost all devices is a huge security gain.
Getting from Audit mode to Block for Application Control requires some work as you will have to create the baseline policies and test, test and test before deploying full scale.
Something to note here as well is that when using Application Control, it is a strong recommendation to have the policies signed with a code signing certificate to provide the best security, i.e. protect the policy or policies from tampering by users or administrators. The code signing recommendation also adds some complexity to the process and routines around handling the signing itself.
Summary
I agree with Microsoft that Smart App Control is limited when it comes to exceptions and that Application Control is the superior technology to use. However, as it looks right now, there are no shortcuts to using Application Control and for most organizations, the threshold to pass to get to a block mode today is extensive and very time-consuming. At the same time, there are technical implementations that break most Autopilot scenarios which is not OK to step aside from.
What I really like about Smart App Control is that you get it for free when fresh installing or obtaining Windows 11 22H2 machines, having the ability to easily turn on the protection mechanism that will truly protect your devices. And you can start monitoring from day 1, and with minimum effort easily enable the protection mechanism.
The big drawback of Smart App Control is that you cannot make any exceptions if something is blocked and you want to allow it, that is very obvious. In this scenario you would have to disable Smart App Control or present the application to the users in another way, via for instance Azure Virtual Desktop where you could publish the application as a remote application.
So, what Microsoft should provide are the tools that will help IT departments to enable Application Control. There must be an easy way via Intune to 1) making sure we have an easy way of defining the Intune agent to become a managed installer and 2) making it easy to create a great baseline policy, and 3) making it easy to create supplemental policies whenever something needs to be allowed (as an option to deploying the binary via the Intune agent).
One Comment