Smart App Control: the Windows 11 security feature you cannot switch on, and why it is off on every managed device

Open Windows Security on any Intune-managed Windows 11 device in your fleet. Go to App & browser control. You will probably see a section called Smart App Control, and it will say Off. Nobody on your team turned it off. There is no Intune policy that turned it off. It turned itself off, on purpose, because your device is managed.

Smart App Control (SAC) is the most misunderstood security feature in Windows 11. It is genuinely strong protection. It is also almost impossible to run on managed hardware, for reasons Microsoft documents but rarely puts in one place. And the folklore around it, that switching it off is a permanent one-way door needing a clean install of Windows, is now contradicted by Microsoft's own pages, which disagree with each other. This post walks the whole feature: what it actually evaluates, its three states, the exact registry surface, the event log, the shared engine it borrows from App Control for Business, and what you should deploy on managed devices instead.

The problem: a security feature you cannot switch on

Let us start with what Smart App Control actually is, because most people have only seen the toggle.

Smart App Control is an application-trust feature introduced in Windows 11 version 22H2. Microsoft describes it as combining its app intelligence services with Windows code integrity features. In plain English, it decides whether a program is allowed to run at the moment Windows tries to load it.

The decision chain is short and worth memorising. It runs in this order, every time a binary loads.

1. Windows asks Microsoft's cloud app intelligence service for a verdict on the file.
2. If the service predicts the file is safe, it runs.
3. If the service predicts the file is malicious or potentially unwanted, it is blocked.
4. If the service cannot make a confident prediction, Windows falls back to the signature.
5. If the file carries a valid signature from a certificate authority in the Microsoft Trusted Root Program, it runs.
6. If the file is unsigned, or the signature is invalid, it is considered untrusted and blocked.

Microsoft's own summary of the net effect is blunt: malware, potentially unwanted apps and unknown, unsigned code are blocked by default. That is a genuinely strong posture. It is also why it never survives on a developer workstation.

Two acronyms before we go further, since both appear constantly in this feature area. WDAC is Windows Defender Application Control, the old name for what Microsoft now calls App Control for Business. ISG is the Intelligent Security Graph, Microsoft's cloud reputation service. Smart App Control uses the ISG for step one above, and App Control for Business can use exactly the same service.

Now the problem. On managed hardware, Smart App Control is off, and you have no supported way to turn it on at scale. Not a Group Policy setting. Not an Intune Settings Catalog setting. Not a Configuration Service Provider (CSP) OMA-URI. The one documented administrative lever Microsoft publishes for this feature exists purely to turn it off more decisively than it turns itself off.

Why it happens: a one-way switch and a 48-hour timer

There are three separate mechanisms working against you here. They get conflated constantly, so let us separate them.

Mechanism one: the three states, and which transitions are allowed

Smart App Control has exactly three documented states. You can see them in the Windows Security app at Settings > Privacy & Security > Windows Security > App and Browser Control > Smart App Control settings.

Microsoft's developer testing article states the transition rule directly. Configuring Smart App Control to Off or On is a one-way operation, and you cannot change modes using Windows Settings unless the current setting is Evaluation. Read that carefully. Evaluation is the only state you can freely leave and choose your destination from. Once you land on Off or On through the UI, the UI stops offering you the other options.

Mechanism two: evaluation mode decides against you

Evaluation mode is not a countdown to enforcement. It is an assessment, and it can conclude that you fail.

Microsoft says evaluation mode judges "whether the device is a good fit for the protection it offers based on the variety of apps installed and used on the device". The consumer FAQ is more candid about the outcome. It says that some legitimate tasks corporate users and developers do regularly would be a poor experience with Smart App Control running, and that "if we detect that you're one of those users, we'll automatically turn Smart App Control off so you can work with fewer interruptions".

For managed devices there is a documented number attached, and it is short. The App Control for Business overview states that Smart App Control starts in evaluation mode and switches off within 48 hours for enterprise-managed devices unless the user turns it on first.

The consumer FAQ lists the full set of documented reasons Smart App Control ends up off. Any one of these is enough.

• The device is enterprise-managed, or developer mode has been configured.
• Evaluation mode determined the device was not a good candidate.
• It was turned off manually by a user signed in to the machine.
• The device is running Windows in S mode.
• Optional diagnostic data in Windows is turned off.

That last one matters more than it looks. Smart App Control depends on optional diagnostic data. Plenty of organisations disable optional diagnostic data as a privacy baseline, and doing so removes Smart App Control from the table permanently on those devices. Microsoft's stated remedy is to reset the PC or reinstall Windows and select Send optional diagnostic data during setup.

Mechanism three: the folklore, and where the docs now disagree

The well-known claim about Smart App Control is that turning it off is irreversible, and the only route back is a clean install. That claim came from Microsoft, and part of it is still on Microsoft's site. But the three relevant pages no longer say the same thing, and if you are writing internal guidance you need to know that.

Why the engine is shared, and why that is the good news

Here is the part that redeems the whole story. Smart App Control is not a parallel security stack. Microsoft states that it built Smart App Control "entirely upon App Control for Business", and that the service Smart App Control uses to predict what code is safe to run "is also available in App Control for Business and called the Intelligent Security Graph (ISG)".

You can see the shared engine on disk. Both features are evaluated by the same code integrity components, and Smart App Control's policy is a real App Control policy with a real policy ID, sitting in the same folder as every other code integrity policy on the machine.

How to verify: registry, CiTool, Event Viewer, files

Four independent sources of truth. Check at least two, because the registry value and the actually-enforced policy can disagree if someone has been forcing states.

Surface 1: the registry

Everything about Smart App Control's state lives under one parent key. The value names are long, so here it is once, on its own.

Two more values are documented, but only inside Microsoft's developer testing article, and only in the context of forcing a mode offline. They sit under different parents.

Here is the Registry Editor view on a managed device where Smart App Control turned itself off.

Surface 2: CiTool, the supported way to see what is actually enforced

The registry says what was asked for. CiTool.exe says what is loaded. Microsoft documents the check by friendly name: Smart App Control is in evaluation mode if the friendly name is VerifiedAndReputableDesktopEvaluation and "Is Currently Enforced" is true, and in enforcement mode if the friendly name is VerifiedAndReputableDesktop and "Is Currently Enforced" is true.

The command below lists every code integrity policy on the device as JSON and filters to the two Smart App Control base policies. It only reads.

Read the output as a pair. If the registry value says 0 and neither policy is enforced, the two agree and the device is genuinely off. If they disagree, somebody has written the registry value without refreshing, and the machine is in the inconsistent state Microsoft warns about.

Surface 3: Event Viewer

Smart App Control does not get a private event channel. It logs into the same code integrity channel as App Control for Business, which is exactly what you would expect from a shared engine. The channel, stated once:

Microsoft documents two event IDs as specifically Smart App Control's, plus a wider catalog you will need when you move to App Control for Business.

Scripts, installers and COM objects are logged elsewhere. Microsoft documents a second channel, Applications and Services Logs\Microsoft\Windows\AppLocker\MSI and Script, carrying 8028 (audit) and 8029 (enforced) for script hosts, 8036 for blocked COM objects, 8037 for an allowed script, 8039 and 8040 for packaged apps, and 8038 for script signature information.

That 3116 row is worth flagging honestly. It appears on a live device with the message "Signature information for Code Integrity policy ID", but it is not in Microsoft's published event ID reference, which stops at 3114. Report it if you see it, and do not build alerting on it, because an undocumented event ID can change in any update.

Surface 4: services, tasks and log files

There is no service named after Smart App Control, and no scheduled task under \Microsoft\Windows\ that drives it. Say that plainly to anyone who asks you to restart the Smart App Control service. Code integrity evaluation happens in the kernel through ci.dll, not in a user-mode service you can bounce. The surrounding cast, however, is real.

Three scheduled tasks sit under \Microsoft\Windows\AppID\ and support the identity and certificate side of application control: PolicyConverter, VerifiedPublisherCertStoreCheck and EDP Policy Manager. None of them are Smart App Control's, and none of them need touching.

On log files, the honest answer is that this feature has no text log. There is no .log file under C:\Windows\Logs for Smart App Control. Its state lives in the registry, its policies live as .cip binaries under C:\Windows\System32\CodeIntegrity\CiPolicies\Active\, and its decisions live in the event log. If you were hoping to grep a file, the closest equivalent is filtering the CodeIntegrity Operational channel for IDs 3076 and 3077, which is what a healthy versus broken read looks like: 3077 events naming a business application are broken, and no 3077 events at all with the policy enforced is healthy.

Surface 5: how SmartScreen fits, and why it is not the same thing

People conflate Smart App Control with Microsoft Defender SmartScreen constantly. They are different features with different verdicts. SmartScreen warns and lets the user click through. Smart App Control blocks, and Microsoft states there is currently no way to bypass its protection for individual apps.

The connection is visible inside the shipped policy. SmartAppControl.xml contains a Windows Lockdown Policy settings block with entries named ShellSmartscreenSuppressed, BrowserSmartscreenSuppressed and ISGSmartscreenTrustSuppressed. In other words, when the lockdown policy is active, the SmartScreen prompts are suppressed, because a hard block has replaced the warning. Those individual value names are observed inside a Microsoft-shipped file rather than documented on Microsoft Learn, so treat them as descriptive, not as a supported configuration surface.

SmartScreen, unlike Smart App Control, is fully manageable. It has real Group Policy settings and real CSP settings.

That is the entire SmartScreen area of the Policy CSP: three settings. None of them is Smart App Control. This is the honest verification the topic demands, and the absence is the finding.

The fix: deploy App Control for Business instead

Stop trying to enable Smart App Control. Deploy its policy under a name you control.

Step 1: state the negative findings out loud in your documentation

Before the how-to, record the two absences, because they will be questioned.

Step 2: build your base policy from the shipped Smart App Control policy

Microsoft recommends this policy as the ideal starter for most App Control deployments. There is one mandatory edit. Because the shipped file is a conditional Windows lockdown policy, you must remove that option before it can work as an ordinary App Control policy.

Copy the file somewhere else first and edit the copy. Never edit the file in C:\Windows\schemas. Microsoft's documented requirement is to remove the option Enabled:Conditional Windows Lockdown Policy so the policy is ready for use as an App Control for Business policy. The easier route for most people is the App Control Wizard from https://aka.ms/appcontrolwizard, where the same policy appears as the Signed and Reputable mode base template, already prepared.

Step 3: deploy it with Intune, click by click

First, if you deploy applications with Intune, turn the Intune Management Extension into a managed installer. Everything Intune installs afterwards is then tagged as trusted automatically.

1. Sign in to the Microsoft Intune admin center.
2. Go to Endpoint security, then App Control for Business.
3. Select the Managed installer tab, then select Create.
4. On Basics, enter a Name and a Description.
5. On Settings, set Enable Intune Managed Extension as Managed Installer to Enabled, which is the default.
6. On Scope tags, add any scope tags you use, then select Next.
7. On Assignments, include your device groups. Managed installer policy applies to the device scope only, so user targeting will not behave the way you expect.
8. On Review + create, select Create. Allow up to 10 minutes for the policy to appear and up to 30 minutes for delivery.

Now the App Control policy itself.

1. Go to Endpoint security, then App Control for Business.
2. Select the App Control for Business tab, then select Create Policy.
3. On Basics, enter a Name and Description.
4. On Configuration settings, choose a Configuration settings format. Pick Enter xml data to upload your edited Smart App Control policy. Pick Built-in controls if you want the simple path.
5. If you chose Built-in controls, set Enable trust of Windows components and store apps. Choose Audit only for your first ring.
6. Under Select additional options for trusting apps, tick Trust apps with a good reputation to use the same ISG reputation service Smart App Control uses, and Trust apps from managed installers to trust everything you deploy through Intune.
7. On Scope tags, add scope tags, then select Next.
8. On Assignments, select your pilot device group. App Control applies to the device scope only.
9. On Review + create, select Create.

Under the covers this uses the ApplicationControl CSP. Worth knowing: when you use built-in controls, the resulting base policy takes one of four fixed policy IDs depending on which combination of the built-in options you picked, so two differently-named policies with the same options share a policy ID.

Step 4: deploy it with Group Policy, click by click

If you still have domain-joined devices, Group Policy can deploy an App Control policy. Note the limitation before you start.

1. On a machine with the Remote Server Administration Tools installed, run GPMC.MSC.
2. Right-click the target organisational unit and select Create a GPO in this domain, and Link it here.
3. Name the GPO, then right-click it and select Edit to open the Group Policy Management Editor.
4. Navigate to Computer Configuration > Administrative Templates > System > Device Guard.
5. Right-click Deploy App Control for Business and select Edit.
6. Select Enabled, then specify the deployment path to your compiled policy. This can be a local path or a UNC path all computer accounts can read.
7. Close the editor and restart the target machine. Whatever you named your binary, it is converted to SiPolicy.p7b on the client.

Step 5: expect Defender to change state, and do not open a ticket about it

One documented side effect surprises people. When Smart App Control is on, or when you enable App Control with the ISG option, Microsoft Defender Antivirus is set to passive or hybrid mode on systems using a non-Microsoft antivirus for real-time protection. Microsoft states plainly that this is expected behaviour, not a bug or a sign of misconfiguration. Defender handles the reputation checks while your chosen antivirus keeps real-time protection.

Proof it worked: a real read-only run

The companion script for this post reports the Smart App Control state on a device with the numeric value translated, says whether it is in evaluation, checks whether App Control policies are also present, and prints a plain-English verdict on whether Smart App Control can be re-enabled. It is read-only, ASCII-only, parses cleanly on both Windows PowerShell 5.1 and PowerShell 7, and aborts with exit code 1 rather than printing a misleading clean result if a read fails.

The output below is a genuine run on a managed Windows 11 Enterprise device, trimmed for length, with no identifiers to redact.

Read that output as a story, not a status. Smart App Control is off, exactly as documented for an enterprise-managed device. The registry and the enforced-policy list agree, so nobody has left the machine half-configured. And the line that should actually prompt action is the one saying no App Control for Business policy has been deployed, because that means this device has no application control at all, only antivirus. That is the gap the shipped SmartAppControl.xml exists to close.

To confirm that the reverse case is detectable, force the failure path rather than trusting a clean result. Run the script without elevation. The CiTool and event log reads are denied, the script names each denied read, exits 1, and prints no zero counts, which is the fail-loud behaviour you want before you wire anything into a detection script.

References

• Application Control for Windows - the VerifiedAndReputablePolicyState value table, the 48-hour enterprise-managed behaviour, the SmartAppControl.xml path, and the Defender passive-mode note.
• Smart App Control overview - the three states in the UI, evaluation versus enforcement mode, requirements, and the clean-install statement.
• Test App Signatures with Smart App Control - the one-way operation statement, the mode value table, the CiTool friendly-name check, and event IDs 3076 and 3077.
• Understanding App Control event IDs - the full event catalog and both channel paths.
• Managing CI policies and tokens with CiTool - every documented switch, including --refresh and --list-policies.
• Use the Smart App Control policy to build your starter base policy - the recommended starting policy and the Wizard walkthrough.
• Deploy App Control policies via Group Policy - the Device Guard path and the single-policy-format limitation.
• Manage approved apps with App Control for Business policy and Managed Installers in Microsoft Intune - the admin center click paths and built-in controls.
• SmartScreen Policy CSP - the complete list of SmartScreen CSP settings, confirming none relate to Smart App Control.
• What is Smart App Control (Microsoft Support) - the trust decision chain, the reasons it is off, the no-per-app-bypass statement, and the current re-enable wording.

Community deep dive

The companion read-only script for this post lives at github.com/Imran76Awan/Windows-11-Scripts under smart-app-control-vs-wdac-signing.